数据访问层或具有CRUD方法的对象？

Question

我曾经有一个数据访问层，它通过参数获取对象，并使用抽象处理所需的持久性类型。在我的新工作中，架构师正在考虑将CRUD操作（load..save..delete..update）实现到所有模型对象中。那些方法将有一个参数的对象，它将处理对象的保存。例子：加载（IPersistence持久性）。我对可扩展性有一些疑问，每个模型对象都必须实现所有加载，保存，删除，更新方法。

最好的方法是什么？

Answer 1

我想这是永恒的问题，两种方法都有其优点和缺点，以及许多追随者，他们发誓。

您似乎赞成的repository方法（拥有Repository / Gateway，无论您如何称呼它）来处理CRUD操作，使您的实际业务类更小更精简，因为它们可能只包含数据并且可能包含验证/商业规则。

在这种情况下，您将实施一次CRUD操作 - 但对于您正在处理的每种类型的对象，最有可能执行一次。

另一方面，smart business object方法可能会认为给定实体上的CRUD操作无论如何都是特定于该实体的，因此选择，更新，删除这样一个实体的代码总是具体的，所以它也可能驻留在该对象本身内部。

在这种情况下，您将为每个对象类实现一次CRUD操作 - 在这种情况下，我没有看到存储库方法的任何重大缺点，实际上。

我个人今天倾向于使用存储库方法，但我也看到了“智能业务对象”方法的好处 - 两者都是有效的，我想你只需要说服你的新架构师你的位置，或者用不同的方法达成协议。

马克

Answer 2

DAL一路走来。

您希望能够隔离您的事务，以便对象不应该知道它们的持久性。否则，代码可能会导致无法维护的噩梦，其中对象可以激活数据库往返，并且很难将多个事务转换为一个原子操作。

我发现这很难。 ：）

Answer 3

我认为，在这两种情况下，实施都不应该重复，而是只实施一次并根据需要继承（例如）。
只有非标准作业（如自定义查询及其自定义参数）才需要子类及其方法。

---

现在问题相当于 POJO哲学辩论。让我试着用我自己的话说出来;-)：

1. 考虑到模型特定于每个特定问题，因此每个应用程序
2. 考虑到模型需要很多方面：持久性是模型所需的一个方面，以及验证，文档，用户界面组件和消息，用户建议，版本之间的迁移。 ..
3. 考虑仅凭模型足够难以单独理解，维护等，而不是将所有方面合并
4. 您从模型对象推断任何方面应该外部化。

  

实际上，我们只是外化复杂的东西（通常需要一些编码），并保持Pojo非常简单的东西（通常是声明，通常使用Annotations）。

---

模型没有技术超类的另一个巨大优势是模型可以用作自己的“数据传输对象”来在系统之间传递信息：

层之间的
2. 在JVM之间（通过序列化），例如在机器之间

如果我们的模型类具有技术超类，则它们在这样的各种上下文中将没有用处。例如：

1. 模型对象的持久性通常仅在某个层中可用（在架构选择中）。例如，只有业务层才能访问要保留的数据层。
2. 在从一台机器到另一台机器的数据迁移期间，每台机器都可以在自己的数据库上运行。因此，如果模型对象不携带指向数据库的指针，则可以自由地转移模型对象;每个服务员都应该使用自己的数据库。 对于相同的模型对象，可以在其他方面进行变化，如果这些方面不由同一对象承载，则可以方便。