1

来自 perl 背景并在其中完成了一些简单的 OO，我正在努力掌握与数据库交互的 android/Java 方式。

根据我的经验，我会为每个对象创建一个文件或类，并且一个对象将匹配/表示数据库中的一个表。

在该对象中将是一个构造函数、数据变量、返回单个变量的方法/函数，还有从 DB 读取和写入的 DB 查询，执行所有必要的 CRUD 功能。

根据我在网上阅读的内容，在 Android 中，我将创建类似的对象，但没有数据库交互。这将发生在一个包含我所有数据库功能的单个类中，或者多个数据库类中，每个表一个。

我的问题都与最佳实践有关。

我可以像在 Perl 中那样做我的应用程序吗？如果不是，为什么不，如果是，有什么优点、缺点和限制？

术语 DAO、适配器和 POJO 是什么意思？

我应该创建一个应用程序类并在那里全局声明数据库吗？

我应该在每个活动中创建一个处理程序还是只在应用程序类中创建一个处理程序？

我已经阅读了很多教程，现在我的头都在旋转，所有这些教程都有不同的做事方式，而且大多只有一个表格，很少显示直接代表表格的实际对象。

我很高兴听到意见，链接到教程或解释奇怪的术语。

提前致谢

4

3 回答 3

1

如果我没看错，ORMLite可能是你最好的选择。它使用反射来创建和维护数据库，这似乎是 Perl 的做法。

于 2012-09-24T23:00:42.520 回答
1

POJO 是Plain old java object这意味着它只是一个普通的类。

适配器将是包含 CRUD 内容并管理数据库本身的类。Android 世界中有很多模式，谈论可以填满一本书。我更喜欢这种模式，我在我的 Application 类中打开数据库一次，我从不关闭它（Android 在杀死应用程序时会这样做）。我拥有的一个非常古老的项目的样本可能会向您展示基本思想。

DAOData Access Object可以写几十本书。如果只是开始编程，看看你要去哪里......

于 2012-09-24T23:01:23.787 回答
1

另一张海报是正确的，将 ORMLite 作为一种管理镜像数据库的代码关系的好方法是正确的。但是，如果您想自己做，有很多方法可以做事，我不会说社区真的倾向于其中一种。就个人而言，我倾向于让我的实体由普通旧 Java 对象表示（POJO- 表示与其他事物没有特殊连接，如数据库），其中表的各种属性对应于字段值。然后，我通过数据访问对象 ( DAO) 持久化并检索这些对象。DAO 都可以访问共享的、开放的数据库对象——他们根据需要执行查询。

例如：如果我有一个 table foo，我会有一个对应的 entity class Foo，其属性对应于列。 class FooDAO将有机制获得Foo：

public Foo getFooById(Integer id) {
   String[] selection = {id.toString()};
   String limit = "1"
   Cursor c = mDatabase.query(FOO_TABLE, null, "id=?", selection, null, null, null, 1);
   // Create a new Foo from returned cursor and close it
}

第二个实体bar可能有很多foo. 为此，我们将在 Bar 中引用FooDAO以获取 bar 的所有成员 foo：

public class Bar {
  public List<Foo> getFoo() {
    return mFooDAO.getFooByBar(this);
  }
}

等等......像这样滚动你自己的 ORM 可以做的范围非常广泛，所以你需要做多少就做多少。或者只是使用ORMLite并跳过整个事情:)

此外，android 工程师不赞成将 Application 子类化为支持单例的全局可访问对象（参见 hackbod 的回答），但意见不一

于 2012-09-24T23:21:50.690 回答