.net - 存储库模式是程序性的，而不是 OOP？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

6年前关闭。




Improve this question




嗯，我一直在读一本关于领域驱动设计的书，它的标题是领域驱动设计的模式、原则和实践(PPPDDD)。到目前为止，我一直很喜欢阅读它，它为 .NET 世界中的 DDD 提供了很多见解。然而，有一件事情让我很困扰。在第 21 章(存储库模式)中，作者提出了以下两个主张:

权利要求 1:

The repository is not an object. It is a procedural boundary and an explicit contract that requires as much effort when naming methods upon it as the objects in your domain model do.

权利要求 2:

The repository is the contract between the domain model and the persistence store. It should be only written in terms of the domain and without a thought to the underlying persistence framework. Define intent and make it explicit; do not treat the repository contract like object oriented code.

所以存储库模式不是 OOP，而是程序化的？您同意本书作者的说法吗？为什么明确存储库方法，例如 findByUsername(string Username) 使存储库本质上是程序化的？

我想写面向对象的代码，而不是程序代码。如果存储库是程序性的，那么它完全扼杀了我使用这种模式的目的。我真的希望作者说的不是真的，你怎么看？

顺便说一句，我提供了本书作者声称存储库在下面的程序部分的快照，如果有帮助，请查看它们:

Answer 1

The repository is not an object. It is a procedural boundary

我完全不同意这一点。存储库是事物的集合。

如果您 GetAll()然后 Add()一些东西到 repo 然后 GetAll()同样，您不会期望得到相同的结果。你谈话的对象变了

=> 它 有一个内部状态 ，或者至少它在外界看来是这样的。

它 隐藏其内部状态 ，a.k.a. 封装了它，因为您可以访问的只是接口(interface)，而不是底层的持久性细节。

您可以 传递消息到一个存储库(调用它的方法)并与同一个存储库进行可能很长的“讨论”。

对象形式非常适合存储库所做的工作。

书中对程序一词的使用充其量是尴尬的，最坏的情况是误导。它有一个明确的契约这一事实与编程的程序风格无关。