系列目录 1.net core天马行空系列:原生DI+AOP实现spring boot注解式编程 2.net core天马行空系列: 泛型仓储和声明式事物实现最优雅的crud操作 哈哈哈哈,大家好,我就是高产似母猪的三合.日常开发中,我们常会遇到这样的场景,一个接口,有多个实现类,在某个业务中,我们希望指定某个实现类,如今网络上常见的解决方案,就是注入一个委托或者利用工厂模式,这些方式虽然能实现功能,但使用起来还是不够优雅,如何才称得上优雅呢?自然是在添加服务的时候给服务指定名称,注入的时候根据…

系列目录 1.net core天马行空系列:原生DI+AOP实现spring boot注解式编程 2.net core天马行空系列: 泛型仓储和声明式事物实现最优雅的crud操作 3.net core天马行空系列: 一个接口多个实现类,利用mixin技术通过自定义服务名,实现精准属性注入 4.net core天马行空系列:移植spring cache,实现支持条件限定,事务环绕,多级复用的注解式缓存(除了多级复用以外,代码已完成,博客正在写) 5.net core天马行空系列:利用AOP,在da…

系列目录 1.net core天马行空系列:原生DI+AOP实现spring boot注解式编程 2.net core天马行空系列: 泛型仓储和声明式事物实现最优雅的crud操作 3.net core天马行空系列: 一个接口多个实现类,利用mixin技术通过自定义服务名,实现精准属性注入 4.net core天马行空系列:SummerBoot,将SpringBoot的先进理念与C#的简洁优雅合二为一 正文开始 hi,大家好,我就是高产似母猪的三合.距离上一篇文章,好像有点久了,我也不知道我都在干…

系列目录 1.net core天马行空系列:原生DI+AOP实现spring boot注解式编程 哈哈哈哈,大家好,我就是那个高产似母猪的三合,长久以来,我一直在思考,如何才能实现高效而简洁的仓储模式(不是DDD里的仓储,更准确的说就是数据库表的mapper),实现spring boot里那样利用注解实现事物操作,日有所思,终有所得,本篇文章浓缩了我对于仓储模式和工作单元模式理解的精华,希望能对大家有所帮助,如果哪里说错了,也希望大家不吝赐教.由于ef core本身就实现了这2种模式,再在ef…

ExpandoObject与DynamicObject的使用   using ImpromptuInterface; using System; using System.Dynamic; namespace ConsoleApp2 { class Program { static void Main(string[] args) { dynamic expando = new ExpandoObject(); expando.name = "cys"; expando.Add = n…

 SRE vs DevOps:是敌是友? - DockOne.io http://www.dockone.io/article/5935   RE vs DevOps:是敌是友? [编者的话]网站可靠性工程(SRE)和DevOps是两个具有相当多重叠的热门学科.在过去,一些人认为SRE是与DevOps相竞争的一组实践.但我们不认为他们有那么大差别.SRE是什么?它与DevOps有什么关系? 今年早些时候,我们(Liz Fong-Jones 和 Seth Vargo)发布了一组视频试图来回答这些问…

引文   hi,大家好,我是三合.不知各位有没有想过,如果能把数据库操作和http访问都统一封装成接口(interface)的形式, 然后接口对应的实现类由框架去自动生成,那么必然能大大降低工作量,因为不需要去写很多重复的代码了,还有一个好处是,都是提供接口,我们把原来数据库操作的部分,改成http访问,对于业务层来说,是无感的,因为接口和方法都没变.致力于降低上手net core的门槛,我开源了SummerBoot项目,下面让我们来看一下效果. 数据库表对应实体类,这些都是常规操作,略过 重头…

1.前言 hi,大家好,我是三合.作为一名程序猿,日常开发中,我们在接到需求以后,一般都会先构思一个模型,然后根据模型写实体类,写完实体类后在数据库里建表,接着进行增删改查, 也有第二种情况,就是有些人喜欢先在数据库里建表,然后再添加实体类.前者是code First,后者是db First,如果数据库表和c#实体类可以互相转换的话,那么无疑将大大加快我们的开发速度,很幸运的是,当前依靠一些第三方建模软件或者是efcode就可以实现,我们以ef core举例, 1.1 ef core根据实体类生…

前言 近段时间在准备公司的技术分享,所以这段时间将大部分时间放在准备分享内容上去了.博客也就停了一下下. 在.NET Core中处理依赖注入问题时,往往是定义好了一个操作规范的接口,会有N多个基于不同技术的实现,根据实际情况在项目中去使用某一个实现. 但是偶尔会出现这样的情况,在某一个地方,需要同时使用到两种或两种以上的实现,这个时候我们要怎么处理呢? 借助Autofac等第三方组件时,是可以很容易的实现,但是在写一些基础类库时会避免直接引用太多依赖组件. 所以这里是只用微软自带的DI(Micr…

最近有个需求就是一个抽象仓储层接口方法需要SqlServer以及Oracle两种实现方式,为了灵活我在依赖注入的时候把这两种实现都给注入进了依赖注入容器中,但是在服务调用的时候总是获取到最后注入的那个方法的实现,这时候就在想能不能实现动态的选择使用哪种实现呢?如果可以的话那么我只需要在配置文件中进行相应的配置即可获取到正确的实现方法的调用,这样的话岂不快哉!今天我们就来一起探讨下实现这种需求的几种实现方式吧. 作者:依乐祝 原文地址:https://www.cnblogs.com/yilezhu…