大话微服务架构之微服务框架微软ServiceFabric正式开源（三）
选择315这天分享一个好框架-ServiceFabric，它于昨天正式开源了！ 微软的 Azure Service Fabric 的官方博客在2017.3.24日发布了一篇博客 Service Fabric .NET SDK goes open source ，介绍了社区呼声最高的 Service Fabric 开源的情况以及当前的情况，当时开源了 Service Fabric的.NET SDK 部分，社区一直在期盼着 Service Fabric 的正式开源，经过了一年漫长的等待，2018年3月14日微软终于开源了 Service Fabric ，而且是以 MIT 许可下开放源代码，在官方博客宣布 https://blogs.msdn.microsoft.com/azureservicefabric/2018/03/14/service-fabric-is-going-open-source。 目前微软在 Github 上的开源地址是 https://github.com/Microsoft/service-fabric，目前的代码构建适用于 Linux 的 Service Fabric ，运行基本测试，有问题可以在上面提交 issue 和 PR 了，Windows 构建环境以及完整的 CI 环境还没有迁移过来。Windows 内部为 Service Fabric 开发了将近十年的内部服务，其中大部分时间都是微软内部平台，比如 Office365，Azure Stack 平台等，这意味着我们有近十年的内部微软工具可以在迁移之前完成迁移和流程细化，逐步全部开源，以后全部开发都在开源模式下进行开发工作。 微软去年漫长的一年时间里也开放了非常多的代码，包括包括 Reliable Services，Reliable Actors 和 ASP.NET Core 集成库，Azure 基础架构服务以及 Azure SQL DB，Azure Cosmos DB 和 Cortana 等大型解决方案都在使用 Service Fabric 构建。 Service Fabric 会带来如下好处： 支持创建无状态和有状态的微服务，通过云平台来伸缩他们，以应对高复杂度、低延迟、数据密集的情况 通过应用程序级别的感知和洞察，为微服务带来编排和自动化的优势 解决分布式系统诸如状态管理这样的难点，为开发人员提供应用程序生命周期管理的能力以便随着业务的增长无需重构系统架构 相关工具会集成到 Visual Studio 中，也会提供相应命令行工具，以便开发人员能够快速和轻易地上手 同时支持.NET和Java，这个特性特别适合目前国内原来很多投资于 .NET 平台。 那么接下来，我们主要来详细看下Service Fabric是什么？有哪些特性？ […]
View DetailsWindows 容器
什么是容器 容器是一种将应用程序包装到其自身隔离空间内的方法。 位于容器中的应用不了解该容器外存在的所有其他应用程序或进程。 应用程序成功运行所需的所有依赖项也存在于此容器内。 无论容器移动到何处，应用程序都将始终得到满足，因为应用程序与其运行所需的一切都已绑定在一起。 这就好像是一个厨房。 我们打包所有的电器和家具、锅碗瓢盆、洗洁精和毛巾。 这便是我们的容器 我们现在可以带着这个容器，将它放在任何喜欢的入住公寓中，厨房还会是这个厨房。 我们所需做的全部工作就是为它接通水电，然后我们便可以立即开始烹饪（因为我们拥有所有需要的器具！） 容器在很大程度上就像是这个厨房。 可以有不同类型的房间以及许多相同类型的房间。 重要的一点是容器与其所需的一切内容打包在一起。 在此处观看简短概述：基于 Windows 的容器：使用企业级控制的现代应用开发。 容器基础知识 容器是独立的、资源受控制的和可移植的运行时环境，在主机或虚拟机上运行。 在容器中运行的应用程序或进程与所有需要的依赖项和配置文件打包在一起；在它看来，容器之外似乎没有任何其他进程在运行。 容器的主机为容器预配一组资源，且容器只会使用这些资源。 在容器看来，除了已经为其提供的资源之外，不存在其他资源，因此它不能接触到可能已为相邻容器预配的资源。 在你开始创建和使用 Windows 容器时，以下关键概念将会很有用。 容器主机：使用 Windows 容器功能配置的物理或虚拟计算机系统。 容器主机将运行一个或多个 Windows 容器。 容器映像：在对容器文件系统或注册表进行修改时（如软件安装），将在沙盒中捕获这些修改。 在许多情况下，你可能希望捕获此状态，以便可以创建继承这些更改的新容器。 这就是映像的本质：一旦容器停止，你便可以放弃该沙盒，或者可以将其转换为新的容器映像。 例如，让我们想象你已从 Windows Server Core 操作系统映像部署一个容器。 然后你将 MySQL 安装到此容器中。 从此容器创建新映像将充当该容器的可部署版本。 此映像将只包含所做的更改 (MySQL)，但是将充当容器操作系统映像之上的一个层。 沙盒：容器启动后，将在此“沙盒”层中捕获所有的写入操作，如文件系统修改、注册表修改或软件安装。 容器操作系统映像：从映像部署容器。 容器操作系统映像是可能组成容器的许多映像层中的第一层。 此映像提供操作系统环境。 容器操作系统映像是不可变的。 也就是说，不能对其进行修改。 容器存储库：每次创建容器映像时，容器映像及其依赖项都会存储在本地存储库中。 这些映像可以在容器主机上重复使用多次。 容器映像还可以存储在公共或私有注册表（如 DockerHub）中，以便可以在许多不同的容器主机上使用它们。 对于熟悉虚拟机的人员而言，容器可能具有令人难以置信的相似性。 容器在操作系统上运行、具有文件系统，并且可以通过网络访问，就像它是物理或虚拟计算机系统一样。 话虽如此，但容器背后的技术和概念与虚拟机有很大不同。 Microsoft Azure 专家 Mark Russinovich 有一篇精彩的博客文章详述了这些差异。 Windows 容器类型 Windows 容器包括两个不同的容器类型或运行时。 Windows Server 容器 – 通过进程和命名空间隔离技术提供应用程序隔离。 Windows Server 容器与容器主机和该主机上运行的所有容器共享内核。 这些容器不提供敌对安全边界，不应该用于隔离不受信任的代码。 由于共享内核空间，这些容器要求具有相同的内核版本和配置。 Hyper-V 隔离 – 通过在高度优化的虚拟机中运行每个容器，在由 Windows Server 容器提供的隔离上扩展。 在此配置中，容器主机的内核不与相同主机上的其他容器共享。 这些容器旨在托管敌对多租户，并且具有与虚拟机相同的安全保证。 由于这些容器与主机或主机上的其他容器不共享内核，它们可运行（与受支持的版本）采用不同版本和配置的内核 – 例如 Windows […]
View DetailsNET编程之事件总线（Event Bus）
1. 引言 事件总线这个概念对你来说可能很陌生，但提到观察者（发布-订阅）模式，你也许就很熟悉。事件总线是对发布-订阅模式的一种实现。它是一种集中式事件处理机制，允许不同的组件之间进行彼此通信而又不需要相互依赖，达到一种解耦的目的。 我们来看看事件总线的处理流程： 了解了事件总线的基本概念和处理流程，下面我们就来分析下如何去实现事件总线。 2.回归本质 在动手实现事件总线之前，我们还是要追本溯源，探索一下事件的本质和发布订阅模式的实现机制。 2.1.事件的本质 我们先来探讨一下事件的概念。都是读过书的，应该都还记得记叙文的六要素：时间、地点、人物、事件（起因、经过、结果）。 我们拿注册的案例，来解释一下。 用户输入用户名、邮箱、密码后，点击注册，输入无误校验通过后，注册成功并发送邮件给用户，要求用户进行邮箱验证激活。 这里面就涉及了两个主要事件： 1，注册事件：起因是用户点击了注册按钮，经过是输入校验，结果是是否注册成功。 2，发送邮件事件：起因是用户使用邮箱注册成功需要验证邮箱，经过是邮件发送，结果是邮件是否发送成功。 其实这六要素也适用于我们程序中事件的处理过程。开发过WinForm程序的都知道，我们在做UI设计的时候，从工具箱拖入一个注册按钮（btnRegister），双击它，VS就会自动帮我们生成如下代码： void btnRegister_Click(object sender, EventArgs e) { // 事件的处理 } 其中object sender指代发出事件的对象，这里也就是button对象；EventArgs e 事件参数，可以理解为对事件的描述 ，它们可以统称为事件源。其中的代码逻辑，就是对事件的处理。我们可以统称为事件处理。 说了这么多，无非是想透过现象看本质：事件是由事件源和事件处理组成。 2.2. 发布订阅模式 定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。 ——发布订阅模式 发布订阅模式主要有两个角色： 1，发布方（Publisher）：也称为被观察者，当状态改变时负责通知所有订阅者。 2，订阅方（Subscriber）：也称为观察者，订阅事件并对接收到的事件进行处理。 发布订阅模式有两种实现方式： 1，简单的实现方式：由Publisher维护一个订阅者列表，当状态改变时循环遍历列表通知订阅者。 2，委托的实现方式：由Publisher定义事件委托，Subscriber实现委托。 总的来说，发布订阅模式中有两个关键字，通知和更新。 被观察者状态改变通知观察者做出相应更新。 解决的是当对象改变时需要通知其他对象做出相应改变的问题。 如果画一个图来表示这个流程的画，图形应该是这样的： 3 实现发布订阅模式 相信通过上面的解释，对事件和发布订阅模式有了一个大概的印象。都说理论要与实践相结合，所以我们还是动动手指敲敲代码比较好。 我将以『观察者模式』来钓鱼这个例子为基础，通过重构的方式来完善一个更加通用的发布订阅模式。 先上代码： /// <summary > /// 鱼的品类枚举 /// </summary > public enum FishType { 鲫鱼, 鲤鱼, 黑鱼, 青鱼, 草鱼, 鲈鱼 } 钓鱼竿的实现： /// <summary > /// 鱼竿（被观察者） /// </summary > public class FishingRod { public delegate void FishingHandler(FishType type); //声明委托 public event FishingHandler FishingEvent; //声明事件 public void ThrowHook(FishingMan man) { Console.WriteLine("开始下钩！"); //用随机数模拟鱼咬钩，若随机数为偶数，则为鱼咬钩 if (new Random().Next() % 2 == 0) { var type = (FishType) new Random().Next(0, 5); Console.WriteLine("铃铛：叮叮叮，鱼儿咬钩了"); if (FishingEvent != null) FishingEvent(type); } } } 垂钓者： /// <summary > /// 垂钓者（观察者） /// </summary > public class FishingMan { public FishingMan(string name) { Name = name; } public string Name { get; set; } public int FishCount { get; set; } /// <summary > /// 垂钓者自然要有鱼竿啊 /// </summary > public FishingRod FishingRod { get; set; } public void Fishing() { this.FishingRod.ThrowHook(this); […]
View Details分布式事务 ( DTS ) 你必须知道的事儿
目前云计算、大数据、互联网领域的大部分系统都采用了SOA、微服务化的架构。一个涉及端到端全链路的业务操作往往会由多个服务和数据库实例共同完成。因此，在一致性要求较高的业务场景中，如何保证多个服务之间RPC调用后的数据一致将成为关键点。 一、分布式系统/SOA/微服务架构的特点： 在大型分布式系统中要同时能够满足，分布式一致性(Consistency)、可用性(Availability)和分区容忍性(Partitiontolerance)，是不存在的。在大多数情况下只能满足其中的2项，而实现系统的最终一致性(Base理论)。 ( 1 ) CAP特点： a.一致性(Consistency):( 同样数据在分布式系统的各个节点上都是一致的) b.可用性(Availability):( 所有在分布式系统活跃的节点都能够处理操作且能响应查询) c.分区容忍性(Partition Tolerance) :(如果出现了网络故障、一部分节点无法通信，但是系统仍能够工作) ( 2 ) ACID特点： a.原子性(Atomicity) 一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 b.一致性(Consistency) 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。 c.隔离性(Isolation) 指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。 d.持久性(Durability) 指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。 二、分布式事务的基本介绍 分布式事务服务（Distributed Transaction Service，DTS）是一种分布式事务框架，用来确保在大规模分布式/微服务环境下端到端业务操作的最终一致性。 由CAP定理可知，任何大型的分布式系统/微服务在一致性、可用性和分区容忍这三点上只能保证其中的两点。由于在分布式系统中经常发生丢包、网络故障，分区容忍性是必须要满足的，同时为了兼顾高可用性，绝大部分系统都将强一致性需求转化成最终一致性的需求，并通过幂等机制保证了数据的最终一致性。 三、常用的分布式技术介绍 ( 1 ) 本地消息表（经典的ebay模式） 该方案的核心思想在于分布式系统在处理任务时通过消息日志的方式来异步执行。消息日志可以存储至本地文本、数据库或消息队列，然后再通过业务规则定时任务或人工自动重试。以在线支付系统的跨行转账为例： 第一步，伪代码如下，对用户id为A的账户扣款1000元，通过本地事务将事务消息(包括本地事务id、支付账户、收款账户、金额、状态等)插入至消息表：
|
1 2 3 4 5 6 7 8 9 |
Begin transaction update user_account set amount = amount - 1000 where userId = 'A' insert into trans_message(xid,payAccount,recAccount,amount,status) values(uuid(),'A','B',1000,1); end transaction commit; |
第二步，通知对方用户id为B，增加1000元，通常通过消息MQ的方式发送异步消息，对方订阅并监听消息后自动触发转账的操作；这里为了保证幂等性，防止触发重复的转账操作，需要在执行转账操作方新增一个trans_recv_log表用来做幂等，在第二阶段收到消息后，通过判断trans_recv_log表来检测相关记录是否被执行，如果未被执行则会对B账户余额执行加1000元的操作，并会将该记录增加至trans_recv_log,事件结束后通过回调更新trans_message的状态值。 ( 2 ) 消息中间件 a.非事务消息中间件 这里仍然以上面跨行转账为例，我们很难保证在扣款完成之后对MQ投递消息的操作就一定能成功。这样一致性似乎很难保证。以下伪代码说明了消息投递的异常：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
try{ boolean result = dao.update(model);//更新数据库失败抛出异常 if(result){ mq.send(model);//如果MQ超时或者接收方处理失败,抛出异常 } }catch(Exception ex){ rollback();//如果异常回滚 } |
对于以上的运行情况主要有以下几种： 操作数据库成功，向MQ中投递消息也成功，该属于正常情况，一切都OK。 操作数据库失败，不会向MQ中投递消息了。 操作数据库成功，但是向MQ中投递消息时失败，向外抛出了异常，刚刚执行的更新数据库的操作将被回滚。 从上面分析的几种情况来看，基本上能确保,发送消息的可靠性。我们再来分析下消费者端的问题： 1.接收者取出消息后，消费者对应的业务操作要执行成功。如果业务执行失败，消息不能失效或者丢失。需要保证消息与业务操作一致。 2.尽量确保消息的幂等性。如果出现重复消息投递，能够进行幂等而不对业务产生影响。 b.支持事务的消息中间件 Apache开源的RocketMQ中间件能够支持一种事务消息机制，确保本地操作和发送消息的异步处理达到本地事务的结果一致。 第一阶段，RocketMQ在执行本地事务之前，会先发送一个Prepared消息，并且会持有这个消息的接口回查地址。 第二阶段，执行本地事物操作。 第三阶段，确认消息发送，通过第一阶段拿到的接口地址URL执行回查，并修改状态，如果本地事务成功，则修改状态为已提交，否则修改状态为已回滚。 其中，如果第三阶段的确认消息发送失败后，RocketMQ会有定时任务扫描集群中的事务消息，如果发现还是处于prepare状态的消息，它会向消息发送者确认本地事务是否已执行成功。RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息的发送与本地事务同时成功或同时失败。 再回到上面转账的例子，如果用户A的账户余额已经减少，且消息已经发送成功，作为消费者用户B开始消费这条消息，这个时候就会出现消费失败和消费超时两个问题，解决超时问题的思路就是一直重试，直到消费端消费消息成功，整个过程中有可能会出现消息重复的问题，就需要采用前面说的幂等方案来进行处理。 分布式事务—2PC协议 为了解决大型分布式/微服务系统中的一致性问题，业界比较流行的做法是采用比较著名的有二阶提交协议（2 Phase Commitment Protocol）和三阶提交协议（3 PhaseCommitment Protocol）。考虑到性能问题，三阶段提交协议目前较少被采用。本文也主要介绍二阶段协议。 2PC协议 二阶段提交协议是分布式系统中较为经典的处理数据一致性的解决方案。在大型的集群环境中，对于单体微服务本身而言虽然能够通过代码质量、Mock测试等方法来确保自身服务的可用性，但是无法能够保证其他服务的可用性。当一个全链路的端到端业务操作，常常会跨多个节点、多个应用，为了能够保证全局事务的ACID特性，需要引入一个协调组件(这里称之为TM)来控制所有服务参与者(这里称之为RM)的操作结果，根据所有参与者的反馈结果来决定整个分布式事务究竟是提交还是回滚的结果。 第一阶段：称为准备(prepare)阶段。事务协调者向各个服务应用发送prepare请求，服务应用在得到请求后做预处理操作，预处理可能是做预检查，也可能是把请求临时存储，可以理解为是一种试探性地提交。下面是一般的步骤： a.事务协调者会问所有的参与者服务，是否可以提交操作。 b.各个参与者开始事务执行的准备工作：如资源上锁，预留资源，写回滚/重试的log。 c.参与者响应协调者，如果事务准备工作成功，则回应“可以提交”，否则回应拒绝提交。 第二阶段：称为提交(commit)/回滚(rollback)阶段。是指事务真正提交或者回滚的阶段。如果事务协调者发现事务参与者有一个在prepare阶段出现失败，则会要求所有的参与者进行回滚。如果协调者发现所有的参与者都prepare操作都是成功，那么他将向所有的参与者发出提交请求，这时所有参与者才会正式提交。由此保证了要求全部提交成功，要么全部失败。下面是具体步骤： a.如果所有的参与者都回应“可以提交”，那么协调者向所有参与者发送“正式提交”的命令。参与者完成正式提交，并释放所有资源，然后回应“完成”，协调者收集各个服务的“完成”回应后结束事务。 b.如果有一个参与者回应“拒绝提交”，那么协调者向所有的参与者发送“回滚操作”，并释放所有的资源，然后回应“回滚完成”，协调者收集各个服务应用的“回滚”返回后，取消整体的分布式事务。 下图为二阶段的成功和失败示例图： 二阶段提交协议解决的是分布式系统/微服务架构中数据强一致性的问题，其原理简单，但缺点也是存在，主要缺点如下： a.单点问题：协调者在整个二阶段中的作用非常重要，一旦部署协调者组件服务的节点出现不可用宕机情况，那么会影响整个分布式系统的正常运行。 b.同步阻塞：二阶段提交执行过程中，所有服务参与者需要服从协调者的统一调度，期间处于阻塞状态，会一定程度上影响整个系统的效率。 from:https://blog.csdn.net/WuLex/article/details/79311776
View DetailsNuGet学习笔记(3) 搭建属于自己的NuGet服务器
在上一篇NuGet学习笔记(2) 使用图形化界面打包自己的类库 中讲解了如何打包自己的类库，接下来进行最重要的一步，从零开始搭建属于自己的NuGet服务器，诚然园子里及其它很多地方已经有完全写好的NuGet服务源码，我们只需要拿来发布一下就ok了，运行也很正常，但作为一名合格的程序猿，不建议这种拿来主义尤其时你自己可以搞定的时候，用别人写好的东西总有些心里不踏实，当有一天它出问题了你的悲剧就开始了，下面进入我们今天的主题 创建NuGetServer Web站点 1.新建Web站点，选择 文件-->新建项目-->Asp.Net 空 Web应用程序 2.选择 工具-->Library Package Manager-->Package Manager Console 打开NuGet命令行控制台 3.在控制台输入Install-Package NuGet.Server (请保持Package source:官方源，即 Nuget offical package source，一般默认即为官方Package源) 4.回车确认后开始下载并安装NuGet.Server类库及相关引用，并自动添加引用到项目 注:具体输出根据版本不同会略有不同 自动添加的引用 5.在控制台输入 Get-Package 可以看到刚刚安装的类库 6.除添加类库引用外，还自动添加了一些文件(关于这些文件及其作用本文不做探讨，有兴趣的可以自行研究下，都很简单) /App_Readme/ /App_Readme/Elmah.txt /DataServices/ /DataServices/Packages.svc /DataServices/Routes.cs /Packages/ /Packages/Readme.txt /Default.aspx /favicon.ico /packages.config 同时Web.config也被修改，添加了一些配置项 7.至此NuGet.Server站点已经创建完毕，恩，你没有看错，就是这么简单，接下来部署到本地或IIS站点即可使用了 发布站点到IIS 1.发布网站到本地 2.IIS里面建立站点www.mynuget.com，主机头www.mynuget.com，应用程序池为.Net4.0集成模式，目录指向站点发布的目录 3.设置hosts 将www.mynuget.com执向本机 4.设置好hosts后，重新打开浏览器输入网址：http://www.mynuget.com/ 5.查看已经发布的类库包 http://www.mynuget.com/nuget/Packages （可以把已经打好包的类库放到网站下的Packages文件夹下即可） 添加本地站点到包包数据源 1.选择 工具-->Library Package Manager-->Package Manager Settings 2.输入名称 MyNuGetServer及包包源地址 http://www.mynuget.com/nuget 点击Add完成源添加 7.查看刚刚添加的类库源 工具-->Library Package Manager-->Manager NuGet Packages for Solution… 点击刚添加的源MyNuGetServer可以看到我们放到站点下的类库包，选中需要的包包点击 Install完成安装 8.也可以在控制台下安装，将类库源执行我们建立的源 MyNuGetServer，控制台下输入Install-Package Winista.HtmlParser完成安装 现在我们已经成功的搭建了自己的NuGet服务器。 注意点： 1.NuGet包包是放置在站点根目录下面的Packages文件夹下，如需要改变可以在配置文件packagesPath中进行设置，可以设置为相对目录或者物理目录
|
1 2 3 4 5 6 7 |
<appSettings> <!-- Change the path to the packages folder. Default is ~/Packages. This can be a virtual or physical path. --> <add key="packagesPath" value="" /> </appSettings> |
2.如何管理我们的包包，可以根据需要自行写个上传下载的文件管理功能，需要时上传到Packages文件下，不需要了删除即可，也可以像我一样写了个FTP服务，使用ftp上传下载 3.最好是为NuGet单独建立个站点这样管理着方便，若不方便建立独立站点可以随便找个现有的web站点，在里面安装NuGet.Server然后发布即可 回头看整个过程:安装NuGet扩展，下载网上的类库包供自己使用，打包自己的类库，搭建自己的NuGet服务器，整个流程基本走完了，剩下的就是我们如何去利用好NuGet这个强大的工具了。 源文件下载：NuGet.rar from:https://www.cnblogs.com/lzrabbit/archive/2012/05/01/2477873.html
View DetailsNuGet学习笔记(2) 使用图形化界面打包自己的类库
上文NuGet学习笔记(1) 初识NuGet及快速安装使用说到NuGet相对于我们最重要的功能是能够搭建自己的NuGet服务器，实现公司内部类库的轻松共享更新。在安装好NuGet扩展后，我们已经能够通过NuGet轻松下载自己需要的类库，下面来说一说如何将自己的项目类库进行打包发布 使用图形界面打包自己的类库 NuGet可以使用NuGet.exe在命令行下进行类库打包，也可以使用图形化界面进行打包，估计很多朋友都和我一样对不熟悉的命令行有些感冒，所以在此仅讲述下使用图形化界面进行类库打包 1.首先下载 包包管理器 NuGetPackageExplorer，顾名思义，包包管理器可以用来创建新的类库包，也可以浏览已经创建好的类库包 2.下载完成后，双击 NuGetPackageExplorer.application 进行安装，安装完成后会在桌面上生成一个NuGet Package Explorer 的快捷方式 3.双击NuGet Package Explorer出现启动界面，选择Create a new package(Ctrl+N)创建一个新包 4.选择菜单 Edit > Edit Package Metadata （或者 CTRL + K) 编辑包包信息 这里可以编辑类库包的信息和添加类库、程序集的引用解释下几个比较重要的字段 Id：用于定位类库包的唯一标示，如在命令行下执行 Install-Package MyPackage 这里的MyPackage就是包包的Id值 Version:类库的版本号，这里建议和程序集的真实版本号保持一致，以免发生混淆 Dependencies:此类库依赖的程序集，根据实际情况添加依赖类库的Id和版本号，若无留空即可，这里需要注意下填写的依赖类库需要在NuGet服务器上能找到，否则无法完成自动引用添加 Framework assemblies:依赖的Framework 程序集，根据实际需要选择即可，一般无需设置 除以上四项以外其他属性根据实际情况修改即可，若自己用不修改也中，不过为了使用方便还是建议把类库描述(Description)填写下 5.编辑好包包信息后接下来添加DLL到包包中 可以选择 右键-->Add Existinng File… 选择dll添加，也可以直接拖拽DLL到 Package contents 窗口，此例选择拖拽方式 直接拖拽dll到窗口后，会出现提示:是否将 Winista.HtmlParser.dll放到lib 文件夹下，一般我们选择是 6.DLL添加完成后，快捷键Ctrl + K 修改包包信息Id为Winista.HtmlParser，版本号为1.8.0 7.信息修改和dll都添加完毕后，选择File --> Save(或Ctrl + S)将文件进行保存，默认文件名为Id + 版本号.nupkg 8.完成保存后如需要发布到网上，选择File--> Publish…(或Ctrl + P) 默认的发布地址是官网，发布 Key需要到官网去注册一个账号，然后就可以得到，这里不在复述，若无需发布直接关闭即可 ps:这里没有讲述如何打包项目文件，一般情况下我们自己将项目文件编译成DLL然后使用图形化界面打包即可满足需求，若实际工作需要高度集成完全自动化操作可自行去研究下官方文档http://docs.nuget.org/ 添加DLL默认会添加Lib文件夹，额外的菜单上还有很多.net文件夹，src等文件夹，这些文件夹只是对文件上的一个物理上的划分而已，只是为了帮助我们做好文件分类，没有其他的用途，dll文件可以随便放置，不过为了规范还是建议按照通常习惯来放置。 from:http://www.cnblogs.com/lzrabbit/archive/2012/05/01/2477607.html
View DetailsAutofac 组件、服务、自动装配 《第二篇》
一、组件 创建出来的对象需要从组件中来获取，组件的创建有如下4种(延续第一篇的Demo，仅仅变动所贴出的代码)方式： 1、类型创建RegisterType AutoFac能够通过反射检查一个类型,选择一个合适的构造函数,创造这个对象的实例。主要通过RegisterType<T>() 和 RegisterType(Type) 两个方法以这种方式建立。 ContainerBuilder使用 As() 方法将Component封装成了服务使用。
|
1 2 |
builder.RegisterType<AutoFacManager>(); builder.RegisterType<Worker>().As<IPerson>(); |
2、实例创建
|
1 |
builder.RegisterInstance<AutoFacManager>(new AutoFacManager(new Worker())); |
单例 提供示例的方式，还有一个功能，就是不影响系统中原有的单例：
|
1 |
builder.RegisterInstance(MySingleton.GetInstance()).ExternallyOwned(); //将自己系统中原有的单例注册为容器托管的单例 |
这种方法会确保系统中的单例实例最终转化为由容器托管的单例实例。 3、Lambda表达式创建 Lambda的方式也是Autofac通过反射的方式实现
|
1 2 |
builder.Register(c => new AutoFacManager(c.Resolve<IPerson>())); builder.RegisterType<Worker>().As<IPerson>(); |
4、程序集创建 程序集的创建主要通过RegisterAssemblyTypes()方法实现，Autofac会自动在程序集中查找匹配的类型用于创建实例。
|
1 2 |
builder.RegisterAssemblyTypes(Assembly.GetExecutingAssembly()); //在当前正在运行的程序集中找 builder.RegisterType<Worker>().As<IPerson>(); |
5、泛型注册 泛型注册通过RegisterGeneric() 这个方法实现，在容易中可以创建出泛型的具体对象。
|
1 2 3 4 5 6 |
//泛型注册,可以通过容器返回List<T> 如:List<string>,List<int>等等 builder.RegisterGeneric(typeof(List<>)).As(typeof(IList<>)).InstancePerLifetimeScope(); using (IContainer container = builder.Build()) { IList<string> ListString = container.Resolve<IList<string>>(); } |
6、默认的注册 如果一个类型被多次注册,以最后注册的为准。通过使用PreserveExistingDefaults() 修饰符，可以指定某个注册为非默认值。
|
1 2 3 4 5 6 7 8 9 |
ContainerBuilder builder = new ContainerBuilder(); builder.RegisterType<AutoFacManager>(); builder.RegisterType<Worker>().As<IPerson>(); builder.RegisterType<Student>().As<IPerson>().PreserveExistingDefaults(); //指定Student为非默认值 using (IContainer container = builder.Build()) { AutoFacManager manager = container.Resolve<AutoFacManager>(); manager.Say(); //输出我是一个工人 } |
如果不使用PreserveExistingDefaults()，那么将输出“我是一个学生”。 二、服务 Autofac有三种典型的方式区分服务，同一个服务的不同实现可以由类型，名称和键区分。 1、类型 类型是描述服务的基本方法
|
1 |
builder.RegisterType<Worker>().As<IPerson>(); //IPerson类型的服务和Worker的组件连接起来，这个服务可以创建Worker类的实例 |
并且上面的服务在自动装备中也有效
|
1 |
AutoFacManager manager = container.Resolve<AutoFacManager>(); |
2、名字 服务可以进一步按名字识别。使用这种方式时，用 Named()注册方法代替As()以指定名字:
|
1 |
builder.RegisterType<Worker>().Named<IPerson>("worker"); |
使用Name可以检索服务创建实例：
|
1 |
IPerson p = container.ResolveNamed<IPerson>("worker"); |
ResolveNamed()只是Resolve()的简单重载，指定名字的服务其实是指定键的服务的简单版本。 3、键 有Name的方式很方便，但是值支持字符串，但有时候我们可能需要通过其他类型作键。 例如，使用枚举作为key：
|
1 |
public enum DeviceState { Worker, Student } |
使用key注册服务，通过Keyed<T>()方法：
|
1 |
builder.RegisterType<Student>().Keyed<IPerson>(DeviceState.Student); |
显式检索 使用key检索服务以创建实例，通过ResolveKeyd()方法：
|
1 |
IPerson p = container.ResolveKeyed<IPerson>(DeviceState.Student); |
ResolveKeyd()会导致容器被当做 Service Locator使用，这是不被推荐的。应该使用IIndex type替代。 IIndex索引 Autofac.Features.Indexed.IIndex<K,V>是Autofac自动实现的一个关联类型。component可以使用IIndex<K,V>作为参数的构造函数从基于键的服务中选择需要的实现。
|
1 2 3 4 5 6 7 |
builder.RegisterType<Student>().Keyed<IPerson>(DeviceState.Student); using (IContainer container = builder.Build()) { IIndex<DeviceState, IPerson> IIndex = container.Resolve<IIndex<DeviceState, IPerson>>(); IPerson p = IIndex[DeviceState.Student]; p.Say(); //输出我是一个学生 } |
IIndex中第一个泛型参数要跟注册时一致，在例子中是DeviceState枚举。其他两种注册方法没有这样的索引查找功能，这也是为什么设计者推荐Keyed注册的原因之一。 三、自动装配 从容器中的可用服务中选择一个构造函数来创造对象，这个过程叫做自动装配。这个过程是通过反射实现的，所以实际上容器创造对象的行为比较适合用在配置环境中。 1、选择构造函数 Autofac默认从容器中选择参数最多的构造函数。如果想要选择一个不同的构造函数，就需要在注册的时候就指定它。
|
1 |
builder.RegisterType(typeof(Worker)).UsingConstructor(typeof(int)); |
这种写法将指定调用Worker(int)构造函数，如该构造函数不存在则报错。 2、额外的构造函数参数 有两种方式可以添加额外的构造函数参数，在注册的时候和在检索的时候。在使用自动装配实例的时候这两种都会用到。 注册时添加参数 使用WithParameters()方法在每一次创建对象的时候将组件和参数关联起来。
|
1 2 |
List<NamedParameter> ListNamedParameter = new List<NamedParameter>() { new NamedParameter("Id", 1), new NamedParameter("Name", "张三") }; builder.RegisterType<Worker>().WithParameters(ListNamedParameter).As<IPerson>(); |
在检索阶段添加参数 在Resolve()的时候提供的参数会覆盖所有名字相同的参数，在注册阶段提供的参数会覆盖容器中所有可能的服务。 3、自动装配 至今为止，自动装配最大的作用就是减少重复配置。许多相似的component无论在哪里注册，都可以通过扫描使用自动装配。
|
1 |
builder.RegisterAssemblyTypes(Assembly.GetExecutingAssembly()).As<IPerson>(); |
在需要的时候，依然可以创建指定的构造函数创建指定的类。
|
1 |
builder.Register(c => new Worker(2,"关羽")); |
四、程序集扫描 1、扫描 Autofac可以使用约定在程序集中注册或者寻找组件。 Autofac可以根据用户指定的规则在程序集中注册一系列的类型，这种方法叫做convention-driven registration或者扫描。
|
1 |
builder.RegisterAssemblyTypes(Assembly.GetExecutingAssembly()).Where(t => t.Name.EndsWith("Manager")); |
[…]
View DetailsC# 遍历类的属性并取出值
最近悟出来一个道理，在这儿分享给大家：学历代表你的过去，能力代表你的现在，学习代表你的将来。 十年河东十年河西，莫欺少年穷 学无止境，精益求精 今天有点胡思乱想，想遍历MVC Model的属性并取值： 这个方法还是很简单的，通过反射即可遍历属性，我总结的方法如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
namespace WeiXinApi.CommonCS { public class ForeachClass { /// <summary> /// C#反射遍历对象属性 /// </summary> /// <typeparam name="T">对象类型</typeparam> /// <param name="model">对象</param> public static void ForeachClassProperties<T>(T model) { Type t = model.GetType(); PropertyInfo[] PropertyList = t.GetProperties(); foreach (PropertyInfo item in PropertyList) { string name = item.Name; object value = item.GetValue(model, null); } } } } |
下面我们来简单测试下： 新建Model如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public class AddressInfo { public int Id { get; set; } public string userName { get; set; } public string userTel { get; set; } public string Addressdetail { get; set; } public int isMoren { get; set; } public AddressInfo() { Id = 1; userName = "陈卧龙"; userTel = "1813707015*"; Addressdetail = "江苏省苏州市工业园区国际科技园"; isMoren = 1; } } |
调用如下：
|
1 2 3 4 5 6 7 8 9 |
public partial class index : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { //Response.Redirect("/Home/Login"); AddressInfo model = new AddressInfo(); ForeachClass.ForeachClassProperties<AddressInfo>(model); } } |
测试结果如下： 经过测试，我们可以得到对象的各个属性及对应的值、 其实这块内容输入C# 反射系列，小弟也是误打误撞，撞入了C# 反射，索性每天学一点 from:https://www.cnblogs.com/chenwolong/p/fanshe.html
View DetailsC#遍历类的属性，然后给其赋值
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
public class PP { public string a { get; set; } public string b { get; set; } public string c { get; set; } } class Program { static void Main(string[] args) { Hashtable ht = new Hashtable(); ht.Add("a", "utf8"); ht.Add("b", "xxxx"); ht.Add("c", "xxxx"); PP config = new PP(); PropertyInfo[] propertys = config.GetType().GetProperties(); foreach (PropertyInfo property in propertys) { for (int i = 0; i < ht.Count; i++) { property.SetValue(config, ht[property.Name].ToString(), null); } } Console.WriteLine(config.a+"\t"+config.b); Console.ReadLine(); } } |
from:https://www.cnblogs.com/yanglang/p/6830982.html
View Details