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

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

---

什么是最好的方法？

我想这是一个永恒的问题，两种方法都有各自的优点和缺点，很多追随者都对它们发誓

处理CRUD操作的

repository

方法（拥有一个存储库/网关，不管你怎么称呼它）使您的实际业务类更小、更精简，因为它们可能只包含数据和可能的验证/业务规则

在本例中，您将实现CRUD操作一次，但最有可能的是针对您正在处理的每种类型的对象实现一次

另一方面，

智能业务对象

方法可能认为给定实体上的CRUD操作无论如何都是特定于该实体的，因此选择、更新、删除此类实体的代码总是特定的，因此它也可能驻留在该对象本身内

在本例中，您将为每个对象类实现一次CRUD操作——在本例中，我看不出与存储库方法相比有什么大的缺点

今天，我个人倾向于使用存储库方法，但我也看到了“智能业务对象”方法的好处——这两种方法都是有效的，我想您只需要说服新的架构师了解您的立场，或者使用不同的方法

---

Marc

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

---

现在这个问题相当于波乔的哲学辩论。让我试着用我自己的话来表达它；-）：

考虑到模型针对每个特定问题，因此针对每个应用

考虑到模型需要许多方面：持久性是模型需要的一个方面，还有验证、文档、用户界面组件和消息、用户建议、版本间迁移

考虑到模型本身就很难理解、维护等，而不需要将所有方面合并

您可以推断，任何方面都应该从模型对象外部化

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

---

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

层间

JVM之间（通过序列化），例如机器之间

如果我们的模型类有技术超类，那么它们在如此多的上下文中就没有用处了。例如：

模型对象上的持久性通常仅在某些层中可用（在架构选择中）。例如，只有业务层才有权访问数据层以进行持久化

在数据从一台机器迁移到另一台机器的过程中，每台机器都可以在自己的数据库上工作。因此，如果模型对象不携带指向数据库的指针，那么它们可以自由地传输；每个服务器都应该使用自己的数据库对于同一个模型对象，其他方面可能会发生变化，如果这些方面不是由同一个对象承载的，这将很容易实现

一路走来

您希望能够隔离事务，这样对象就不会知道它们的持久性。否则，代码可能会变成无法维护的噩梦，对象可能会激活数据库往返，并且很难将多个事务滚动到一个原子操作中

---

我好不容易才发现这一点。：）

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