2

我正在与一位同事一起构建一个 Android 应用程序，其中将包含一个包含大约 15 个表的数据库。根据 Google 的 Android 开发文档，我们现在编写了几个类型类、一个 DB-helper、一个数据提供者，并且每个类型类还有一个排序适配器。

这可行，但我的主要问题是，为了添加数据库表，我需要创建一个新的类型类，编辑 DB-helper 和提供程序，并创建一个新的适配器。看到这很麻烦且容易出错，我想这是 ORM 的完美配方。

环顾四周，我发现唯一有意义的项目是ORMLite。但是四处搜索我什至不觉得 ORMLite 是在 Android 中处理 SQLite 的常用方法。

所以我的问题如下：

  1. 在 Android 应用程序中处理相当复杂的数据库的最常用/最好的方法是什么？自制类还是像 ORMLite 这样的 ORM？
  2. 像 ORMLite 这样的 ORM 是否会使我的 Android 应用程序比编写自己的访问器慢很多？
  3. 您对在 Android 应用程序中访问 SQLite 有任何其他建议（其他 ORM 或技术）吗？
4

1 回答 1

2

这不是一个真正的答案，而只是我在 Android 上使用 DB 的经验的反馈。

我问自己同样的问题，你说得对，这不是很清楚。

在 Android 应用程序中处理相当复杂的数据库的最常用/最好的方法是什么？自制类还是像 ORMLite 这样的 ORM？

我认为在大多数情况下，人们会尝试在他们的应用程序中避免使用复杂的数据库，而当他们做不到时，他们可能会采用 Android 方式（自制类）。（只是我的建议）

像 ORMLite 这样的 ORM 是否会使我的 Android 应用程序比编写自己的访问器慢很多？

如果你说的复杂，你的意思是关系，有很多相同类型的读/写。Ormlite 肯定会减慢您的应用程序的速度。（我的经验）。当您这样做时，访问肯定会更快（因为您不是程序或猴子），但实现和维护的时间会更长。

您对在 Android 应用程序中访问 SQLite 有任何其他建议（其他 ORM 或技术）吗？

再一次，这只是我的建议，但如果您可能是完全或部分复制的数据库（基于服务器），您必须问您：

“我的用户真的可以在没有网络的情况下使用该应用程序吗？” 如果他不能，请优化您对服务器的请求，但不要创建本地数据库。维护起来会更快更简单。

最后，我从未测试过这类解决方案，但这应该是一种“中间方式”——> CouchDB我认为他们正在开发一个库（目前为测试版）......

希望它会有所帮助。

于 2013-09-22T17:56:27.853 回答