MVC存储库模式设计决策 [英] MVC repository pattern design decision
问题描述
我已经为每个模型创建了一个存储库/服务我创造的这是否过度杀戮？相反，我应该为每个逻辑业务领域创建一个存储库/服务，为许多不同的模型提供CRUD？
对我来说，似乎我要么是混乱的项目树与许多文件或混乱一个类有许多方法。 6一路六打另一个。你可以以任何方式考虑任何好的参数吗？
一般来说，如果您使用的是真实存储库模式，反对其他持久层（例如ActiveRecord或DAO），您应该旨在识别您的域聚合，并为每个聚合创建一个存储库。
这是什么意思？那么这在很大程度上取决于你的应用程序，但是通常有一些对象是自然是其他对象的父母，或是相关交易的一部分。
I认为规范的例子是一个电子商务系统，您有一个订单的概念，并且按顺序您有订单线每个订单线是一些产品和数量等等。
在这种情况下，Order对象是系统的聚合根之一，并创建了一个OrderRepository。
在这种情况下要记住的是，订单和订单之间存在一些关系（暗示或其他）。因此，存储库中的CRUD的C-UD部分通常只应该是每个方法的一个方法，通常只需要接收该聚合根对象的实例并对其进行操作（例如。repo.Save（order））。其他可能的参数可能在那里，但这取决于你的含义。
事实上，你可以经常解决大多数C-UD部分的继承（即make a RepositoryBase使用一些已知的逻辑来实现它们，这些逻辑是针对特定的持久性方案发生的一些事情）。
这样我们就可以将CRUD的R部分。在这种情况下，如果您选择进入查询方法路由，那么您可能会获得大量查询方法（GetById; GetByName; GetByCustomerName等）。一些人喜欢，特别是简单的应用程序，暴露了一个基于linq的界面（例如IQueryable GetAll（）），然后可以应用Where子句。 YMMV取决于你的基础持久性，但它是一个坚实的射击，简单的应用程序，尤其是。如果您期望您的持久性提供程序直接支持linq。
最后，许多人通过命令查询责任分离模式的一个或另一个实际分离出查询部分，说持久化和查询的接口应该是不同的。在这种情况下，你会有一个Repo，只有基本的CRUD（GetById，GetAll，Save，Delete）操作系统和另一类可以根据应用程序的意图进行查询的类型。
希望有帮助。
Paul
I have an asp .net MVC application and recently started implementing the repository pattern with a service validation layer, much like this.
I've been creating one repository/service for each model that I create. Is this overkill? Instead, should I create one repository/service for each logical business area that provides CRUD for many different models?
To me, it seems like I'm either cluttering the project tree with many files or cluttering a class with many methods. 6 one way half dozen the other. Can you think of any good arguments either way?
Generally, if you're using a "true" Repository Pattern, as opposed to other persistence layers (e.g. ActiveRecord or DAO's), you should aim to identify your domain aggregates, and create one repository per aggregate.
What does that mean? Well, it depends a lot on your app, but generally there are objects which are naturally 'parents' of other objects, or which are part of a related transaction.
I think the canonical example is an ecommerce system in which you have a concept of an order, and in an order you have orderlines each orderline is some product and a quantity, and so on.
In that case, the Order object is one of the system's aggregate roots and an OrderRepository is created.
The thing to remember in that case is that there's some relationship (implied or otherwise) between a order and its orderlines and so on. So the C-UD parts of "CRUD" on the Repository should generally just be one method each, and should generally just take in an instance of that aggregate root object and operate on it (.e.g. repo.Save(order)). Other possible params might be there, but that depends on your impl.
IN fact, you can often solve most of the C-UD part w/ inheritance (i.e. make a RepositoryBase that implements them using some known logic about what shoudl happen for your particular persistence scheme).
So that leaves us the R part of CRUD. In this case is where you might get a ton of query methods (GetById; GetByName; GetByCustomerName, etc) if you choose to go the query method route. Some folks prefer, espeically for simple apps, exposing a linq-based interface (e.g. an IQueryable GetAll()) that can then have Where clauses applied. YMMV depending on your underlying persistence on that one, but it's a solid shot for simple apps, esp. if you expect your persistence provider to support linq directly.
Lastly, many folks actually separate out the query part via one implentation or another of the Command Query Responsibility Separation pattern, which says the interfaces for persisting and querying should be different. IN that case, you'd have a Repo that just has basic CRUD (GetById, GetAll, Save, Delete) ops and another class of some sort which queries things based on your app's intentions.
Hope that helps.
Paul
这篇关于MVC存储库模式设计决策的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
