存储库中的命令/写入操作是反模式吗？
我现在已经在一些 .NET 项目中使用了存储库模式，但我总是会回过头来与自己争论这个问题：
将存储库视为可查询的数据存储，有人可能会争辩说，在对于命令查询分离原则来说，存储库是一种误解。另一方面，将与相同域对象相关的方法保留在同一个类中可以简化编码和使用，并促进 DRY 和 KISS 原则。
您有哪些不同的观点/论点？福勒或埃文斯会怎么说？
I've used the Repository Pattern in a few .NET projects now, but I always get back to arguing with myself about this question:
Thinking of a repository as a queryable data store, one could argue that having commands (or write operations) in a repository is a misconception, as to the command-query separation principle. On the other hand, keeping the methods that have to do with the same domain objects in the same class simplifies coding and usage, and promotes the DRY and KISS principles.
Which different views/arguments do you have? What would Fowler or Evans say?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对我来说，拥有持久性逻辑和在一个地方引用 O/RM 等底层技术比按读/写职责进行划分更重要。所以我结合了命令和每个域聚合根在一个具体存储库中进行查询，通常使用持久性技术特定的抽象基类（Nhibernate、实体框架等）。
我唯一一次将它们分开是当我使用事件源进行完整的 CQRS 实现（命令/查询责任分离）时，即，当针对不同数据存储的代码库完全不同的区域进行读取和写入时。
For me, having persistence logic & references to underlying technologies like O/RMs in one place is more important than splitting by the read/write responsibility. So I combine command & queries in one concrete repository per domain aggregate root, usually with a persistence-technology specific abstract base class (Nhibernate, Entity Framework, etc).
The only time I split these up is when I am doing a complete CQRS implementation (command/query responsibility segregation) with event sourcing, i.e., when reading and writing happens in completely different areas of my code base against different data stores.