autofac

.net core 2和3 使用autofac注入方式不一样，此文章是针对.net core 3.1 首先安装 Autofac.Extensions.DependencyInjection 然后在Program.cs 新增一行代码 然后在Startup.cs 增加方法 注：业务逻辑层每个类都以Service结尾 ConfigureServices 和 Configure 都不需要更改 到这里就配置好了，下面添加测试用例，直接截图代码： 注：控制器中要注入Test接口 添加好代码，直接运行 来源： oschina 链接： https://my.oschina.net/u/4395911/blog/3305539

.net core 2和3 使用autofac注入方式不一样，此文章是针对.net core 3.1 首先安装 Autofac.Extensions.DependencyInjection 然后在Program.cs 新增一行代码 然后在Startup.cs 增加方法 注：业务逻辑层每个类都以Service结尾 ConfigureServices 和 Configure 都不需要更改 到这里就配置好了，下面添加测试用例，直接截图代码： 注：控制器中要注入Test接口 添加好代码，直接运行 来源： oschina 链接： https://my.oschina.net/u/4384335/blog/4267909

.net core 2和3 使用autofac注入方式不一样，此文章是针对.net core 3.1 首先安装 Autofac.Extensions.DependencyInjection 然后在Program.cs 新增一行代码 然后在Startup.cs 增加方法 注：业务逻辑层每个类都以Service结尾 ConfigureServices 和 Configure 都不需要更改 到这里就配置好了，下面添加测试用例，直接截图代码： 注：控制器中要注入Test接口 添加好代码，直接运行 来源： oschina 链接： https://my.oschina.net/u/4302946/blog/4267920

在我们码字过程中，单元测试是必不可少的。但在从业过程中，很多开发者却对单元测试望而却步。有些时候并不是不想写，而是常常会碰到下面这些问题，让开发者放下了码字的脚步： 这个类初始数据太麻烦，你看：new MyService(new User("test",1), new MyDAO(new Connection(......)),new ToManyPropsClass(......) .....) 。我：。。。 这个代码内部逻辑都是和Cookie有关，我单元测试不好整啊，还是得启动到浏览器里一个按钮一个按钮点。 这个代码内部读了配置文件，单元测试也不能给我整个配置文件啊？ 这个代码主要是验证WebAPI入口得模型绑定，必须得调用一次啊？ 这些问题确实存在，但它们阻止不了我们那颗要写单元测试的心。单元测试的优点很多，你或许可以不管。但至少能让你从那些需要在浏览器里点击10多下的操作里解脱出来。 本文从一个简单的逻辑测试出发，慢慢拉开测试的大幕，让你爱上测试。文章主要是传播一些单元测试的理念，其次才是介绍asp.net core中的单元测试。 本文使用的环境为asp.net core 2.1 webapi，代码可以直接下载: https://github.com/yubaolee/DotNetCoreUnitTestSamples 为了方便阅读，以一个最简单的逻辑为例： public

面向切面编程：Autofac.Annotation扩展组件是我开源的一款利用打标签完成autofac容器的注入组件。 https://github.com/yuzd/Autofac.Annotation 我们之前介绍了利用Aspect标签来完成拦截器功能 Aspect是一对一的方式，我想要某个class开启拦截器功能我需要针对每个class去配置。 详情请点击 比如说 我有2个 controller 每个controller都有2个action方法， [ Component ] public class ProductController { public virtual string GetProduct ( string productId ) { return "GetProduct:" + productId; } public virtual string UpdateProduct ( string productId ) { return "UpdateProduct:" + productId; } } [ Component ] public class UserController { public virtual string GetUser ( string userId ) { return "GetUser:" + userId; } public

前言 　　现在的编程世界中，IOC已经成为了标配，毕竟解耦对于代码开发和维护都提升了很大的效率；而.NetCore中就自带了IOC功能，下面记录一下.NetCore Web项目中IOC的使用及如何集成AutoFac； 环境 　　 开发环境： .NetCore3.1；注：需要安装对应的SDK版本； 项目创建 　　1. 选择模板 -- ASP.NET Core Web应用程序； 　　2. 添加两个项目DotNetCoreBll 和 DotNetCoreDal ，选模板的时候选择 类库(.Net Core)； 　　最终项目结构 　　加这两个程序集的目的就是为了模拟业务处理，DotNetCoreBll 业务处理；DotNetCoreDal 获取数据； 设置DotNetCoreIoc 为启动项目运行，如下图 　　出现以上界面项目创建成功； 传统方式--自己New 　　1. 分别在DotNetCoreBll 和 DotNetCoreDal中增加 类 UserBll 和 UserDal ， 里面代码如下： 　　类UserDal : 　　 　　类UserBll: 　　 　　2. 在HomeController中增加一个Api 　　 　 　然后，运行项目，访问 http://localhost:5000/Home/GetUserName 地址，运行如下： 　　综上， 可以看出

前言 最近将近半个月没有更新博客了，因为找到了新的工作，开始上班了。上班之余也没闲着，上周末将自己去年的一个.NetCore2.1的框架升级到了3.1版本。在升级过程中还是出现了不少问题。有些是版本升级必须要解决的，有些是因为自己犯了强迫症，一定要将引用的Nuget包升级到当前最新版本。 这里就凭借记忆，记录下这次升级的点点滴滴吧。 框架引用的Nuget包 这里先将引用到的部分Nuget包罗列出来，都是常用的库。 Autofac AutoMapper NewLife.Redis NLog System.Text.Json Microsoft.AspNet.SignalR DotNetCore.NPOI Quartz Swashbuckle.AspNetCore 升级到.NetCore 3.1出现的几个明显的问题 使用第三方IOC容器方式的改变导致依赖注入这一块代码需要改动 Startup内提供内置的依赖注入服务有所改变，导致原有的部分方法编译可通过运行时则异常 跨域实现部分微软做了更细化的限制，原有的跨域部分代码运行时异常 依赖的组件出现的问题 AutoMapper升级到9.0后因为官方移除了静态API导致所有引用到AutoMapper映射的地方都要改，同时需要将IMapper注入到DI容器内 Swashbuckle.AspNetCore升级到5.1后API有所更新

我们在项目中很早就开始使用autofac，也以为知道与mvc和webapi集成的做法。 var builder = new ContainerBuilder(); // Mvc Register builder.RegisterControllers(Assembly.GetExecutingAssembly()).AsSelf().PropertiesAutowired(); builder.RegisterFilterProvider(); builder.RegisterType<UserService>().As<IUserService>().InstancePerLifetimeScope(); //WebApi Register builder.RegisterApiControllers(Assembly.GetExecutingAssembly()).AsSelf().PropertiesAutowired(); builder.RegisterWebApiFilterProvider(GlobalConfiguration.Configuration); builder.RegisterWebApiModelBinderProvider(); var container = builder.Build(); // Set the dependency