Question

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

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

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

从我在网上看到的内容来看，在Android中，我会以类似的方式创建对象但没有数据库交互。这可能发生在具有我所有数据库功能的单个类中，或者发生在多个数据库类中，每个表一个。

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

我可以在Perl中使用我的应用程序。如果不是，为什么不，如果是，有什么利弊和限制？

术语DAO，Adapter和POJO是什么意思？

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

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

我已经阅读了很多教程，现在我的头脑正在旋转，所有这些都采用不同的做法，大部分只有一个表，很少有人直接表示表格。

我很高兴听到意见，与教程相关或只是解释了奇怪的术语。

提前致谢

Answer 1

如果我正确地读你，ORMLite可能是你最好的选择。它使用反射进行数据库创建和维护，这似乎是Perl的工作方式。

Answer 2

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

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

DAO是Data Access Object，可以填写数十本书。如果只是开始编程并看到你的目标......

Answer 3

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

例如：如果我有一个表foo，我会有一个对应的实体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工程师对于全局可访问的对象的子类化而不赞成Singletons（参见hackbod的答案），但观点不同

Android数据库最佳实践

3 个答案: