在开发 ASP.Net MVC 项目时，似乎有许多指南插入将 Entity Framework 与存储库和工作单元模式一起使用。
快速 Google 一下，就该方法的优点和缺点进行了无数讨论，虽然那些反对在 EF 中使用这些模式的人直言不讳，但我还没有看到任何人详细介绍一个好的替代方案。
除了在 Controller 类中直接访问 EF 之外，数据访问层的另一种方法是什么？
最佳答案
我过去经常使用存储库；我认为它们是自切片面包以来最好的东西。
但是，随着时间的推移和经验的积累，我停止使用存储库模式。我的存储库类不可避免地最终被许多方法堵塞，其中许多方法几乎模仿了存储过程，例如
customerRepo.GetCustomerWithFooBar();
sp_GetCustomerWithFooBar
我本身并没有刻意寻找替代方案，但最终我使用了两种方法之一。
- Entity Framework 上下文 我只是针对上下文对象本身进行编码；运行 LINQ 查询以及通常的 SaveChanges() 类型的东西。
这看起来很困惑，但它降低了抽象级别。但是，随着我的项目和代码变得越来越大，这种方法就不那么可维护了。所以我尝试了...
CQS(命令查询分离) 这个想法是拥有执行命令的类和执行查询的其他类。例如
公共(public)类 SaveCustomerCommand(){}
公共(public)类 ListCustomerQuery(){}
这样，我就能够很好地将 Entity Framework 代码抽象为两类 - 更改数据的类和仅读取数据的类。不幸的是，我从未完成尝试这种方法的代码，但您可以考虑编写一个 CommandDispatcher 类，该类接受命令/查询、new 的 UnitOfWork 对象(无论您如何实现)并控制命令.Execute() 和 query.Execute()。
有一些文章可以帮助您启动并运行方法 2。
http://alertcoding.wordpress.com/2013/03/17/command-and-query-based-entity-framework-architecture/
关于c# - 使用存储库替代 Asp.net MVC，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25504242/