按照http://martinfowler.com/eaaCatalog/unitOfWork.html这篇文章的介绍,UnitOfWork是为了维护对象的变化,A Unit of Work keeps track of everything you do during a business transaction that can affect the database。如果是这样的花,对于ef来说,继承DbContext类都可以看作是unit of work,而dbset<>可以看作是repository, 最终都通过savechanges来完成所有变化的持久化。
如果项目只是用EF,不考虑以后使用其他ORM的可能的话,个人认为没有必要使用unitofwork.对于EF来说本身就实现了这部分功能。
如果考虑今后变化的可能,那需要自己来实现IunitOfWork 和 IRepository 来应对今后的变化,实现对ORM的解耦。
类似的,对于使用的IOC,来说,为了应对未来的变化,也可以有类似的思考,比如有当前使用的autofac,转为使用其他的IOC容器。Common Service Locator就是为了应对这种变化,在IOC容器和Service LOcator 之上抽象的一个类库。实现对IOC容器的解耦
【推荐】还在用 ECharts 开发大屏?试试这款永久免费的开源 BI 工具!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步