EntityFramework

[TOC] ←不知道为啥没生成目录，Sorry 本文地址： https://www.cnblogs.com/oberon-zjt0806/p/12215717.html 注意 ：本篇大量地使用了mermaid绘制图表，加载需要较长的时间，请见谅 O 前请提要 在第1期中，我们通过一个简单的过程构建了一个ASP.NET的初始项目，当然，实际上这个项目也是一个.NET Core的项目。因为在第2期中我们提到过，.NET Core的项目本身就基于.NET Framework基础之上扩展的。 构建一个项目的过程如下： 这里有图，请稍等片刻 graph LR install(安装dotnet) create(创建WebApp项目) edit(编辑代码) trust(信任开发证书) run(运行项目) install-->create create-->edit edit-->trust trust-->run 但是，这只是站在一种不透明的视角下对ASP.NET Core的宏观开发过程进行的一次概览和简单尝试，我们实际上并不清楚ASP.NET的内部构造和运作机理。 I Web的诸视角 I.1 用户视角 可以很负责任的说，实际上Web在用户眼里就是这些东西：一个鼠标+一个键盘+一个浏览器 是的，用户只需要使用浏览器输入网址，只要运气够好的话（比如网络通信没有问题或者远端也没什么问题的话

题外话： 接上篇吧。上篇主要是介绍下LayUI的使用，太兴奋手打代码去了- -。 其实这个项目用了Unity这个IOC框架，毕竟人要有梦想。感兴趣的可以自己去了解下，后面有机会会说说对于IOC和DI的个人拙见以及Unity的使用。 进入正题。 二.WebApi 一个有梦想的咸鱼做的一个有梦想的demo项目就需要有梦想的考虑后期维护与扩展，那么就需要从建项目开始做好文件分类。 打开VS，选择ASP .NET Web应用程序(.NET Framework)创建一个新的项目命名Demo，然后选择Web Api，然后建立项目。注意看项目下有个Area的文件夹，作用呢其实就是可以区分控制器，方便管理，而且控制器名称可以重名。 毕竟是个B/S项目，后台所接收的请求都属于http请求，要处理这些请求后台，就会涉及到安全问题，也就是权限问题，毕竟要有梦想，还是可以发布上服务器的。而这个安全问题并不是只用 用户登录验证就能解决的，这时候就会涉及到权限问题，参考淘宝，你可以随意浏览，但是一些额外操作则需要登录。 所以这里我是考虑FormsAuthenticationTicket身份验证配合授权属性AuthorizeAttribute。 Ticket，顾名思义，想入场看比赛是需要门票的，那么想进入自己的网站或者有数据库操作时，我们可以为用户设置门票。 进而小朋友些许问号，演唱会门票还有前排后排区别

原地址：http://www.cnblogs.com/fly_dragon/archive/2011/06/05/2073084.html 正文： 在介绍Entity Framework的修改实体到数据库的方法之前呢，我们先简要的介绍一下ObjectContext的处理机制。 1、ObjectContext的处理机制 ObjectContext是Entity Framework封装了数据库访问的上下文，以及实体的映射关系元数据信息等。EF帮我们封装好了这么一个统一的接口。让我们所有的操作都只通过这个一个实体上下文就可以实现了增删查改等所有对应数据库的操作。当然，我们要了解EF的生成SQL的机制我们才能更好的使用EF帮我们生成效率更高的SQL脚本。 看一个实例：下图所示项目截图与实体模型图（一个简单的例子） 然后看下面一段代码： static void Main( string [] args) { SchoolDBEntities schoolDB = new SchoolDBEntities(); Student student = new Student(); student.Address = " 北京上地 " ; student.Name = " 飞龙 " ; student.Phone = " 110 " ; schoolDB.Student.AddObject

本篇原文： Async and Stored Procedures 为何要采用异步？ 一个Web服务器肯定有可用线程的限制，那么在一些访问量特别大的情况下，线程肯定会消耗完；这个时候服务器肯定处理不了请求，必须等线程里处理结束才可以处理请求； 在非异步的时候，很多线程都处于等待状态，并不是一直在工作，而是在等类似于I/O等处理结束； 采用异步的时候，当一个处理在等待I/O处理结束的时候，可以先去做做其他事情； 所以异步处理可以使服务器更为高效，较低延迟的情况下处理更多的请求。 在早期的.NET中，写或者测试异步处理都是很复杂的，庆幸的是.NET 4.5以后写或者测试异步处理请求代码都非常简单，除非有特别的理由不采用异步处理； 异步处理确实会有一些多出来的系统开销，对于低流量的应用，效果可以忽略，但对于大流量的应用，效果是很明显的； 更专业的资料： Use .NET 4.5's async support to avoid blocking calls . 下面做些代码测试： 采用异步方式新建Department控制器： 自动生成的Index Action: 　　public async Task<ActionResult> Index() { var departments = db.Departments.Include(d => d.Administrator); return

前言 　　1、本文的前提条件：EF上下文是线程唯一，EF版本6.1.3。 　　2、网上已有相关API的详细介绍，本文更多的是作为我自己的个人学习研究记录。 　　3、 2018-05-31修改DbSession.cs部分严重错误代码！ 　　4、 2019-08-16 修改DbContextFactory.cs部分严重错误代码！ 疑问 用反编译工具翻开DbContext类可以看到EF本身就是一个实现了工作单元的仓储层，每运行一次DbContext.SaveChanges()便提交一次工作单元，那么本文要探究的问题来了： 如何在service层调用多个repository实例时实现工作单元？ 上述方法的正确性及原理是什么？ service层的工作单元实现 public class UsersService { private BaseRepository<User> userRepositroy = new BaseRepository<User> (); private BaseRepository<Log> logRepositroy = new BaseRepository<Log> (); public UsersService() { } public void DoSomething() { userRepositroy.Insert( new User());

旅程5：准备发布V1版本 添加功能和重构，为V1版本发布做准备。 “大多数人在完成一件事之后，就像留声机的唱片一样，一遍又一遍地使用它，直到它破碎，忘记了过去是用来创造更多未来的东西。” -- 弗雷娅.斯塔克 发布Contoso会议管理系统V1版本： 本章描述了团队为准备Contoso会议管理系统的第一个产品版本所做的更改。这项工作包括对前两章介绍的订单(Order)和注册(Registrations)限界上下文的一些重构和功能添加，以及一个新的会议管理(Conference Management)限界上下文和一个新的支付(Payment)限界上下文。 团队在此过程中进行的一个关键重构是将事件源(ES)引入订单(Order)和注册(Registrations)限界上下文中。 实现CQRS模式的一个预期好处是，它将帮助我们在复杂系统中管理变化。在CQRS旅程中发布一个V1版本将帮助团队评估当我们从V1版本迁移到系统的下一个产品版本时使用CQRS和ES的好处。剩下的章节将描述V1版本发布后的情况。 本章描述了团队在此阶段添加到公共网站的用户界面(UI)，并包括了对基于任务的UI的讨论。 本章的工作术语定义： 本章使用了一些术语，我们将在下面进行描述。有关更多细节和可能的替代定义，请参阅参考指南中的“ 深入CQRS和ES ”。 访问代码(Access code)

.NET(C#)主流ORM总揽 SqlSugar (国内) Dos.ORM (国内) Chloe (国内) StackExchange/Dapper (国外) Entity Framework (EF) (国外) NHibernate (国外) ServiceStack/ServiceStack.OrmLite (国外) linq2db (国外) Massive (国外) PetaPoco (国外) SqlSugar SqlSugar是国人开发者开发的一款基于.NET的ORM框架，是可以运行在.NET 4.+ & .NET CORE的高性能、轻量级 ORM框架，众多.NET框架中最容易使用的数据库访问技术。 特点： 开源、免费 国内开发者开发、维护； 支持.NET Core； 支持主流数据库，如：SQL Server,MySql,Oracle,Sqlite等； 维护更新及时 PetaPoco PetaPoco：轻量的POCO对象和数据库映射的ORM框架。 特点： 开源、免费 linq2db linq2db也是一款快速、轻量、类型安全的POCO对象和数据库映射的ORM框架。从构架上来说，linq2db是对比如：Dapper、PetaPoco这个的微ORM的进一步封装，但它不像Entity Framework那样笨重。它没有实现状态跟踪，需要自己处理实体的状态更改等。 推荐等级:★★★

转发请注明出处：https://home.cnblogs.com/u/zhiyong-ITNote/ 整个Demo是基于Controller-Service-Repository架构设计的，每一层之间是通过接口来实现解耦与调用的，参照了《ASP.NETMVC5框架揭秘》一书最后的网站示例架构，使用Unity容器作为DI容器以及实现AOP。 首先Repository文件夹里面的代码文件： 见百度网盘链接 整个Repository相当于三层架构里面的DAL数据访问层，它的作用就是调用数据库，封装了最基本的增删改查，当然你可以选择ADO.NET或是EntityFramework来做数据库驱动。 其次就是Services文件夹里面的代码文件： 见百度网盘链接 整个Services文件主要的功能就是调用下一层的Repository文件夹的相关类。我们在这里就是使用DI中的构造函数注入了，使用接口来实现解耦，这就需要用到unity容器了。这个层次是为上一层的控制器层服务的。 接下来就是Controller层了，这一层调用下一层Services也是基于接口，使用DI构造函数注入实现了解耦。 见百度网盘链接 准备做好了，接下来就是使用Unity容器来替换MVC框架默认的控制器工厂以及基于Unity的AOP设计。

关于Repository模式，直接百度查就可以了，其来源是《企业应用架构模式》。 我们新建一个Infrastructure文件夹，这里就是基础设施部分，EF Core的上下文类以及Repository层都放在这里面。 新建一个IReposotory的接口，其内容就是封装了基本的CRUD: public interface IRepository<TEntity> where TEntity : class { /// 获取当前实体的查询数据集 IQueryable<TEntity> Entities{ get ;} /// 获取当前实体的数据集 DbSet<TEntity> DbEntities{ get ;} /// <summary> /// Gets all objects from database /// </summary> /// <returns></returns> IQueryable<TEntity> All(); /// <summary> /// Gets objects from database by filter. /// </summary> /// <param name="predicate"> Specified a filter </param> /// <returns></returns> IQueryable<TEntity>

这篇文章行文结构对照微软博客， 结合本人意译和多年实践的回顾思考形成此次读书笔记。 Domian-driven Design 领域-驱动-设计（DDD）提倡 基于(用例相关的现实业务)进行建模 。 1. DDD的视角 DDD将 现实问题视为领域 ; DDD将 独立的问题描述为有界限的上下文 (一个有界上下文对应一个微服务)，并强调通用语言讨论这些问题 2. DDD提出的概念 许多技术概念和模式，例如充血模型(对应我们常写贫血模型)、值对象、聚合和聚合根规则。 3. 目前实施DDD的现状 有时DDD技术规则和模式被视为障碍/啰嗦，对于实施DDD方法而言，学习曲线比较陡峭。 不要为了实施而实施，最重要的是 使用通用语言编写与业务问题一致的领域代码 。 此外仅当您要实现具有复杂业务规则的微服务时，才应使用DDD方法，诸如CRUD服务之类的简单职责可以通过更简单的方法进行管理。 DDD模式可以协助 划分微服务边界 在已经确定的界限上下文，您可以为领域建模：实体模型、值对象和聚合，DDD与边界有关，微服务也与边界有关。 尽量保持小型微服务 划分界限上下文，要平衡两个目标： 创建尽可能小的微服务（这一点不应该成为主要动力) 要避免微服务之间过密的通信 这两个目标可能彼此矛盾，两者通过演进的方式达到平衡： 尽可能分解系统，直到在下次分解时感到服务通信迅速增加。 DDD微服务中的层