ASP.NET Core

通过 上文 所述案例，我们已经选择了最优回归算法来预测学生的综合成绩，并且完成了基于训练数据集的预测模型训练。从实现上，训练好的模型被保存成一个ZIP文件，以便在其它项目中直接调用以完成机器学习的实践场景。在本文中，我将介绍如何在ASP.NET Core中使用这个ZIP文件，以提供用于学生成绩预测的RESTful API。 将模型文件保存到Azure Blob Storage中 我们已经得到了经过ML.NET训练好的模型数据文件，也就是一个ZIP文件，在开发的RESTful API中，需要读入这个文件以便实现预测功能。于是，ZIP文件保存在何处就成为了我们首要解决的问题。在开发环境，我们可以将ZIP文件保存在ASP.NET Core的运行目录中，可是，开发好的RESTful API最终还是要部署到生产环境，这种部署有可能是单节点的，也有可能是位于负载均衡服务器后端的多节点部署，而且模型文件也会随着训练数据集的增加或变化进行增量式更新，因此，依赖于部署环境的本地文件系统并不是一个好的做法。因此，我选择将模型文件保存在 Azure Blob Storage 中。 注意：为了防止在开发调试阶段过多使用Azure Blob Storage的流量，我们可以在ASP.NET Core的应用程序中实现两套模型数据供应器：一套从本地文件系统读入模型，用于开发环境，另一套从Azure Blob

前言 默认的 index.html 显示的 Loading 太简陋了. 而且没有加载进度条. 所以做了一个. 代码地址 : https://github.com/BlazorPlus/BlazorDemoWasmLoading 只需要改 index. html <! DOCTYPE html > < html > < head > < meta charset ="utf-8" /> < meta name ="viewport" content ="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" /> < title > BlazorDemoWasmLoading </ title > < base href ="/" /> < link href ="css/bootstrap/bootstrap.min.css" rel ="stylesheet" /> < link href ="css/app.css" rel ="stylesheet" /> < link href ="manifest.json" rel ="manifest" /> < link rel ="apple-touch-icon" sizes ="512x512" href ="icon-512

0.前言 在《asp.net core 系列》之实战系列中，我们在之前的篇幅中对项目有了一个大概的认知，也搭建了一个基础的项目骨架。那么就让我们继续完善这个骨架，让它更加丰满。这一篇，我将带领小伙伴们一起实现用户管理功能。 1. 数据表 一般情况下，我们会把用户表和登录信息表放在两个表里。为什么会这样设计呢？出于以下几种考虑： 使功能分割，用户信息管理是用户管理，登录是登录 增加安全，降低无关信息的查询，例如访问登录接口不会连带检索用户的普通信息，当进行用户信息管理的时候，不会把登录信息也带过来 等等 废话不多说，直接上代码： namespace Data.Enums { /// <summary> /// 登录类型 /// </summary> public enum LoginType : byte { /// token登录 Token, /// 用户名密码 Password } /// <summary> /// 性别 /// </summary> public enum SexEnum { /// 男 Male, /// 女 Female, /// 隐私 None } } SysUserAuthEntity.cs using Data.Enums; using Data.Infrastructure; namespace Data.Models { public

原文: ASP.NET Core中的依赖注入（4）: 构造函数的选择与服务生命周期管理 ServiceProvider最终提供的服务实例都是根据对应的ServiceDescriptor创建的，对于一个具体的ServiceDescriptor对象来说，如果它的ImplementationInstance和ImplementationFactory属性均为Null，那么ServiceProvider最终会利用其ImplementationType属性返回的真实类型选择一个适合的构造函数来创建最终的服务实例。我们知道服务服务的真实类型可以定义了多个构造函数，那么ServiceProvider针对构造函数的选择会采用怎样的策略呢？ 目录 一、构造函数的选择 二、生命周期管理 ServiceScope与ServiceScopeFactory 三种生命周期管理模式 服务实例的回收 一、构造函数的选择 如果ServiceProvider试图通过调用构造函数的方式来创建服务实例，传入构造函数的所有参数必须先被初始化，最终被选择出来的构造函数必须具备一个基本的条件：ServiceProvider能够提供构造函数的所有参数。为了让读者朋友能够更加真切地理解ServiceProvider在构造函数选择过程中采用的策略，我们不让也采用实例演示的方式来进行讲解。 我们在一个控制台应用中定义了四个服务接口

前言, Blazor Assembly 需要最少 1.9M 的下载量. ( Blazor WebAssembly 船新项目下载量测试 , 仅供参考. ) 随着程序越来越复杂, 引用的东西越来越多, 需要更多的下载量 , 有一些网站的网络可能较差, 加载这些文件需要一定的时间. 对于一些网站而言, 它不是一开始就把wasm页面暴露给游客的. wasm更加适合做的, 是一些需要与服务器进行大量交互的App类程序. 例如网站后台管理界面, 聊天后台界面, 等等. 所以, 大部分场合, 游客是先进了网站, 然后登陆, 最后才到wasm页面. 基于这种情况, 这里提供了一个例子, 关于如何预先加载wasm所需的dll 达到如此效果: 游客进入网站欢迎页 => 欢迎页在背后预先加载dll资源 => 游客进入WASM界面, 加载速度变快. 例子工程 : 首先, 这个例子使用的是 Asp.Net hosted , 加上 PWA 模式. 那么这里就有 Asp.Net Core 的程序在服务器运行着 . 修改WASM首页地址 把 Index.razor 的地址改成 /Home , 因为我们需要网站的首页是欢迎页. 新增网站首页 我们用 Asp.Net Core 的 razor页面来做首页. 没有Controller , 当然你也可以用自己喜欢的方式, 使用 MVC , 甚至是Blazor Server

基于blazor实现的一个简单的TODO List 最近看到一些大佬都开始关注blazor，我也想学习一下。做了一个小的demo，todolist，仅是一个小示例，参考此vue项目的实现 http://www.jq22.com/code1339 先看实现的效果图 不BB,直接可以去看 源码与预览地址 示例地址 http://baimocore.cn:8081/ 源码地址 BlazorAppTodoList 源码介绍 我们这里删除了默认的一些源码。只保留最简单的结构,在Pages/Index.razor中。 @code代码结构中写如下内容 创建一个类，里面包含 id,label,isdone三个属性值。 public class TodoItem { public TodoItem () { } public TodoItem (int id, string label, bool isDone) { Id = id; Label = label; IsDone = isDone; } public int Id { get; set; } public string Label { get; set; } public bool IsDone { get; set; } } 我们可以通过override重写初始化，并给Todos设置一些数据。 private IList

原文: .NET CORE 中间件 什么是中间件 对于中间件我们其实并不陌生，在.NET CORE出现之前中间件的概念在OWIN应用程序中就已经普遍使用了。 中间件官方定义： 中间件是一种集成到应用管道中间来处理请求和响应的模块，每个中间件可以： 选择是否将请求传递到管道的下一个组件 可以在管道的下一个组件前后执行工作 ASP.NETCORE中的中间件本质上是一个请求委托 Func< RequestDelegate, RequestDelegate> middleware 。 RequestDelegate本身也是一个委托，定义为 public delegate Task RequestDelegate(HttpContext Context) 。 在ASP.NETCORE请求管道中，形成一条委托链。 请求管道短路：当委托不选择将请求传递到下一个委托时，称之为“短路”。 如何创建中间件 在ASP.NETCORE中，使用 IApplicationBuilder 来创建/插入中间件管道。提供了 Run 和 Use 两类方式。依赖组件包 Microsoft.AspNetCore.Http.Abstractions Run是一种 约定 的终端管道,即短路，不再执行下一个委托 public void Configure(IApplicationBuilder app,

在向微服务体系架构转型的过程中，我们都会毫不意外地遇到越来越多的现实问题，而这些问题却并不是因为功能性需求而引入的。比如，服务的注册与发现，是应用程序在云中部署、提供可伸缩支持的主要实现方案，在特定的微服务架构中，实践这样的云设计模式是利远远大于弊的。今我们需要讨论的API网关也是这样的一种微服务实现方案，它解决了客户端与服务端之间繁琐的通信问题。 在进一步讨论API网关在微服务架构中的应用前，先一起了解一下目前我手上的两个微服务：A服务提供了数学计算的API，B服务则提供了天气数据查询的API。两者看上去风马牛不相及，然而，B服务中的一个需求使得两者之间产生了密不可分的联系：B服务需要提供某些城市5年来平均气温的标准差，以便用户能够了解各个城市的气温变化情况。业务需求其实挺简单，从一个外部数据源将指定城市的平均气温数据读入，然后计算标准差即可，不过从实现上看，由于A服务已经提供了计算标准差的API，因此，B服务没有必要自己再写一套，只需要调用A服务提供的API即可，也就是A和B之间存在互相调用的情况。另一方面，对于用户来说，也存在需要同时调用A和B两组API的场景，因此，A和B的API也需要向外界曝露，这样一来应用程序的结构大致如下： 也就是上图中B服务的/weather/stddev API将会用到A服务中的/calc/stddev这个API。OK

原文: .NET CORE 依赖注入 实践总结 知识点回顾 依赖包。 Microsoft.Extensions.DependencyInjection.Abstractions 核心对象和方法。 IServiceCollection 。注入对象的容器。注意它只存储对象的元数据，并不保存实例对象。 IServiceProvider 。注入对象的提供者。它负责提供具体的对象实例。在架构中，IServiceProvider有2种身份，一种是Root ServiceProvider，由service.BuildServiceProvider()创建，生命周期贯穿整个应用程序，AddSingleton对象保存在这里。另外一种则是普通IServiceProvider，由IServiceScope创建，生命周期即为AddScoped的生命周期。AddScope 的对象保存在这里。普通ServiceProvider由Root ServiceProvider创建的IServiceScope创建。 IServiceScope 。表某一个生命周期范围。由ServiceProvider.CreateScope()创建。 注入方式，知识点一 。 注入功能默认在Startup类中的ConfigureServices方法中。 注入方式，知识点二 。支持以下三种方式 AddScoped。生命周期为Scoped类型

单例模式 线程安全的Singleton 会破坏Singleton的情况 线程级Singleton 单例模式是几个创建型模式中最独立的一个，它的主要目标不是根据客户程序调用生成一个新的实例，而是控制某个类型的实例数量只有一个。 GOF对单例的描述为： Ensure a class only has one instance, and provide aglobal point of access to. —Design Patterns : Elements of Reusable Object-Oriented Software 单例模式 单例模式的应用场景不必赘述，先来一个最简单的实现方式： public class Singleton { private Singleton() { } private static Singleton instance; public static Singleton Instance() { if (instance == null) { instance = new Singleton(); } return instance; } } 这里采用的是Lazy方式，也可以在静态变量被创建的时候直接初始化实例。 这段代码已经可以满足最初Singleton模式的设计要求，在大多数情况下可以很好地工作。但在多线程环境下这种实现方式是存在缺陷的