标签: unit-of-work

随着我深入研究DbContext,DbSet和相关接口,我想知道为什么你需要围绕这些实现实现一个单独的"通用"存储库？

它看起来像DbContext和IDbSet做你需要的一切,并在DbContext中包含"工作单元".

我在这里遗漏了什么,或者似乎人们喜欢无缘无故地添加另一层依赖.

结合Unit of Work并且Repository Pattern是现在相当广泛使用的东西.正如Martin Fowler 所说,使用的目的UoW是形成商业交易,同时不知道存储库实际如何工作(持续无知).我已经回顾了很多实现; 并忽略具体细节(具体/抽象类,接口,......),它们或多或少类似于以下内容:

public class RepositoryBase<T>
{
    private UoW _uow;
    public RepositoryBase(UoW uow) // injecting UoW instance via constructor
    {
       _uow = uow;
    }
    public void Add(T entity)
    {
       // Add logic here
    }
    // +other CRUD methods
}

public class UoW
{
    // Holding one repository per domain entity

    public RepositoryBase<Order> OrderRep { get; set; }
    public RepositoryBase<Customer> CustomerRep { get; set; }
    // +other repositories …

我即将实现一个带有存储库和工作单元的Entity Framework 6设计.

有太多的文章,我不知道最好的建议是什么:例如我真的喜欢这里实现的模式:由于这里的文章建议的原因

但是,Tom Dykstra (Senior Programming Writer on Microsoft's Web Platform & Tools Content Team)建议它应该在另一篇文章中完成:这里

我订阅了Pluralsight,并且它在每次在课程中使用时都以稍微不同的方式实现,因此选择设计很困难.

有些人似乎认为工作单元已经DbContext在这篇文章中实现,所以我们根本不需要实现它.

我知道之前已经提出过这类问题,这可能是主观的,但我的问题是直接的:

我喜欢第一篇(Code Fizzle)文章中的方法,并想知道它是否可能更易于维护,并且可以像其他方法一样容易测试并且可以安全地继续使用？

任何其他观点都非常受欢迎.

几天前,我遇到了ASP.Net线程的这个问题.我希望每个Web请求都有一个单例对象.我的工作单位实际上需要这个.我想为每个Web请求实例化一个工作单元,以便身份映射在整个请求中有效.这样我就可以使用IoC透明地将我自己的IUnitOfWork注入到我的存储库类中,并且我可以使用相同的实例来查询然后更新我的实体.

由于我使用Unity,我错误地使用了PerThreadLifeTimeManager.我很快意识到ASP.Net线程模型不支持我想要实现的目标.基本上它使用theadpool并回收线程,这意味着每个线程我得到一个UnitOfWork!但是,我想要的是每个Web请求的一个工作单元.

一些谷歌搜索给了我这个伟大的帖子.这正是我想要的; 除了非常容易实现的统一部分.

这是我对PerCallContextLifeTimeManager实现统一的实现:

public class PerCallContextLifeTimeManager : LifetimeManager
{
    private const string Key = "SingletonPerCallContext";

    public override object GetValue()
    {
        return CallContext.GetData(Key);
    }

    public override void SetValue(object newValue)
    {
        CallContext.SetData(Key, newValue);
    }

    public override void RemoveValue()
    {
    }
}

当然,我使用它来使用与此类似的代码注册我的工作单元:

unityContainer
            .RegisterType<IUnitOfWork, MyDataContext>(
            new PerCallContextLifeTimeManager(),
            new InjectionConstructor());

希望能节省一些时间.

我想创建一个环绕在类似的方式对存储库工作类的单元此.

我遇到的问题是尝试通过用IRepository接口替换示例中的通用存储库来实现依赖注入.在链接文章中的uow中,他们使用getter来检查存储库是否被实例化,如果不是,则实例化它.

public GenericRepository<Department> DepartmentRepository
{
    get
    {
        if (this.departmentRepository == null)
        {
            this.departmentRepository = new GenericRepository<Department>(context);
        }
        return departmentRepository;
    }
}

这是强烈耦合的.

我可以通过两种方式看到这一点.

1. 使用构造函数注入.
2. 使用setter注入.

1的问题是,如果我注入所有存储库,我必须实例化每个存储库,即使我不在特定的工作单元实例中使用它们.因此招致了这样做的开销.我想象使用一个数据库范围的工作单元,这会导致很多不必要的实例化和一个巨大的构造函数.

2的问题是很容易忘记设置和结束空引用异常.

在这种情况下是否有任何最佳实践？还有其他我错过的选择吗？

我刚刚进入依赖注入,并完成了我可以找到的关于该主题的所有研究,但我可能会遗漏一些关键.

根据MSDN,DbContext定义为:

表示工作单元和存储库模式的组合,使您可以查询数据库并将更改组合在一起,然后将这些更改作为一个单元写回到存储中.

既然DbContext实现了工作单元和存储库模式,那么为什么我在Internet上找到的ASP.NET教程和其他资源演示了如何使用DbContext工作单元和存储库模式的自定义实现？这不是多余的吗？

如果没有,使用时创建工作单元和存储库层的自定义实现有什么好处DbContext？(我可以看到这在测试项目中是如何有意义的.)

目前,我正在尝试使用Dapper ORM与工作单元+存储库模式.

我想使用工作单元而不是简单的dapper存储库,因为我的插入和更新需要一定程度的事务处理.我一直无法找到任何有用的例子,因为大多数似乎使用实体框架并且在工作单元内存在泄漏问题.

有人可以指点我正确的方向吗？

我正在使用Entity Framework 6学习ASP.NET MVC 5应用程序中的存储库和工作单元模式.

我已经阅读了很多教程和文章,但几乎所有教程和文章都是相同的.其他人说,存储库和工作单元模式是好的,其他人说DbContext已经是一个存储库和工作单元,其他人说类似的东西,但提供了一种完全不同的方法.我尝试了所有这些不同的方法(好吧,也许不是全部)并且仍然在努力确定哪种方法是最正确的方法.

我现在拥有的是:

• 实现IRepository的IRepository和GenericRepository
• IUnitOfWork和UnitOfWork实现IUnitOfWork
• IDbContext和MyDbContext继承自IdentityDbContext并实现IDbContext

不确定我是否需要粘贴它的代码,我认为这是非常通用的,问题实际上不是Repository/UnitOfWork.我遇到的问题是将ASP.NET Identity类与我的存储库和工作单元结合使用.我正在为成员资格和所有其他数据共享相同的数据库 - 我认为这是一种常见的情况.我找不到好的解决方案如何使用我的存储库实例化ASP.NET Identity类.

UserStore<ApplicationUser> store = new UserStore<ApplicationUser>(_DBCONTEXT_);
this.UserManager = new UserManager<ApplicationUser>(store);

我应该用什么代替DBCONTEXT,以便它与我的UnitOfWork共享相同的DbContext？或者如何以其他方式完成使ASP.NET身份与UnitOfWork一起工作？

我尝试将DbContext暴露为UnitOfWork类的公共属性,如:

UserStore<ApplicationUser> store = new UserStore<ApplicationUser>(this.unitOfWork.MyDbContext);

但是我不认为它是正确的 - 它不适用于自定义IDbContext接口,并使代码不适合单元测试.

我也试图实现CustomUserStore和CustomRoleStore - 通常它可以工作,但是当我测试它时,它需要实现越来越多的方法.这个解决方案看起来太复杂了 - 我真的希望应该有更简单的方法.

创建一个新的MVC项目,并喜欢数据层中的存储库的想法,所以我已经实现了它们.我还创建了一个Service层来处理所有业务逻辑和验证,该层依次使用适当的存储库.像这样的东西(我使用Simple Injector注入)

DAL LAYER

public class MyRepository {

    private DbContext _context;
    public MyRepository(DbContext context) {
        _context = context;
    }    

    public MyEntity Get(int id)
    {
        return _context.Set<MyEntity>().Find(id);
    }

    public TEntity Add(MyEntity t)
    {
        _context.Set<MyEntity>().Add(t);
        _context.SaveChanges();
        return t;
    }

    public TEntity Update(MyEntity updated, int key)
    {
        if (updated == null)
            return null;

        MyEntity existing = _context.Set<MyEntity>().Find(key);
        if (existing != null)
        {
            _context.Entry(existing).CurrentValues.SetValues(updated);
            _context.SaveChanges();
        }
        return existing;
    }

    public void Delete(MyEntity t)
    {
        _context.Set<MyEntity>().Remove(t);
        _context.SaveChanges();
    }
}

服务层

public class MyService {
    private …

尽管这样的问题被多次询问,我仍在努力理解存储库和工作单元模式之间的关系.基本上我还是不明白哪个部分会保存/提交数据更改 - 存储库或工作单元？

由于我看到的每个例子都与使用这些和数据库/ OR映射器有关,所以让我们做一个更有趣的例子 - 让数据保存在数据文件中的文件系统中; 根据模式,我应该能够做到这一点,因为数据的去向与此无关.

所以对于一个基本实体:

public class Account
{
    public int Id { get; set; }
    public string Name { get; set; }
}

我想会使用以下接口:

public interface IAccountRepository
{
     Account Get(int id);
     void Add(Account account);
     void Update(Account account);
     void Remove(Account account);
}

public interface IUnitOfWork
{
    void Save();
}

我认为在使用方面它看起来像这样:

IUnitOfWork unitOfWork = // Create concrete implementation here
IAccountRepository repository = // Create concrete implementation here

// Add a new account
Account account = new Account() …