3

到目前为止，我已经制作了几十个使用数据库的应用程序。我并没有深入研究数据库逻辑以及如何构建它，而是按照规则使其尽可能简单。

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

在与一些开发人员交谈时，我被告知我的逻辑结构应该更复杂，更 OOP。我尝试在网上查找样本，但它们都针对解释如何处理数据库。我什至审查了一些开源项目，但它们的逻辑与我的相似。

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

4

2 回答 2

3

这是一个稍微主观的问题，所以这里是一个主观的答案。恕我直言，没有一种正确的方法，我只能谈谈我个人喜欢的工作方式（大项目版本，对于小项目，还有另一个故事）。对于您或您的团队来说，情况可能会有所不同。

作为参考，我的工作主要是敏捷的，例如需求可以改变。代码中的 API 可以更改（并且经常这样做）。这 - 当然 - 会影响我认为有用的东西以及我认为对我的个人工作没有用的东西。

此外，我喜欢尽可能在没有大型框架的情况下工作。这就是为什么下面解释的模型中没有框架的原因。

我将数据库工作分为三个部分来处理：（与MVC 模式有很多相似之处）

  • 实际的数据库后端（可以执行 SQL）。可以包含自己的跨平台工作代码。
  • 存储类，负责存储特定于应用程序的信息。每条信息都可以从存储类中读取和设置，（例如：interface AddressBook提供对 type 元素的访问，interface Contact这些元素具有某些东西的 getter 和 setter。实现将其转换为后端中的单个表）。
  • 应用程序代码，执行实际工作并根据应用程序进一步拆分（例如：提供地址簿 GUI 的东西等）。

为什么我要这样分开？嗯，一个原因是很容易切换到新的存储或数据库后端。如果我发现在重组表以满足新要求时可能会有更多性能，我会更新存储类。这样我就不必触及任何应用程序逻辑（例如：将电子邮件地址的 1:n 表添加到地址簿。新表及其关系不会影响应用程序中的任何代码，它可以接收电子邮件列表联系人的地址，并轻松添加或删除它们）。

另一个原因是应用程序代码易于阅读（因为它由应用程序代码组成），而存储代码也易于阅读（因为它只负责存储、缓存和类似的东西）。

第三个原因是，如果我希望添加另一种存储机制（例如切换到具有内置数据库后端的平台或添加可选的 Web 服务时） - 我可以使用三层上的所有 OOP 机制；例如，多个存储可以在同一个应用程序中共存，以便用户可以选择在本地存储数据（带有数据库后端的存储）或在云中存储数据。

我希望这个答案能让您对在应用程序的数据库相关部分中使用 OOP 的一些可能性有所了解。同样，这不是一种正确的方法，只是我发现一种效果很好。

于 2013-08-30T18:23:40.227 回答
0

试试 ORMLite

Object Relational Mapping Lite (ORM Lite) 提供了一些轻量级的功能，用于将 Java 对象持久化到 SQL 数据库，同时避免了更多标准 ORM 包的复杂性和开销。它支持许多使用 JDBC 的 SQL 数据库，还支持带有对 Android OS 数据库 API 的本机调用的 Sqlite。

http://ormlite.com/sqlite_java_android_orm.shtml

http://sourabhsaldi.blogspot.in/2012/10/ormlite-tutorial.html

于 2013-08-30T18:08:16.640 回答