好的移动数据库逻辑应如何构建？

到目前为止,我已经开发了许多使用数据库的应用程序.我没有深入研究数据库逻辑以及如何构造它,而是根据规则使其尽可能简单.

例如,我的数据库逻辑通常由一个扩展SQLiteOpenHelper的数据库类组成.然后,我为每个表创建CRUD方法.每次必须处理数据库时,我都会创建一个特殊的AsyncTask并在其中处理数据库.就是这样.

与一些开发人员交谈时,我被告知我的逻辑结构应该更复杂,更面向对象.我尝试在网上查找示例,但所有示例均旨在说明如何处理数据库.我什至回顾了一些开源项目,但它们的逻辑与我的相似.

你能帮助我吗？我应该如何使数据库逻辑更加面向对象？我猜他们提到我将来应该能够重用此逻辑,仅更改处理特定数据库及其表的最低部分.

解决方法:

这是一个有点主观的问题,所以这是一个主观的答案.恕我直言,没有正确的方法,我只能说一下我个人的工作方式(大型项目版本,对于小型项目,还有另外一个故事).对于您或您的团队而言,可能会有所不同.

供参考,我主要是敏捷的,例如需求可以改变.代码中的API可以更改(并且经常更改).当然,这会影响我认为对我的个人工作有用和不有用的东西.

另外,我喜欢尽可能不使用大型框架.这就是下面解释的模型中没有框架的原因.

我将数据库工作分为三个部分进行处理：(与MVC pattern相当相似)

>实际的数据库后端(可以执行SQL).可以包含自己的跨平台工作代码.
>存储类,用于存储特定于应用程序的信息.可以从存储类中读取和设置每条信息(例如：接口AddressBook提供对接口Contact类型的元素的访问,这些元素具有某些内容的获取器和设置器.该实现将其转换为后端的单个表).
>执行实际工作并根据应用程序进一步细分的应用程序代码(例如：提供地址簿GUI的内容等).

我为什么要这样分开？好吧,原因之一是轻松切换到新的存储或数据库后端.如果我发现重组表时可能会有更多性能,以满足新的要求,请更新存储类.这样,我不必接触任何应用程序逻辑(例如：将电子邮件地址的1：n表添加到地址簿.新表及其关系不影响应用程序中的任何代码,它可以接收电子邮件列表通讯录中的地址,并轻松添加或删除).

另一个原因是应用程序代码易于读取(由应用程序代码组成),而存储代码也易于读取(因为它仅负责存储,缓存和类似内容).

第三个原因是,在我希望添加另一种存储机制的情况下(例如,当切换到具有内置数据库后端的平台时,或者在添加可选的Web服务时),我可以在三层上使用所有OOP机制.例如,多个存储可以在同一个应用程序中共存,因此用户可以选择在本地存储数据(与数据库后端存储)还是在云中存储数据.

我希望这个答案能使您对应用程序中与数据库有关的部分中OOP的一些可能性有所了解.再说一次,这不是正确的方法,只是我发现它工作得很好.

标签：oop,android-sqlite,android
来源： https://codeday.me/bug/20191122/2062847.html