（ 且放白鹿青崖间，须行即骑访名山 ）
终于还是要面对这个问题了，一直想着可以逃避它，自从18年就开始纠结这个问题，后来看了DDD，然后也收集了很多的设计思想，发现一个框架除了稳定性，可扩展性以外，易操作无冗余也是很重要的，看来今天是时候操作了。
代码上传到weakrepo分支（如果没有，则表示已合并master,文末投票过半数，三天内合并分支）。
看完本文后，可以文末做一下投票，说说你对本文这个操作的接受程度。
仓储层存在的鸡肋
首先，要还是需要的。
关于Blog.Core项目呢，刚开始的时候，我就为了记录代码，怎么简单怎么来，主要设计的是服务+仓储+接口模式，面向抽象编程，其实当时也是为了能让初学者更好的理解整体框架，毕竟很像三层架构，这样初学者就可以花更多的心思和精力去研究具体的知识点，比如DI、AOP、Middleware、容器化、事务等。
但是这个时候就埋下了一个伏笔，就是很多人也发现了，如果新建一个实体，就会需要增加四层类文件，服务/服务接口，仓储/仓储接口，如果再算上控制器提供API（下一步打算设计将server层接口直接作为控制器api），那就是需要五层文件，前期还好，如果实体多的话，就显得很臃肿，甚至被很多人吐槽，苦不堪言，后来我迫于压力，设计了代码生成器，可以一键生成五层文件，这样可以大大的加快时间，但是类文件还是很多：
其实服务文件还是很有必要的，毕竟不是DDD设计，重心还是要放到服务上，这里的服务应该就是数据业务逻辑代码，总不能放到控制器的。但是仓储文件就显得有点儿鸡肋了，代码都是空的，还需要两个cs文件，就是一个中转的作用，看着真的是没有什么必要一样：
然后就很多小伙伴针对这一点，一直在提意见，发问题，甚至开怼，无奈的我只能说：
服务层写的是业务逻辑，仓储层是操作的DB，两者是不一样的。
但是有些苍白无力，这几天打算Blog.Core和Blog.Idp认证中心打通，发现如果使用多库模式下，新建的实体类，也需要四层文件，这就是很尴尬了，于是还是打算对仓储层动手了。
弱化仓储层
下面我就直接写操作步骤了，比较简单，用一句话概括，就是用泛型仓储来代替具体仓储。具体的操作如下。
容器中注册仓储基类
这个就是文章标题说的内容了，只需要这一行代码就行了：
builder.RegisterGeneric(typeof(BaseRepository<>))
.As(typeof(IBaseRepository<>)).InstancePerDependency();//注册仓储
就是这么简单，但是现在一个最大的问题，就是我之前说解耦了，web层只引用接口层，如果要这么注册的话，就必须要修改引用了，看自己的需要吧，毕竟这个解耦，好像并没有收到什么好处，坏处倒是有很多，那我们就退缩了吧，web层直接引用Extension层，Extension服务扩展层引用Service层，Service层引用Repository层。
（PS：服务扩展层只是对web层的一次剥离瘦身）
删掉所有无用的仓储文件
就像上边举例的，把空的仓储文件以及对应的接口文件都删除，当然，如果你后期想创建的话，也可以新建，我这里保留了一个示例，自己可以查看：
（我这里也把仓储接口层给删了，毕竟没有几个文件）
修改服务实现层对仓储调用
上边我们已经把仓储/接口都删除了，那如何使用呢，很简单，直接用基类泛型注入就行了，这里用一个Service文件来看看：
效果预览
测试数据没有问题，多库、读写分离、事务等也没有问题，证明效果是一样的，当然AOP事务也是没有问题的：
（新增一条数据后，手动异常，执行回滚）
是不是瞬间就清爽了很多，这里咱们说说优缺点。
操作带来的优缺点
优点：
1、大大减少文件量，同时也会减少项目编译时间；
2、同时自己可以做自定义仓储扩展；
3、多库连接只需要写service层即可；
缺点：
1、大大弱化了仓储层，可能对新用户接触不友好；
2、web层需要引用service层，放弃了项目解耦理念；
其实缺点也不是缺点，就是和之前讲的不一样罢了。
预告下一步：
封装服务基类，将视图模型封装进去。
