仓储模式咱们已耳熟能详,但当咱们将其进行应用时,真的是那么驾轻就熟吗?肯定是解放了生产力吗?这究竟是怎样的一个存在,肯定不是反模式?,一篇详文咱们探讨仓储模式,这里仅我我的的思考,如有更深入的理解,请在评论中给出git
5年前我在Web APi中使用EntityFramework中写了一个仓储模式,并将其放在我我的github上,此种模式也彻底是参考所流行的网传模式,现现在在我看来那是极其错误的仓储模式形式,当时在EntityFramework中有IDbSet接口,而后咱们又定义一个IDbContext接口等等,大同小异,接下来咱们看看在.NET Core中大可能是如何使用的呢?github
public interface IRepository<TEntity> where TEntity : class { /// <summary> /// 经过id得到实体 /// </summary> /// <param name="id"></param> /// <returns></returns> TEntity GetById(object id); //其余诸如修改、删除、查询接口 }
固然还有泛型类可能须要基础子基础类等等,这里咱们一并忽略架构
public abstract class EntityRepository<TEntity> : IRepository<TEntity> where TEntity : class { private readonly DbContext _context; public EntityRepository(DbContext context) { _context = context; } /// <summary> /// 经过id获取实体 /// </summary> /// <param name="id"></param> /// <returns></returns> public TEntity GetById(object id) { return _context.Set<TEntity>().Find(id); } }
public interface IUserRepository : IRepository<User> { /// <summary> /// 其余非通用接口 /// </summary> /// <returns></returns> List<User> Other(); }
public class UserRepository : EntityRepository<User>, IUserRepository { public List<User> Other() { throw new NotImplementedException(); } }
咱们定义基础通用接口和实现,而后每个业务都定义一个仓储接口和实现,最后将其进行注入,以下:app
services.AddDbContext<EFCoreDbContext>(options => { options.UseSqlServer(@"Server=.;Database=EFCore;Trusted_Connection=True;"); }); services.AddScoped(typeof(IRepository<>), typeof(EntityRepository<>)); services.AddScoped<IUserRepository, UserRepository>();
有一部分童鞋在项目中可能就是使用如上方式,每个具体仓储实现咱们将其当作传统的数据访问层,紧接着咱们还定义一套业务层即服务层,如此第一眼看来和传统三层架构无任何区别,只是分层名称有所不一样而已。每个具体仓储接口都继承基础仓储接口,而后每一个具体仓储实现继承基础仓储实现,对于服务层同理,反观上述一系列操做本质,其实咱们回到了原点,那还不如直接经过上下文操做一步到位来的爽快。上述仓储模式并无带来任何益处,分层明确性从而加大了复杂性和重复性,根本没有解放生产率,咱们将专一力所有放在了定义多层接口和实现上而不是业务逻辑,如此使用,这就是仓储模式的反模式实现仓储模式思考ide
全部脱离实际项目和业务的思考都是耍流氓,若只是小型项目,直接经过上下文操做何尝不可,既然用到了仓储模式说明是想从必定程度上解决项目中所遇到的痛点所在,要否则只是随波逐流,终将是自我打脸微服务
根据以下官方在微服务所使用仓储连接,官方推崇仓储模式,但在其连接中是直接在具体仓储实现中所使用上下文进行操做,毫无觉得这没半点毛病学习
EntityFramework Core基础设施持久化层ui
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-implementation-entity-framework-core
但我们想在上下文的基础上进一步将基本增、删、改、查询进行封装,那么咱们如何封装基础仓储而避免出现反模式呢?this
在进行改造以前,咱们思考两个潜在须要解决的重点问题spa
其一,每个具体业务仓储实现,定义仓储接口是必定必要的吗?我认为彻底不必,有的童鞋就疑惑了,若咱们有非封装基础通用接口,需额外定义,那怎么搞,咱们能够基于基础仓储接口定义扩展方法
其二,若与其余仓储进行互操做,此时基础仓储不知足需求,那怎么搞,咱们能够在基础仓储接口中定义暴露获取上下文Set属性
其三,若很是复杂的查询,可经过底层链接实现或引入Dapper
首先,咱们保持上述封装基础仓储接口前提下添加暴露上下文Set属性,以下:
/// <summary> /// 基础通用接口 /// </summary> /// <typeparam name="TEntity"></typeparam> public interface IRepository<T> where T : class { IQueryable<T> Queryable { get; } T GetById(object id); }
上述咱们将基础仓储接口具体实现类,将其定义为抽象,既然咱们封装了针对基础仓储接口的实现,外部只需调用便可,那么该类理论上就不该该被继承,因此接下来咱们将其修饰为密封类,以下:
public sealed class EntityRepository<T> : IRepository<T> where T : class { private readonly DbContext _context; public EntityRepository(DbContext context) { _context = context; } public T GetById(object id) { return _context.Set<T>().Find(id); } }
咱们从容器中获取上下文并进一步暴露上下文Set属性
public sealed class EntityRepository<T> : IRepository<T> where T : class { private readonly IServiceProvider _serviceProvider; private EFCoreDbContext _context => (EFCoreDbContext) _serviceProvider.GetService(typeof(EFCoreDbContext)); private DbSet<T> Set => _context.Set<T>(); public IQueryable<T> Queryable => Set; public EntityRepository(IServiceProvider serviceProvider) { _serviceProvider = serviceProvider; } public T GetById(object id) { return Set.Find(id); } }
若为基础仓储接口不知足实现,则使用具体仓储的扩展方法
public static class UserRepository { public static List<User> Other(this IRepository<User> repository) { // 自定义其余实现 } }
最后到了服务层,则是咱们的业务层,咱们只须要使用上述基础仓储接口或扩展方法便可
public class UserService { private readonly IRepository<User> _repository; public UserService(IRepository<User> repository) { _repository = repository; } }
最后在注入时,咱们将省去注册每个具体仓储实现,以下:
services.AddDbContext<EFCoreDbContext>(options => { options.UseSqlServer(@"Server=.;Database=EFCore;Trusted_Connection=True;"); }); services.AddScoped(typeof(IRepository<>), typeof(EntityRepository<>)); services.AddScoped<UserService>();
以上只是针对第一种反模式的基本改造,对于UnitOfWork同理,其本质不过是管理操做事务,并需咱们手动管理上下文释放时机就好,这里就再也不多讲
咱们还能够根据项目状况可进一步实现其对应规则,好比在是否须要在进行指定操做以前实现自定义扩展,好比再抽取一个上下文接口等等,ABP vNext中则是如此,ABP vNext对EF Core扩展是我看过最完美的实现方案,接下来咱们来看看
其核心在Volo.Abp.EntityFrameworkCore包中,将其单独剥离出来除了抽象通用封装外,还有一个则是调用了EF Core底层APi,一旦EF Core版本变更,此包也需同步更新
ABP vNext针对EF Core作了扩展,经过查看总体实现,主要经过扩展中特性实现指定属性更新,EF Core中当模型被跟踪时,直接提交则更新变化属性,若未跟踪,咱们直接Update但想要更新指定属性,这种方式不可行,在ABP vNext则获得了良好的解决
在其EF Core包中的AbpDbContext上下文中,针对属性跟踪更改作了良好的实现,以下:
protected virtual void ChangeTracker_Tracked(object sender, EntityTrackedEventArgs e) { FillExtraPropertiesForTrackedEntities(e); } protected virtual void FillExtraPropertiesForTrackedEntities(EntityTrackedEventArgs e) { var entityType = e.Entry.Metadata.ClrType; if (entityType == null) { return; } if (!(e.Entry.Entity is IHasExtraProperties entity)) { return; } ..... }
除此以外的第二大亮点则是对UnitOfWork(工做单元)的完美方案,将其封装在Volo.Abp.Uow包中,经过UnitOfWorkManager管理UnitOfWork,其事务提交不简单是像以下形式
private IDbContextTransaction _transaction; public void BeginTransaction() { _transaction = Database.BeginTransaction(); } public void Commit() { try { SaveChanges(); _transaction.Commit(); } finally { _transaction.Dispose(); } } public void Rollback() { _transaction.Rollback(); _transaction.Dispose(); }
额外的还实现了基于环境流动的事务(AmbientUnitOfWork),反正ABP vNext在EF Core这块扩展实现使人叹服,我也在持续学习中,其余就很少讲了,博客园中讲解原理的文章比比皆是
好了,本文到此结束,倒没什么可总结的,在文中已有归纳,咱们下次再会