linq

FreeSql是一个功能强大的 .NET ORM 功能库，支持 .NetFramework 4.0+、.NetCore 2.1+、Xamarin 等支持 NetStandard 所有运行平台。 QQ群：4336577(已满)、8578575(在线) 模型 FreeSql 使用模型执行数据访问，模型由实体类表示数据库表或视图，用于查询和保存数据。 可从现有数据库生成实体模型，FreeSql 提供 IDbFirst 接口实现 生成实体模型 。 或者手动创建模型，基于模型创建或修改数据库，提供 ICodeFirst 同步结构的 API（甚至可以做到开发阶段自动同步）。 using FreeSql.DataAnnotations; using System; public class Blog { [Column(IsIdentity = true, IsPrimary = true)] public int BlogId { get; set; } public string Url { get; set; } public int Rating { get; set; } } 声明 dotnet add packages FreeSql.Provider.Sqlite static IFreeSql fsql = new FreeSql.FreeSqlBuilder()

ML.NET 在经典机器学习范畴内，对分类、回归、异常检测等问题开发模型已经有非常棒的表现了，我之前的 文章 都有过介绍。当然我们希望在更高层次的领域加以使用，例如计算机视觉、自然语言处理和信号处理等等领域。 图像识别是计算机视觉的一类分支，AI研发者们较为熟悉的是使用TensorFlow、Pytorch、Keras、MXNET等框架来训练深度神经网络模型，其中会涉及到CNN（卷积神经网络）、DNN（深度神经网络）的相关算法。 ML.NET 在较早期的版本是无法支持这类研究的，可喜的是最新的版本不但能很好地集成 TensorFlow 的模型做 迁移学习 ，还可以直接导入 DNN 常见 预编译模型 ：AlexNet、ResNet18、ResNet50、ResNet101 实现对图像的分类、识别等。 我特别想推荐的是，ML.NET 最新版本对 ONNX 的支持也是非常强劲，通过 ONNX 可以把众多其他优秀深度学习框架的模型引入到 .NET Core 运行时中，极大地扩充了 .NET 应用在智能认知服务的丰富程度。在 Microsoft Docs 中已经提供了一个基于 ONNX 使用 Tiny YOLOv2 做对象检测的例子。为了展现 ML.NET 在其他框架上的通用性，本文将介绍使用 Pytorch 训练的垃圾分类的模型，基于 ONNX 导入到 ML.NET 中完成预测。

阅读目录： 1.需求背景介绍（Model元数据设置项应该与View绑定而非ViewModel） 1.1.确定问题域范围（可以使用DSL管理问题域前提是锁定领域模型） 2.迁移ViewModel设置到外部配置文件（扩展Model元数据提供程序） 2.1.实现元数据提供程序（简单示例） 1.需求背景介绍（Model元数据设置项应该与View绑定而非ViewModel） 使用ASP.NETMVC构建普通的中小型站点可以使用简单的Model元数据设置方式来控制ViewModel如何显示在View中，但是复杂的应用场景不会这么简单的就能完成；大型站点的ViewModel的体积非常大，真的大的超乎我们的想象（当然这里面有历史原因），这么大的一个显示实体我们需要在不同的页面中呈现它会非常的棘手；然而小型站点不太会遇见ViewModel在几十个页面中显示的情况出现，一般页面也就是几十个差不多了； 在大型电子商务应用中，UI层的一个ViewModel不仅用来呈现数据还充当着与远程SOA接口通讯的DTO作用，如果为了结构清晰完全可以将ViewModel与DTO分开，但是有时候我们确实需要考虑额外的性能开销（有时候我们只能接受历史遗留的问题，技术债务累积多久就要还多久）； 这篇文章将讲解如何利用ASP

Microsoft.AspNetCore.Mvc.Versioning //引入程序集 .net core 下面api的版本控制作用不需要多说，可以查阅 https://www.cnblogs.com/dc20181010/p/11313738.html 普通的版本控制一般是通过链接、header此类方法进行控制，对ApiVersionReader进行设置，例如 services.AddApiVersioning(o => { //o.ReportApiVersions = true ; // 返回版本可使用的版本 o.ApiVersionReader = ApiVersionReader.Combine( new HeaderApiVersionReader( " api-version " ), new QueryStringApiVersionReader( " api-version " ));//通过 Header或QueryString 进行传值来判断api的版本 //o.DefaultApiVersion = new ApiVersion( 1 , 0 ); // 默认版本号 }); 或者使用 https://www.cnblogs.com/tdfblog/p/asp-net-core-api-versioning.html 这种方式

/// <summary> /// Linq 连接查询 /// Geovin Du /// 涂聚文 /// https://docs.microsoft.com/en-us/dotnet/csharp/linq/perform-inner-joins /// </summary> /// <param name="confirmed"></param> /// <param name="deaths"></param> /// <param name="recovered"></param> /// <returns></returns> public List<HistoryList> getUnionNumber(List<History> confirmed, List<History> deaths, List<History> recovered) { List<HistoryList> list = new List<HistoryList>(); if (recovered.Count > 0) { HistoryList newinfo = null; //1 种方法 var newinfto = (from d in confirmed join c in deaths on d.datename equals c.datename join s in

原文： https://bit.ly/2Cy3J5f 作者：Jon P Smith 翻译：王亮 声明：我翻译技术文章不是逐句翻译的，而是根据我自己的理解来表述的。其中可能会去除一些本人实在不知道如何组织但又不影响理解的句子。 这篇文章是关于如何使用 EF Core 实现软删除的，即表面上删除了数据，但数据并没有被物理删除，在需要的时候你还是可以把它读取出来的。软删除有很多好处，但也有一些值得注意的问题。这篇文章会教你使用 EF Core 实现一般的软删除和复杂的级联软删除。在此过程中，我还会介绍如何编写可重用代码来提高软删除解决方案的开发效率。 我假设你对 EF Core 已经有了一定的认识。但在真正讲软删除实现的方案之前，我们先来了解一下如何使用 EF Core 实现删除和软删除的一些基本知识。 本文是“深入理解 EF Core”系列中的第三篇。以下是本系列文章列表： 深入理解 EF Core：当 EF Core 从数据库读取数据时发生了什么？ 深入理解 EF Core：当 EF Core 写入数据到数据库时发生了什么？ 深入理解 EF Core：使用查询过滤器实现数据软删除（本文） 概要 ∮. 你可以使用全局查询过滤器（现在称为查询过滤器）为你的 EF Core 应用程序添加软删除功能。 ∮. 在应用程序中使用软删除的主要好处是可以恢复无意的删除和保留历史记录。 ∮.

介绍 　　1、TCP/IP(Transmission Control Protocol/Internet Protocol) 即传输控制协议/网间协议，是一个工业标准的协议集，它是为广域网(WANs)设计的。 　　2、UDP(User Data Protocol，用户数据包协议)是与TCP相对应的协议。它属于TCP/IP协议族中的一种。 　　3、应用层(Application)：应用层是一个很广泛的概念，有一些基本相同的系统级TCP/IP应用以及应用协议，也有许多的企业商业应用和互联网应用。 　　4、传输层(Transport)：传输层包括UDP和TCP，UDP几乎不对报文进行检查，而TCP提供传输保证。 　　5、网络层(NetWork)：网络层协议由一系列协议组成，包括ICMP、IGMP、RIP、OSPF、IP(v4、v6)等。 　　6、链路层(Link)：又称为物理数据网络接口层，负责报文传输。 网络4层协议 原理图 端口的分类 　　1、公认端口(Well Known Ports)：从0到1023，它们紧密绑定(binding)于一些服务。通常这些端口的通讯，明确了某种服务的协议。例如：80端口实际上总是HTTP通讯。 　　2、注册端口(Registered Ports)：从1024到49151。它们松散地绑定于一些服务。也就是说许多服务绑定于这些端口

前言 1、需求 需求很简单，就是在C#开发中高速写日志。比如在高并发，高流量的地方需要写日志。我们知道程序在操作磁盘时是比较耗时的，所以我们把日志写到磁盘上会有一定的时间耗在上面，这些并不是我们想看到的。 解决方案 2.1、简单原理说明 使用 列队 先缓存到内存，然后我们一直有个 线程 再从列队中写到磁盘上，这样就可以高速高性能的写日志了。因为速度慢的地方我们分离出来了，也就是说程序在把日志扔给列队后，程序的日志部分就算完成了，后面操作磁盘耗时的部分程序是不需要关心的，由另一个线程操作。 俗话说，鱼和熊掌不可兼得，这样会有一个问题，就是如果日志已经到列队了这个时候程序崩溃或者电脑断电都会导致日志部分丢失，但是有些地方为了高性能的写日志，是否可以忽略一些情况，请各位根据情况而定。 2.2、示例图 关键代码部分 这里写日志的部分LZ选用了比较常用的 log4net ，当然也可以选择其他的日志组件，比如nlog等等。 3.1、日志至列队部分 第一步我们首先需要把日志放到列队中，然后才能从列队中写到磁盘上。 public void EnqueueMessage( string message, FlashLogLevel level, Exception ex = null ) { if ((level == FlashLogLevel.Debug && _log