Repository个人实践

1、背景

　　最近，有空了，想着把之前一些乱七八糟的小项目给整理一下，尤其是涉及到Repository、UoW几处。为此，专门查阅了博客园中几个大神 关于Repository的实践，到最后都感觉依然莫衷一是，于是感觉这玩意儿不能深究，自己还是紧扣Martin老爷子关于Repository及UoW的核心定义，自己实践核心概念就是了，其他的都不重要了。

2、整个项目架构

红框框起来的部分，就是关于Repository的那些部分，其中，Account.Infrustructure.Contract和Account.Infrusture.EF是核心，可以跨解决方案或工程存在，前者是Repository基础契约定义，后者是该契约基于EF的实现。接下来，分别就两部分实现详细说明。

3、Repository、UoW核心实现

先看Repository核心契约的定义：

很简单，一个基于netstandard的类库，其中就两个接口定义，分别对应Repository和UoW的核心概念，IRepository的定义如下：

public interface IRepository
    {
    }

    /// <summary>
    /// Repository标记接口
    /// </summary>
    public interface IRepository<TEntity> : IRepository
        where TEntity : class
    {
        IQueryable<TEntity> Get(
            Expression<Func<TEntity, bool>> filter = null,
            Func<IQueryable<TEntity>, IOrderedQueryable<TEntity>> orderBy = null,
            string includeProperties = "");

        TEntity GetByID(object id);

        void Insert(TEntity entity);

        void Delete(object id);

        void Delete(TEntity entityToDelete);

        void Update(TEntity entityToUpdate);

        void Save();
    }

非泛型空接口IRepository用来标记仓储，是面向接口编程中很常见的做法，这个待会我们会在使用环节进一步说明。泛型IRepository接口用来规范所有仓储都应该具有的基础增删查改方法，这里有2点需要注意：

1）方法返回类型为IQueryable，目的是延迟查询，用过类似EF的ORM的应该都知道；

2）接口有个泛型参数TEntity，很明显，是要每个实体对应一个Repository实现的将来。

接下来再看UoW契约的定义：

public interface IUnitOfWork
    {
        DbTransaction BeginTransaction();

        void CommitTransaction();

        void RollbackTransaction();
    }

这个契约更简单，因为我给其的职责，就只有将多个操作纳入统一事务并有效管理。这已经足够实现Martin老爷子关于UoW的核心概念了。

之后，我们看看IRepository、IUoW的基于EF的实现：

可以看见，也很简单，就是基于契约基础工程中的两个接口的实现，整个类库也是基于standard的。

IUnityOfWork的实现如下：

public class EFUnitOfWork : IUnitOfWork
    {
        private readonly DbContext _context;

        public EFUnitOfWork(DbContext context)
        {
            _context = context;
        }

        public DbTransaction BeginTransaction()
        {
            _context.Database.BeginTransaction();

            return _context.Database.CurrentTransaction.GetDbTransaction();
        }

        public void CommitTransaction()
        {
            _context.SaveChanges();
            _context.Database.CommitTransaction();
        }

        public void RollbackTransaction()
        {
            _context.Database.RollbackTransaction();
        }
    }

大家注意工作单元中用到的上下文，很明显，DBContext是基于EF的数据上下文的，而且，一般，我们具体项目中才用到的上下文，都是SchoolDBContext之类的，那么这里如何注册进来呢？如果是自定义系统服务，直接Registet<XXDbContext>().As<DbContext>()就成了（如果Autofac的话），问题是我们注入上下文时候，是类似这样：

services.AddDbContext<AccountContext>(options =>
                     options.UseMySql(Configuration.GetConnectionString("DefaultConnection")));

翻遍了EF的AddDBContext的重载，也没发现可以注册为DBContext的实现啊，怎么整。。。答案来了，这里有个小技巧，既然我们都明白，自定义服务是可以注册为接口或基类的，那这里我们把XXXDBContext也当做自定义服务来注册，你前面不是EF标准注册了XXDBContext了么，好，下一步，我就再把XXDBContext注册为DBContext，无非控制下生命周期就成，具体实现如下：

 services.AddDbContext<AccountContext>(options =>
                     options.UseMySql(Configuration.GetConnectionString("DefaultConnection")));
            services.AddScoped<DbContext>(provider => provider.GetService<AccountContext>());

上述操作是在Startup中完成的。注意，这一步比较重要，因为它直接决定了你EFUnityOfWork中是否能接收到DBContext，不这样做，你就得在EFUnityOfWork中直接接受XXDBContext了，那还谈何抽象，还谈何基础架构。。。

接下来，再看EF基础实现中Repository的实现，如下：

public abstract class Repository<TEntity> : IRepository<TEntity>
        where TEntity : class
    {
        protected DbContext Context;
        protected DbSet<TEntity> DbSet;

        public Repository(DbContext context)
        {
            this.Context = context;
            this.DbSet = context.Set<TEntity>();
        }

        public virtual IQueryable<TEntity> Get(
            Expression<Func<TEntity, bool>> filter = null,
            Func<IQueryable<TEntity>, IOrderedQueryable<TEntity>> orderBy = null,
            string includeProperties = "")
        {
            IQueryable<TEntity> query = this.DbSet;

            if (filter != null)
            {
                query = query.Where(filter);
            }

            foreach (var includeProperty in includeProperties.Split
                (new char[] { ',' }, StringSplitOptions.RemoveEmptyEntries))
            {
                query = query.Include(includeProperty);
            }

            if (orderBy != null)
            {
                return orderBy(query);
            }
            else
            {
                return query;
            }
        }

        public virtual TEntity GetByID(object id)
        {
            return DbSet.Find(id);
        }

        public virtual void Insert(TEntity entity)
        {
            DbSet.Add(entity);
        }

        public virtual void Delete(object id)
        {
            TEntity entityToDelete = DbSet.Find(id);
            Delete(entityToDelete);
        }

        public virtual void Delete(TEntity entityToDelete)
        {
            if (Context.Entry(entityToDelete).State == EntityState.Detached)
            {
                DbSet.Attach(entityToDelete);
            }
            DbSet.Remove(entityToDelete);
        }

        public virtual void Update(TEntity entityToUpdate)
        {
            DbSet.Attach(entityToUpdate);
            Context.Entry(entityToUpdate).State = EntityState.Modified;
        }

        public void Save()
        {
            this.Context.SaveChanges();
        }
    }

　　这个很简单，无非就是你平时写的直接基于XXDBContext的CRUD给抽象一下，泛型一下，然后蒸到这里来。注意最后边的那个save，有些实践中会把save直接整到UoW里边去，我没有，因为我对UoW的唯一期望就是，管理好事务，不涉及到事务的情况下，应用服务层连UoW的影子都不要出现，有Repository就够了，那就涉及到简单CUD的保存，尤其是像基于EF的这种实现中，还他妈必须savechanges才行。。。这里特别说明，可能save放这里并不合适，因为有些orm犯不着必须save才行，在非事务的情况下，比如Dapper，再比如Chloe，所以这里可以更进一步优化或抽象。只能说，fuck EF，非事务性写操作，你给我直接写库不就完了。。。

　　大家注意，这里既然这里抽象出了Account.Infrustructure.Contract，以及有了Account.Infrustructure.EF的实现，以及我上边说了那么多各ORM关于save的不同，你就应该想到，抽象的目的，是为了切换ORM准备的，假如我想切换为Chloe的实现，那么很简单，改动只需要3处：

1）startup中EFDBContext的注册改为Chole Context的注册，如MsSqlContext；

2）ChloeUnityOfWork实现IUnitOfWork，构造函数中传入IDbContext，下面的方法实现切换为MsSQLContext的相关事务操作；

3）Repository中DBContext切换为IDBContext，对应的CRUD及save切换为基于IDBContext的实现（其实Chloe根本他妈就不需要save。。。）；

上述IDbContext是Chloe的数据上下文，用过的应该清楚。另外，涉及到多ORM或切换ORM，直接更改不推荐，锅锅们，面向对象或者抽象的目的，不是为了改动，而是为了扩展，我上边只是为了说明要基于其他ORM去实现，非常简单而已，正确做法是，直接新建Account.Infrustructure.Chloe工程，然后实现两个契约接口，跟EF的实现简直大同小异。

4、应用

基础架构定义好了，接下来就是我们仓储层的具体应用，这里以一个简单的ManifestRepository为例看下如何实现：　　

public class ManifestRepository : Repository<Manifest>, IManifestRepository
    {

        public ManifestRepository(AccountContext context)
            :base(context)
        {
        }

        public async Task<PaginatedList<Manifest>> GetManifests(DateTime start, DateTime end, int pageIndex, int pageSize)
        {
            var source = DbSet.Where(x => x.Date >= start && x.Date < new DateTime(end.Year, end.Month, end.Day).AddDays(1));
            int count = await source.CountAsync();
            List<Manifest> manifests = null;
            if (count > 0)
            {
                manifests = await source.OrderBy(x => x.Date).Skip((pageIndex - 1) * pageSize).Take(pageSize).ToListAsync();
            }

            return new PaginatedList<Manifest>(pageIndex, pageSize, count, manifests ?? new List<Manifest>());
        }
    }　　

 典型的，继承基类泛型实现获取基本CRUD方法，这里多了一个，是因为这个查询相对复杂，如果实际项目中，没有这种复杂查询，或者这种查询只出现一次，实际上没必要在ManifestRepository里边抽取，直接在应用服务层通过IRepository暴露的接口获取即可。具体Repository有了，接下来我们看应用服务层如何调用：

public class ManifestService : IManifestService
    {
        private readonly IManifestRepository _manifestRepository;
        private readonly IDailyRepository _dailyRepository;
        private readonly IUnitOfWork _unitOfWork;

        public ManifestService(IManifestRepository manifestRepository,
            IDailyRepository dailyRepository,
            IUnitOfWork unitOfWork)
        {
            _manifestRepository = manifestRepository;
            _dailyRepository = dailyRepository;
            _unitOfWork = unitOfWork;
        }

 看见没有，典型的构造函数注入，注入 所需的仓储，以及UoW。我们再看看具体的一个Add方法，看下它是如何与Repository、UoW交互的：

 public Manifest AddManifest(Manifest manifest)
        {
            try
            {
                _unitOfWork.BeginTransaction();

                _manifestRepository.Insert(manifest);
                var daily = _dailyRepository.Get(x => x.Date.Date == manifest.Date.Date).FirstOrDefault();
                if (daily != null)
                {
                    daily.Cost += manifest.Cost;
                    _dailyRepository.Update(daily);
                }
                else
                {
                    daily = new Daily
                    {
                        ID = Guid.NewGuid().ToString(),
                        Date = manifest.Date,
                        Cost = manifest.Cost
                    };
                    _dailyRepository.Insert(daily);
                }

                _unitOfWork.CommitTransaction();

                return manifest;
            }
            catch(Exception e)
            {
                _unitOfWork.RollbackTransaction();
                throw e;
            }           
        }

 　　看到没有，UoW开启事务，然后各种仓储原子操作，操作完毕，UoW 提交事务，或者异常出现，UoW回滚事务。是不是So easy。。。另外，假如仓储层切换了ORM或者数据源，对应用服务层是完全透明的，是不是so happy。。。

　　另外，之前曾有园友问过，在Autofac模块化注入中，如果不想以名字结尾来匹配，如何注册服务或仓储，这里也贴出解决方案：

public class RepositoryModule : Module
    {
        protected override void Load(ContainerBuilder builder)
        {
            builder.RegisterType<EFUnitOfWork>()
                .As<IUnitOfWork>()
                .InstancePerLifetimeScope();
            builder.RegisterAssemblyTypes(this.ThisAssembly)
                .Where(t => t.IsAssignableTo<IRepository>())
                .AsImplementedInterfaces()
                .InstancePerLifetimeScope();
        }
    }

 大家注意看红色部分，这就是之前定义那个空IRepository接口的作用。记住一个词，面向接口。。。

5、总结

　　本文是针对Repository、UoW的核心概念的实现，即，Repository用于解耦应用服务层或者说叫业务逻辑层与具体数据存取，UoW用于维护事务。在此之前，曾拜读过园子中大神们的一些文章，最终得出结论，这玩意儿，没必要深究，只要抓住了Martin老爷子对二者的核心定义，在此基础上按照自己的理解去实践就OK了。这玩意儿就像ML，在XX和获得GC的大前提下，采用何种姿势，各位随意，只要自己爽就成。如果你非要尝试各种不同姿势，未尝不可，只要自己不嫌累，是不是。。。