相关疑难解决方法(0)

我的印象是DbContext意味着代表你的数据库,因此,如果你的应用程序使用一个数据库,你只需要一个DbContext.但是,有些同事希望将功能区域分解为单独的DbContext类.我相信这来自一个好地方 - 希望保持代码清洁 - 但它似乎不稳定.我的直觉告诉我这是一个坏主意,但不幸的是,我的直觉并不是设计决策的充分条件.

所以我正在寻找A)为什么这可能是一个坏主意的具体例子,或B)保证这一切都很好.

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

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

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

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

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

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

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

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

我有自己的存储库,如下所示.但是,这并未考虑一些新功能,例如范围功能.有没有人有一个包含所有内容的存储库.我在网上搜索过这个,但是我找不到最新的东西.这就是我所拥有的.我希望有更多的东西,并提供许多方法的IQueryable:

namespace Services.Repositories
{
    /// <summary>
    /// The EF-dependent, generic repository for data access
    /// </summary>
    /// <typeparam name="T">Type of entity for this Repository.</typeparam>
    public class GenericRepository<T> : IRepository<T> where T : class
    {
        public GenericRepository(DbContext dbContext)
        {
            if (dbContext == null) 
                throw new ArgumentNullException("An instance of DbContext is required to use this repository", "context");
            DbContext = dbContext;
            DbSet = DbContext.Set<T>();
        }

        protected DbContext DbContext { get; set; }

        protected DbSet<T> DbSet { get; set; }

        public virtual IQueryable<T> Find(Expression<Func<T, …