在使用ORM解决方案的ASP.NET MVC中工作时，是否需要使用Repository模式？ [英] Do we need to use the Repository pattern when working in ASP.NET MVC with ORM solutions?
问题描述
DbContext 和 DbSet< T> 以及NHibernate中的 ISession 。 Repository 模式中提到的大部分问题，如 POEE 和 DDD - 由这些ORM充分实施。就是这些担心是， - 持久性
- OO数据视图
- 数据访问逻辑抽象
- 查询访问逻辑
此外，大多数我已经看到的存储库模式的实现遵循这种实现模式 - 假设我们正在开发一个博客应用程序。
NHibernate实现：
public class PostRepository：IPostRepository
{
private ISession _session;
public PostRepository（ISession session）
{
_session = session;
}
public void Add（Post post）
{
_session.Save（post）;
}
//其他crud方法。
}
实体框架：
public class PostRepository：IPostRepository
{
private DbContext _session;
public PostRepository（DbContext session）
{
_session = session;
}
public void Add（Post post）
{
_session.Posts.Add（post）;
-session.SaveChanges（）;
}
//其他crud方法。
}
在我看来，当我们使用ORM时，如Nhibernate或Entity框架 - 创建这些存储库实现是多余的。此外，由于这些模式实现不仅仅是ORMS中已经存在的模式，所以这些操作比有用的OO抽象更像是 noise 。在上述情况下，似乎使用存储库模式只不过是开发人员自我扩大，而且没有任何可实现的技术优势。你的想法是什么？
答案是否，如果你不需要切换ORM或者可以测试任何对ORM /数据库具有依赖关系的类。
如果您想要切换ORM或者能够轻松测试您使用数据库层的类：是的，您需要一个存储库（具有接口规范）。
您还可以切换到内存仓库（我在我的单位测试），一个XML文件，或者如果您使用存储库模式，或者其他任何内容。
更新
Googling可以找到的大多数存储库模式实现的问题是它们在生产中的工作不尽如人意。他们缺乏限制结果（分页）和排序结果的选项，这是一个惊人的。
当与UnitOfWork实现结合使用时，存储库模式将成为荣耀，并具有支持规范模式。
如果你发现有一个，请告诉我:)（我有一个很好的工作规范部分的例外）
更新2
资源库不仅仅是访问数据库一个抽象的方式，如ORM可以完成。正常的Repository实现应该处理所有聚合实体（例如 Order 和 OrderLine ）。在同一个存储库类中处理它们，您可以随时确保这些库正确构建。
但是，您可以这样说：ORM会自动为我完成。那么是的，没有。如果你创建一个网站，你最有可能只编辑一个订单行。您是否获取完整的订单，循环查找订单，然后将其添加到视图？
通过这样做，您可以向您的控制器介绍不需要的逻辑属于那里当一个webservice想要一样的东西，你怎么做？复制你的代码？
通过使用ORM，从任何地方获取任何实体非常简单，例如myOrm.Fetch< User>（user => user .Id == 1）修改它，然后保存。这可以非常方便，但是由于您重复代码并且无法控制对象的创建方式（如果它们具有有效的状态或正确的关联），则会添加代码气味。
接下来要想到的是，您可能希望能够以集中的方式订阅创建，更新和删除等事件。如果您有一个存储库，那就很容易。
对于我来说，ORM提供了一种将类映射到表的方法，而没有更多。我仍然希望将它们包装在知识库中以控制它们，并获得一个修改点。
I am bit curious as to what experience other developers have of applying the Repository pattern when programming in ASP.NET MVC with Entity Framework or NHibernate. It seems to me that this pattern is already implemented in the ORM themselves. DbContext and DbSet<T> in the Entity Framework and by the ISession in NHibernate. Most of the concerns mentioned in the Repository pattern - as catalogued in POEE and DDD - are pretty adequately implemented by these ORMs. Namely these concerns are,
- Persistence
- OO View of the data
- Data Access Logic Abstraction
- Query Access Logic
In addition, most of the implemententations of the repository pattern that I have seen follow this implementation pattern - assuming that we are developing a blog application.
NHibernate implementation:
public class PostRepository : IPostRepository
{
private ISession _session;
public PostRepository(ISession session)
{
_session = session;
}
public void Add(Post post)
{
_session.Save(post);
}
// other crud methods.
}
Entity Framework:
public class PostRepository : IPostRepository
{
private DbContext _session;
public PostRepository(DbContext session)
{
_session = session;
}
public void Add(Post post)
{
_session.Posts.Add(post);
-session.SaveChanges();
}
// other crud methods.
}
It seems to me that when we are using ORMs - such as Nhibernate or Entity Framework - creating these repository implementation are redundant. Furthermore since these pattern implementations does no more than what is already there in the ORMS, these act more as noise than helpful OO abstractions. It seems using the repository pattern in the situation mentioned above is nothing more than developer self aggrandizement and more pomp and ceremony without any realizable techical benefits. What are your thoughts ??
The answer is no if you do not need to be able to switch ORM or be able to test any class that has a dependency to your ORM/database.
If you want to be able to switch ORM or be able to easily test your classes which uses the database layer: Yes you need a repository (with an interface specification).
You can also switch to a memory repository (which I do in my unit tests), a XML file or whatever if you use repository pattern.
Update
The problem with most repository pattern implementations which you can find by Googling is that they don't work very well in production. They lack options to limit the result (paging) and ordering the result which is kind of amazing.
Repository pattern comes to it's glory when it's combined with a UnitOfWork implementation and has support for the Specification pattern.
If you find one having all of that, let me know :) (I do have my own, exception for a well working specification part)
Update 2
Repository is so much more than just accessing the database in a abstracted way such as can be done by ORM's. A normal Repository implementation should handle all aggregate entities (for instance Order and OrderLine). Bu handling them in the same repository class you can always make sure that those are built correctly.
But hey you say: That's done automatically for me by the ORM. Well, yes and no. If you create a website, you most likely want to edit only one order line. Do you fetch the complete order, loop through it to find the order, and then add it to the view?
By doing so you introduce logic to your controller that do not belong there. How do you do it when a webservice want's the same thing? Duplicate your code?
By using a ORM it's quite easy to fetch any entity from anywhere myOrm.Fetch<User>(user => user.Id == 1) modify it and then save it. This can be quite handy, but also add code smells since you duplicate code and have no control over how the objects are created, if they got a valid state or correct associations.
The next thing that comes to mind is that you might want to be able to subscribe on events like Created, Updated and Deleted in a centralized way. That's easy if you have a repository.
For me an ORM provides a way to map classes to tables and nothing more. I still like to wrap them in repositories to have control over them and get a single point of modification.
这篇关于在使用ORM解决方案的ASP.NET MVC中工作时，是否需要使用Repository模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
