使用entity framework使用存储库和单元工作模式正确处置？
干杯！我对使用工作单元和存储库有些怀疑。 特别是来自Entity Framework的子上下文的角色。 我已经搜索了很多关于这个主题的信息，但是我发现只是不同类型的使用模式，我很困惑，我无法理解主要思考。
1.我应该在哪里实现处置和储蓄？ – 它是否在DbContext的inheritance类中正确实现了Disposable？ 之后在存储库和工作单元中实现还是只在Uni fo工作中实现？
– 把方法保存在工作单元或存储库中？
我的存储库将是Generic我的代码在架构师风格和其他细节方面是否正确？请告诉我的想法是否错误。
interface IRepository : IDisposable { void Create(); void Delete(); void Update(); void Get(); T getSomeByExpression() ...Some another costum operations ...should I remember about Save here? } class Repository : IRepository { SomeContext context = new SomeContext(); ...Using using(context = new SomeContext()){} in functions?? ... ....Disposing? } interface IUnitOfWork : IDisposable { ...Which methods I should realize? Commit() Save() ...Need some another methods like rollback, Attach() Add() or Dispose or something else? } class UnitOfWork { ...Collection of Repository } 在Logic级别的工作单元之后使用？ 请帮我理解这个主题。
我想知道，如何正确使用工作单元和存储库模式，特别是包括DBContext.Also我想知道在哪里使用像Dispose这样的操作。 通常应该在UnitOfWork中执行哪些操作，保存等。如何在存储库中处理上下文？
这是一篇关于使用MVC实现工作单元的精彩文章 。
我通常在业务交易完成后处置该单元。 例如，如果操作是创建一个父项，一些子项并附加它们，我会在完成后立即处理。
添加了与上述相关的更多细节：
在重读你的问题时，听起来你想要更多关于工作单元理论的信息，而不是实际的实现，我的道歉。
这是与MSDN相关的更好的文章，但我将为您总结。
根据Martin Fowler的说法，工作单元模式“维护一个受业务事务影响的对象列表，并协调写入更改和解决并发问题。”
通常，我使用工作单元模式将所有相关的存储库集合在一起，以解决并发问题，同时仍然保持存储库分离。
使用工作单元模式的最佳方法之一是允许不同的类和服务参与单个逻辑事务。 这里的关键点是，您希望不同的类和服务在能够在单个事务中登记时保持彼此无知。
- “我应该在哪里实现处置和储蓄？”
我不确定我是否完全理解你的问题，但我认为你在问什么应该管理工作单元的生命周期？
这是与此相关的另一个SOpost ，但摘要是当前拥有工作单元的任何内容，它与您如何设置工作单元的范围有关。 例如，它可以是业务命令或MVC操作。
- “它是否在DbContext的inheritance类中正确实现了Disposable？之后在Repository和Unit of Work中实现，还是只在Uni fo工作中实现？”
你的意思是，你应该在哪里处理DbContext？ 我认为它应该属于工作单元。 如果您在一个工作单元中创建/处理多个上下文，也许您应该将它们分成两个不同的单元。
- put方法保存在工作单元或存储库中？
您的工作单元处理上下文和事务，并且应包含防止重复更新的逻辑，因此您的保存function应由您的工作单元控制。