到目前为止,我已经制作了数十个使用数据库的应用程序。我没有深入研究数据库逻辑以及如何构建数据库逻辑,而是使其尽可能简单并且遵循规则。
例如,我的数据库逻辑通常由一个扩展SQLiteOpenHelper
的数据库类组成。然后我为每个表制作CRUD方法。每次我必须处理数据库时,我会创建一个特殊的AsyncTask
并在其中处理数据库。就是这样。
与一些开发人员交谈时,我被告知我的逻辑结构应该更复杂,更多OOP。我尝试在网上找到样本,但它们都是针对解释如何处理数据库的。我甚至回顾了一些开源项目,但他们的逻辑与我的相似。
你能帮帮我吗?我应该如何使数据库逻辑更多OOP?我猜他们提到我将来能够重用这个逻辑,只改变处理特定数据库及其表的最低部分。答案 0 :(得分:3)
这是一个有点主观的问题,所以这是一个主观的答案。没有一个正确的方法来做到这一点,我只能说我个人喜欢的工作方式(大项目版本,小项目还有另一个故事)。对于您或您的团队,可能会有所不同。
作为参考,我的工作主要是敏捷,例如要求可以改变。代码中的API可以更改(并且经常这样做)。这当然会影响我认为有用的东西以及我认为对我个人工作没用的东西。
另外,我喜欢在没有大框架的情况下工作。这就是为什么下面解释的模型中没有框架的原因。
我将数据库工作划分为三部分来处理:(与MVC pattern相似的一些类似物)
interface AddressBook
提供对interface Contact
类型元素的访问,这些元素具有某些东西的getter和setter。实现将其转换为单个在后端的表格。为什么我这样分开?好吧,一个原因是易于切换到新的存储或数据库后端。如果我发现在重组表时可能会有更多的性能,以便满足新的需求,我会更新存储类。这样我就不必触摸任何应用程序逻辑(例如:将电子邮件地址的1:n表添加到地址簿中。新表及其关系不会影响应用程序中的任何代码,它可以查看电子邮件列表来自联系人的地址,并轻松添加或删除它们。
另一个原因是应用程序代码易于阅读(因为它包含应用程序代码),而存储代码也易于阅读(因为它只负责存储,缓存和类似的东西)。
第三个原因是,在我希望添加另一种存储机制的情况下(例如,当切换到具有内置数据库后端的平台或添加可选的Web服务时) - 我可以在三者上使用所有OOP机制层;例如,多个存储可以在同一个应用程序中共存,这样用户就可以选择在本地存储数据(存储数据库后端)还是存储在云端。
我希望这个答案让您对应用程序中与数据库相关的部分中的OOP有一些可能性。再一次,这是不是这样做的正确方法,只是我找到了一个很好的方法。
答案 1 :(得分:0)
尝试ORMLite
对象关系映射Lite(ORM Lite)提供了一些轻量级功能,用于将Java对象持久化到SQL数据库,同时避免了更多标准ORM包的复杂性和开销。它支持使用JDBC的许多SQL数据库,并且还支持Sqlite以及对Android OS数据库API的本机调用。
http://ormlite.com/sqlite_java_android_orm.shtml
http://sourabhsaldi.blogspot.in/2012/10/ormlite-tutorial.html