【发布时间】:2018-03-27 22:02:48
【问题描述】:
我们正准备对一个大型企业应用程序进行模块化,该应用程序目前正在使用濒临死亡的技术堆栈。我的问题是在存储库/工作单元模式中,一个工作单元中可以有多少个存储库?例如,我们在一个 DbContext 上创建一个 UnitOfWork,它公开了 50 多个存储库实体。这会导致性能问题吗?
我们正在考虑将其拆分,以便每个模式都有自己的 DbContext,但这似乎增加了很多复杂性,并且不允许在模式之间轻松连接数据。我觉得在一个上下文/工作单元下创建所有内容是易用性和可维护性的最佳答案,但我担心性能可能是一个问题。
public class UnitOfWork : IUnitOfWork
{
private readonly AppContext _context;
public UnitOfWork(AppContext context)
{
_context = context;
Courses = new CourseRepository(_context);
Authors = new AuthorRepository(_context);
...
...
// Will lots of repositories here cause a performance problem?
...
...
...
...
...
}
public ICourseRepository Courses { get; private set; }
public IAuthorRepository Authors { get; private set; }
...
...
public int Complete()
{
return _context.SaveChanges();
}
public void Dispose()
{
_context.Dispose();
}
}
【问题讨论】:
-
您不应该在
Entity Framework中使用UoW和Repository模式。 EF 已经实现了这些模式。 -
确实如此,但在大型企业应用程序中,存储库/UoW 模式仍然可以用于创建一个代理层,封装所有处理 ORM 的代码,这样应用程序就不会直接暴露给 ORM .这创建了非常清晰的关注点分离,允许在不更改任何应用程序代码的情况下更轻松地过渡到另一个 ORM。
标签: asp.net-mvc entity-framework repository unit-of-work