MVC模式库的设计决策 [英] MVC repository pattern design decision

问题描述

我有一个的ASP.NET MVC应用程序和最近开始实施与服务验证层的存储库模式，很像<一个href=\"http://www.asp.net/%28S%28pdfrohu0ajmwt445fanvj2r3%29%29/learn/mvc/tutorial-38-cs.aspx\">this.

I have an asp .net MVC application and recently started implementing the repository pattern with a service validation layer, much like this.

我已经建立一个资料库/为我创建的每个模型的服务。这是矫枉过正？相反，我要建立一个资料库/每个逻辑业务领域，提供了CRUD许多不同型号的服务？

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?

要我，好像我是不是塞满了许多文件的项目树或塞满一类具有许多方法。 6单向另一半打。你能想到的任何好的理由无论哪种方式？

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?

推荐答案

通常，如果您使用的是真Repository模式，而不是其他的持久层（如ActiveRecord的或DAO的），你的目标应该是确定域汇总，并建立每个聚集一个存储库。

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.

我认为，典型的例子是，你有一个订单的概念的电子商务系统，并在为了你orderlines每个订单项目的部分产品和数量，等等。

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.

在这种情况下，订单的对象是系统的总根源之一，并创建一个OrderRepository

In that case, the Order object is one of the system's aggregate roots and an OrderRepository is created.

在这种情况下需要记住的是，有一个秩序及其orderlines等之间的一些关系（暗示或其他）。因此，对信息库CRUD的C-UD的部分通常应该只是每个人的方法，一般应该只是把在聚合根对象的实例，并在其上​​运行（.e.g。repo.Save（顺序））。其他可能的PARAMS可能是有，但要看你implement执行。

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.

其实，你经常可以解决大部分C-UD部分W /继承（即使实现他们RepositoryBase使用约shoudl发生的事情为你特定的持久方案一些已知的逻辑）。

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).

所以这给我们留下CRUD的R部分。在这种情况下，你可能会得到一吨的查询方法，如果你选择去查询方法途径（GetById; GetByCustomerName等; GetByName方法）。有些人preFER，espeically简单的应用程序，露出一个基于LINQ的接口（例如一个IQueryable GETALL（）），可以再有凡适用条款。根据YMMV上，一个基本的持久性，但它是如此简单的应用稳固射击，ESP。如果你希望你的持久性提供直接支持LINQ。

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.

最后，很多人实际上通过一个implentation或其他命令查询责任分离模式，它说，对坚持和查询的接口应该是不同的分离出查询部分。在这种情况下，你不得不说只是有基本的CRUD回购（GetById，GETALL，保存，删除），OPS和其他类某种根据您的应用程序的意图哪些查询的东西。

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.

希望有所帮助。

保

这篇关于MVC模式库的设计决策的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！