标签：c asp-net-mvc entity-framework-5

这是关于我从这里找到的一些实体框架材料的一些混淆：
https://www.asp.net/

在本页中,它解释了如何使用存储库包装dbcontext并使用工作类单元包装存储库：
http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

但是,在此页面上,它指出dbcontext已经是UOW模式和存储库模式的组合：
https://msdn.microsoft.com/en-us/library/system.data.entity.dbcontext(v=vs.103).aspx

因此,如果dbcontext已经解决了这些模式解决的问题,为什么要用EF5重新实现这些模式呢？

此外,在本教程中,UnitOfWork类似乎没有显示UOW应该给出的任何好处.例如,它声明：“这样,当一个工作单元完成后,您可以在该上下文实例上调用SaveChanges方法,并确保所有相关更改都将得到协调.”

但它似乎只是无缘无故地包装dbcontext.我想我错过了什么.我没有看到在这个实现中有任何协调……如果出现问题,事情如何“回滚”？

解决方法:

不要使用其他UoW /存储库抽象层

正如OP正确指出的那样,Entity Framework(类似于NHibernate和其他ORM)已经为您提供了数据库的抽象,同时提供了可供您使用的事务“工作单元”和“存储库”.

额外的UoW /存储库抽象层是反模式,应该不惜一切代价避免.它有很多问题,其中最重要的是：

>它们阻止您使用底层ORM的全部功能(延迟加载,急切加载,复杂查询……)
>如果他们想要提供除简单CRUD之外的任何额外好处,它们将会泄漏(即反映基础ORM中存在的功能).

但是,但是,但……

I need to be able to unit test by mocking my repositories

不,你没有.只需使用具有针对您的测试的特定内容的数据库.如果您希望更快,请使用内存数据库(例如SQLite,Effort,…).

EF does not enforce business logic which is not expressed in data relationships … To enforce this type of logic, you have to build a OUW/Repository/both of some sort around the EF context.

不,你不应该.在基础架构抽象层(例如工作单元或存储库)中实现业务逻辑是完全错误的.

>有价值的业务逻辑属于域实体,域服务,域命令或长期运行的业务流程,sagas.
>简单验证(即非空,x和y之间的值)不会：那些应该在系统接口边界处解决.

还要注意,没有任何有价值的业务逻辑的简单CRUD样式操作不需要经历所有“层箍”,即避免这种模式：

>数据库→无行为的实体→DTO→查看模型→查看
>编辑字段
>查看→查看模型→DTO→无行为的实体→数据库

只需从控制器中的ORM直接加载视图所需的“视图模型”形状,然后直接从控制器中保存.

关于抽象

不必要的抽象和诸如此类的层层箍是邪恶的.它们会混淆您的代码,绑定您的手,泄漏,增加代码大小,从而增加代码中的错误数量,而不会提供任何附加值.

当它们为您提供附加值时使用抽象,例如当您需要它们来解决跨领域问题时,捕获/管理架构中的重复模式,……

为抽象而创建抽象是浪费时间.

标签：c,asp-net-mvc,entity-framework-5
来源： https://codeday.me/bug/20190628/1317411.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。