ASP.NET Core

　　由于公司的工作安排，一直在研究其他技术，所以一直没时间更新博客，今天终于可以停下手头的事情，写一些新内容了。 　　应用场景：企业门户网站会根据内容不同，设置不同的板块，如新浪有体育，娱乐频道，等等。有的情况下需要给不同的板块设置不同的二级域名，如新浪体育sports.sina.com.cn。 　　在asp.net core mvc中，如果要实现板块的效果，可能会给不同的板块建立不同的控制器（当然也有其他的技术，这里不讨论实现方式的好坏），在这种情况下，如何给控制器绑定上独有的二级域名，比如体育频道对应的控制器叫SportController，通过sports.XXX.com域名访问系统的时候，直接进入SportController，并且通过这个二级域名无法访问其他的控制器。 　　上面说完场景了，下面来看下如何实现。 　　在asp.net core mvc中有路由规则配置，配置的地方在Startup.Configure方法中，具体代码如下： 　　 app.UseMvc(routes => { routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}", defaults: new { area="admin"}); }); 　　遗憾的是不支持对域名的支持（我目前了解的是

欢迎大家加入《ASP.NET Core 3框架揭秘》读者群。入群方式：扫描下方二维码或者搜索微信账号“broadview002”（博文小丸子）并添加为好友，并在申请消息中指定本书书号“38462”，出版社工作人员将自动帮你添加到该微信群。对于在群的朋友们，你也可以邀请感兴趣的人加入。 样章下载： https://pan.baidu.com/s/147VsO1wt9DJi9kuE7Kzngg 提取码 qm7s。 完整目录下载： 上册 、 下册 相关博文系列： https://www.cnblogs.com/artech/p/inside-asp-net-core-3-summary.html 本书提供的实例源代码： https://github.com/jiangjinnan/InsideAspNetCore3 https://files.cnblogs.com/files/artech/inside-asp-net-core-3.7z 勘误： https://www.cnblogs.com/artech/p/corrigendum.html 来源： oschina 链接： https://my.oschina.net/u/4259850/blog/4318157

介绍 关于什么是Claim？ 可以看看其他大神的文章： http://www.cnblogs.com/jesse2013/p/aspnet-identity-claims-based-authentication-and-owin.html http://www.cnblogs.com/savorboard/p/aspnetcore-identity.html 注：本人目前还是菜鸟初学阶段，如有写错的地方，望各位大鸟 指出！ 场景 用户登录是一个非常常见的应用场景 .net core的登录方式跟以往有些不同，可以说是往好的方向发展，变得更容易扩展，更方便。 在上一章里面，有过简单的介绍，那么这一章，我们来详细看看。 配置 1.首先需要NuGet安装一个包： Microsoft.AspNetCore.Authentication.Cookies 打开项目中的Startup.cs文件，找到ConfigureServices方法，我们通常在这个方法里面做依赖注入的相关配置。 public void ConfigureServices(IServiceCollection services) { // 增加Cookie中间件配置 services.AddAuthentication(options => { options.DefaultAuthenticateScheme = "

一、前言 回顾： 认证授权方案之授权初识 从上一节中，我们在对授权系统已经有了初步的认识和使用，可以发现，asp.net core为我们提供的授权策略是一个非常强大丰富且灵活的认证授权方案，能够满足大部分的授权场景。 在ConfigureServices中配置服务：将授权服务添加到容器 public void ConfigureServices(IServiceCollection services) { services.AddAuthorization(options => { options.AddPolicy("customizePermisson", policy => policy .Requirements .Add(new PermissionRequirement("user"))); }); //此外，还需要在 IAuthorizationHandler 类型的范围内向 DI 系统注册新的处理程序： services.AddScoped<IAuthorizationHandler, PermissionRequirementHandler>(); } 在Configure中注册管道：运行使用调用方法来配置Http请求管道 public void Configure(IApplicationBuilder app, IWebHostEnvironment env)

看到越南小哥 的github 上的 Evaluating Performance of REST vs. gRPC ， 使用的是.NET Core 3.0 , 今天我把它升级到.NET Core 3.1 同样做了一个测试，文章的结果和他的博客文章是一样的： https://dev.to/thangchung/performance-benchmark-grpc-vs-rest-in-net-core-3-preview-8-45ak 。 在8年前我写过一篇文章： WCF和ASP.NET Web API在应用上的选择 。 现在是2020年了，WCF换成了gRPC， ASP.NET Web API换成了ASP.NET Core Web API, 对外提供标准化的REST服务，内部通信采用gRPC的也是新时代的.NET应用程序的一个好选择，类似于Kubernetes 架构将有效负载格式用于传输协议的方式。 我们来看下.NET Core 3.1下REST和gRPC的性能表现怎么样？ 从 https://github.com/geffzhang/RESTvsGRPC 下载代码。在测试机器上安装.NET Core 3.1。 REST API： cd RESTvsGRPC\RestAPI dotnet run -p RestAPI.csproj -c Release gRPC API： cd

单元测试对我们的代码质量非常重要。很多同学都会对业务逻辑或者工具方法写测试用例，但是往往忽略了对Controller层写单元测试。我所在的公司没见过一个对Controller写过测试的。今天来演示下如果对Controller进行单元测试。以下内容默认您对单元测试有所了解，比如如何mock一个接口。在这里多叨叨一句，面向接口的好处，除了能够快速的替换实现类（其实大部分接口不会有多个实现），最大的好处就是可以进行mock，可以进行单元测试。 测试Action 下面的Action非常简单，非常常见的一种代码。根据用户id去获取用户信息然后展示出来。下面看看如何对这个Action进行测试。 public class UserController : Controller { private readonly IUserService _userService; public UserController(IUserService userService) { _userService = userService; } public IActionResult UserInfo(string userId) { if (string.IsNullOrEmpty(userId)) { throw new ArgumentNullException(nameof(userId)); } var

原文: ASP.NET Core中的依赖注入（5）：ServicePrvider实现揭秘【补充漏掉的细节】 到目前为止，我们定义的ServiceProvider已经实现了基本的服务提供和回收功能，但是依然漏掉了一些必需的细节特性。这些特性包括如何针对IServiceProvider接口提供一个ServiceProvider对象，何创建ServiceScope，以及如何提供一个服务实例的集合。 一、提供一个ServiceProvider对象 我们知道当将服务类型指定为IServiceProvider接口并调用ServiceProvider的GetService方法是，ServiceProvider对象本身将会作为服务实例返回，这个特性可以利用一个自定义的Service来实现。如下面的代码片段所示，我们定义的这个ServiceProviderService既是一个Service，又是一个ServiceCallSite。它默认采用生命周期管理模式为Scoped，在Invoke和Build方法中，它直接将当前ServiceProvider作为提供的服务实例。在初始化ServiceTable的时候，我们额外添加一个针对ServiceProviderService的ServideEntry。 1: internal class ServiceProviderService : IService

距离上次提出 [Asp.Net Core] Blazor Server Side 扩展用途 - 配合CEF来制作带浏览器核心的客户端软件 的想法后, 差不多2个星期了. 这个玩意也做了一半, 自用是没问题的, 放出去倒是不够精细. 如图: 上面的是开发中的项目文件的截图. 不是成品. 现在可以用 .net core 或者 .net framework 来绑定这个 CEF . 只有 .net core 才能启动 asp.net core , 而 .net framework 可以自启 asp.net webform , 虽然自己觉得这不实用. 现在离发布开源, 还差一些工作量 : 1 - CEF的很多实用的API根本没整合 , 只是根据需要, 用一个就整合一个. 2 - 改名 , 很多类名, 属性方法, 都需要看情况改名. 3 - 下载列表对话框 4 - 完整的测试. 功能越多, 需要的测试越多 5 - CEF默认没有Notification API, 考虑实现. 项目当前功能的一些状况: 1 - 冷启动是6秒左右. 包括启动.net core, 启动asp.net core, 启动CEF, 用CEF打开第一个网页, 待网页的window.onload触发 2 - 热启动是1.1秒左右. 3 - 程序启动后占用内存180MB起步. CEF多进程模式(默认不打开,不推荐),

原文: ASP.NET Core中的依赖注入（5）: ServiceProvider实现揭秘 【解读ServiceCallSite 】 通过 上一篇 的介绍我们应该对实现在ServiceProvider的总体设计有了一个大致的了解，但是我们刻意回避一个重要的话题，即服务实例最终究竟是采用何种方式提供出来的。ServiceProvider最终采用何种方式提供我们所需的服务实例取决于最终选择了怎样的ServiceCallSite，而服务注册是采用的ServiceDescriptor有决定了ServiceCallSite类型的选择。我们将众多不同类型的ServiceCallSite大体分成两组，一组用来创建最终的服务实例，另一类则与生命周期的管理有关。 一、用于服务创建的ServiceCallSite 服务实例的创建方式主要有三种，分别对应ServiceDescriptor如下三个只读属性。简单来说，如果ImplementationInstance属性返回一个具体的对象，该对象将直接作为提供的服务实例。如果属性ImplementationFactory返回一个具体的委托对象，该委托将会作为提供服务实例的工厂。除此之外，ServiceProvider将会利用ImplementationType属性返回的真是服务类型定位某一个最佳的构造函数来创建最终提供的服务实例。 1: public

0. 前言 在前一篇中我们创建了一个基于EF的数据查询接口实现基类，这一篇我将带领大家讲一下为这EF补充一些功能，并且提供一个解决避免写大量配置类的方案。 1. SaveChanges的外移 在之前介绍EF Core的时候，我们提到过使用EF需要在每次使用之后，调用一次SaveChanges将数据提交给数据库。在实际开发中，我们不能添加一条数据或者做一次修改就调用一次SaveChanges，这完全不现实。因为每次调用SaveChanges是EF向数据库提交变更的时候，所以EF推荐的是每次执行完用户的请求之后统一提交数据给数据库。 这样就会造成一个问题，可能也不是问题：我们需要一个接口来管理EF 的SaveChanges操作。 1.1 创建一个IUnitOfWork接口 通常我们会在Domain项目中添加一个IUnitOfWork接口，这个接口有一个方法就是SaveChanges，代码如下： namespace Domain.Insfrastructure { public interface IUnitOfWork { void SaveChanges(); } } 这个方法的意思表示到执行该方法的时候，一个完整的工作流程执行完成了。也就是说，当执行该方法后，当前请求不会再与数据库发生连接。 1.2 实现IUnitOfWork接口 在 Domain