在开发 ASP.Net MVC 项目时，似乎有许多指南在推动将实体框架与存储库和工作单元模式一起使用。
快速浏览 Google 会产生无数关于这种方法的优缺点的讨论，虽然那些反对在 EF 中使用这些模式的人大声疾呼，但我还没有看到任何人详细说明一个好的替代方案。
在控制器类中直接访问 EF 的不足之处是数据访问层的另一种方法是什么？
【问题讨论】：
标签： c# asp.net-mvc entity-framework repository
我过去经常使用存储库；我认为它们是自切片面包以来最好的东西。
但是，随着时间的推移和经验的积累，我不再使用存储库模式。我的 repo 类最终不可避免地被许多方法所阻塞，其中许多方法几乎模仿了存储过程，例如..g
customerRepo.GetCustomerWithFooBar();
sp_GetCustomerWithFooBar
我本身并没有刻意寻找替代方案，但我最终使用了两种方法中的一种。
这看起来很乱，但它降低了抽象级别。但是，随着我的项目和代码变得越来越大，这种方法就不是那么可维护了。所以我尝试了...
CQS（命令查询分离） 这个想法是让类执行命令和其他执行查询的类。例如
公共类 SaveCustomerCommand(){}
公共类 ListCustomerQuery(){}
这样，我能够很好地将我的 Entity Framework 代码抽象为两类 - 更改数据的类和简单读取数据的类。不幸的是，我从未完成我尝试过这种方法的代码，但您可以考虑编写一个CommandDispatcher 类，该类接受命令/查询、新的 UnitOfWork 对象（无论您如何实现）并控制 command.Execute() 和查询.Execute()。
有一些文章可以帮助您开始使用方法 2。
http://alertcoding.wordpress.com/2013/03/17/command-and-query-based-entity-framework-architecture/
【讨论】：