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

Question

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

什么是最佳做法？

- Patrick Desjardins

Answer 1

我想这是一个永恒的问题，两种方法都有其优点和支持者。

你似乎更倾向于使用存储库/网关等方式处理CRUD操作的“存储库”方法，这可以使你的实际业务类更小、更精简，因为它们可能只包含数据和可能的验证/业务规则。

在这种情况下，你需要为每种类型的对象实现CRUD操作一次。

另一方面，“智能业务对象”方法可能会认为，在给定实体上执行CRUD操作本质上是特定于该实体的，因此选择、更新、删除这样的实体的代码总是特定的，所以最好将其放在该对象本身内部。

在这种情况下，你需要为每个对象类实现一次CRUD操作——我真的没有看到在这种情况下与存储库方法相比有什么大的劣势。

我个人今天更倾向于使用存储库方法，但我也看到了“智能业务对象”方法的好处——两种方法都是有效的，我想你要么说服你的新架构师采用你的立场，要么接受不同的方法。

- marc_s

---

我想补充一点，CRUD 的基本情况可以在通用存储库中实现一次（取决于语言），因此您只需要为每个实体实现专门的方法即可。（这也适用于智能业务对象）。 - Matthew Groves

Answer 2

一路使用DAL。

您希望能够隔离事务，使对象不必意识到它们的持久性。否则，代码可能会变成难以维护的噩梦，其中对象可以触发数据库往返，并且很难将多个事务合并为一个原子操作。

我是通过艰苦的方式才发现这一点的。 :)

- Quibblesome

Answer 3

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

---

现在问题归结为POJO哲学辩论。让我尝试用自己的话来表达它;-)：

1.考虑到模型对每个具体问题和每个应用程序都是特定的
2.考虑到模型需要许多方面：持久性是模型所需的一个方面，以及验证、文档、用户界面组件和消息、用户建议、版本之间的迁移...
3.考虑到单独理解、维护等模型本身就很困难，没有所有方面合并
4.您推断出任何方面都应该从模型对象中外部化。

事实上，我们只外部化那些复杂的东西（通常需要一些编码），并保留非常简单的Pojo内容（通常使用注释声明）。

---

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

1.层之间
2.JVM之间（通过序列化），例如在计算机之间

如果我们的模型类有技术超类，它们在这些不同的上下文中将无用。例如：

1.模型对象上的持久性通常只能在某些层中使用（在架构选择中）。例如，只有业务层才能访问数据层以进行持久化。
2.在从一台机器迁移到另一台机器时，每台机器可以在其自己的数据库上工作。因此，如果模型对象不带有指向数据库的指针，则可以自由传输模型对象；每个服务器都应该使用自己的数据库。对于相同的模型对象，其他方面可能存在变化，如果这些方面不由同一对象承载，则易于实现变化。

- KLE