摘要：在线：读取和修改在一个线程中。离线：读取和修改不在一个线程中。在线悲观锁概念：A和B依次读取了数据，先读取的执行修改会成功，后读取的执行修改回失败。思路：事务隔离级别或数据库锁。离线悲观锁概念：A打开了编辑界面，B就不能打开编辑界面了。思路：自己实现锁。在线乐观锁概念：A和B依次读取了数据，先执行修改的会成功，后执行修改的会失败。思路：版本字段。离线乐观锁概念：A和B依次打开了编辑界面，先执行修改的会成功，后执行修改的会失败。思路：版本字段。备注针对乐观锁和悲观锁，后面我会详细写文章。 阅读全文

摘要：背景我在上篇文章“.NET：可扩展的单据编号生成器 之 顺序号（防止重复）”中介绍了如何使用“种子表”和“悲观锁”解决顺序号的问题。昨天找朋友讨论，说这种速度不够高，今天就稍微改进一下，引入一个内存缓冲区，提高生成的速度。思路引入内存缓冲区后，顺序号的生产流程变为：在内存中维护一个顺序号区间，在这个区间内，就直接查内存，否则更新种子表并重新更新内存区间。还是直接看代码吧。实现代码下载：http://yunpan.cn/Q5jj5yedRAtk5。SeedCodeRuleProvider.cs 1 using System; 2 using System.Collections.Generi.. 阅读全文

摘要：背景我在上篇文章“.NET：可扩展的单据编号生成器 + 简单的解释器”中介绍了一个简单的单据编号框架。有朋友留言问如何实现“顺序号，且不能重复”，本篇文章就针对这个问题用上篇介绍的框架进行实现。思路顺序号 = 上次顺序号 + 步长根据上面的公式，问题可以化解为：如何获取上次顺序号？获取上次顺序号有两种方式：扫描单据表，找出最新的一条记录。引入种子表，种子表记录了最新的顺序号。因为生成的顺序号不能重复，这里就有了并发的要求，为了最大限度的提高并发性，我选择2（引入种子表）。并发处理可以选择：悲观锁或乐观锁，这里为了简单，我选择悲观锁。实现代码下载：http://yunpan.cn/Q5KMUTA 阅读全文

摘要：背景在企业应用中单据编号的自定义是一个很常见的需求，能不能抽象一个通用的框架呢？之前写个一篇自定义密码强度的博文，感觉他们两个思路应该很相似。就让我们试试吧。思路这里的难点在于实现"解释器"，比如将"前缀_"解释为“工号生成器”，而且“解释器”的“规则”允许动态增加。实现代码下载类图核心代码CodeRuleGenerator.cs 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5 using System.Thre 阅读全文

摘要：背景在上篇文章中我介绍了如何用动态语言解释器执行路由规则，有很多朋友都给出了他们的选项，如下：集成解释器（Iron、Javascript等）。动态编译。解析为Lamda表达式。模板引擎。因为我觉得动态编译很有意思，结合T4可能会更舒服，这篇文章就用这个思路重新实现一下如何解析路由规则。思路T4 + 动态编译 = 无限可能如何使用动态编译解析这条规则（“LeaveDays>=5 && LeaveType=='病假'”）呢？思路有很多种，我立马想到的的有两种，将Leave的属性解析为某个方法的本地变量或方法所有类型的成员变量，下面就是动态编译后的方法：1 pu 阅读全文

摘要：背景做流程引擎最终避免不了一个问题：如何动态解析路由规则？几乎所有的审批流程都要求支持条件路由，比如：请假天数大于xx天时某个领导审批，否则其它人审批。常见的解决方法有：一、动态编译；二、解释执行。这篇文章就讲解如何使用Javascript引擎解释执行。思路静态语言集成动态语言解释器这种模式，在业界已经有很多惯例，如：很多C++开发者都用Lua在运行时修改配置。因为我对Javascript比较熟悉，所以准备搜索一下Javascript的解释器。在NuGet中用Javascript关键字进行搜索，搜索到了第2页就找到了一个解释器，安装一下，准备尝试吧。实现代码下载：http://yunpan.c 阅读全文

摘要：背景框架开发中，经常会用到“单例模式”，但是传统的单例模式不支持多态和运行时变化，在关注测试的今天，这种模式是不可行的。为了应对这种情况，微软又提供了另外一种模式，暂且将其称为“动态单例模式”。 我也想统一我的框架对单例的使用模式，因此就写了这篇文章。Microsoft.Practices.ServiceLocation 核心代码看完代码，如何使用这种模式就不用我多介绍了。IServiceLocatorView Code 1 using System; 2 using System.Collections.Generic; 3 4 namespace Microsoft.Practices.. 阅读全文

摘要：背景为了增强系统的安全，很多信息系统都提供了“IP限制”功能。功能虽然简单，但是从业五年来从来没有是实现过，因此就以博文的形式记录下来。思路实现应该很简答，功能可以分解为如下这三个问题：判断当前请求是否应用IP限制，有些请求不用应用IP限制的。当前客户IP是否包含在限制列表中。如何以AOP的形式应用IP限制1和2可以抽象为一个接口 1 using System; 2 3 namespace IpLimit.Codes 4 { 5 interface IIpLimitService 6 { 7 bool IsInExcludeUrl(string url); 8... 阅读全文

摘要：场景在企业应用中，我们经常需要限制用户的密码强度。问题如何以可扩展的方式支持不同企业应用的密码强度要求？思路算法思路：密码强度 = 求和（每个规则的强度 * 权重）。可扩展思路：以聚合的形式管理各种规则，让用户可以扩展自定义规则。实现设计类图示例代码PasswordStrengthService 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5 using System.Threading.Tasks; 6 7 namespace PasswordSt. 阅读全文

摘要：场景在WEB系统开发中，我们经常面对这样的需求：如何在一个请求中共享数据或对象实例？之前我都会用HttpContext.Current.Items。然而有一天我发现了两个事实：一、每个请求都是在一个线程中执行的；二、[ThreadStatic]可以标注某个静态字段为每个线程提供独立的存储。面对这两个发现，我得出了这个结论：可以用[ThreadStatic]替换HttpContext.Current.Items。问题可以用[ThreadStatic]替换HttpContext.Current.Items吗？实验实验素材 1 using System; 2 using System.Collect 阅读全文

摘要：前言程序开发的一个良好原则就是：“将使用和创建分开”。5年前有多少人采用这种风格呢？几乎没有。在IOC流行甚至泛滥的今天，还有一些团队没有使用IOC容器，有些是由于历史原因，有些是由于团队的文化。没有采用IOC的团队，找个机会拥抱一下吧。我一直在用IOC容器，在此介绍一下如何将IOC集成到WebForm和WebMvc的应用系统中。自动注入到ASPX和ASHX框架支持 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5 using System.Thread 阅读全文

摘要：前言刚开始做AJAX应用的时候，经常要手工解析客户端传递的参数，这个过程极其无聊，而且代码中充斥着：Request["xxx"]之类的代码。这篇文章的目的就是告诉初学者如何自动将客户端用AJAX发送的参数自动绑定为强类型的成员属性或方法参数。自动绑定到ASPX和ASHX框架支持 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5 using System.Threading.Tasks; 6 7 namespace Happy.Web 阅读全文

摘要：概念介绍类图如下：在常见的用例场景下，类图的对象图如下：问题在一个用例执行过程中，如何保证同一个界限上下文内的所有仓储实例可以共享同一个工作单元实例？解决方案1仓储采用依赖注入模式 + 使用IOC管理工作单元的生命周期（PerRequest或其它）。代码示例 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5 using System.Threading.Tasks; 6 7 using Autofac; 8 9 namespace AutoFacSt.. 阅读全文

摘要：概述几乎所有的企业应用程序都有多个用户和后台线程，它们可以同时更新数据库。两个数据库处理事务同时访问同一份数据的情形很常见，但是这样很可能导致数据库的不一致，或者引起应用程序行为异常。大部分应用程序必须处理多个事务并发访问同一份数据的情况，而这会影响业务层和表示层的设计。悲观锁你可以利用事务的隔离级别实现悲观锁，一般用“可重复读”和“串行化”就可以满足悲观锁的要求。从表面上看，这种方法看似非常简单，但是这类事务也存在问题，由于隔离事务如何实现完全由平台或数据库提供，因此有时他们会导致性能降低，令人无法接受 。鉴于此，许多应用程序都避免使用这类事务，转而采用乐观锁。乐观锁处理并发更新的另一种方式 阅读全文

摘要：名称解释悲观锁定义：我修改数据的时候，不允许别人修改数据。意图：并发很容易发生（悲观者经常认为某件坏事会发生在自己身上）。场景：绩效评分的过程，因为每个评估人评分后都要修改评估结果表的同一行记录，而且经常是在同一个时间段进行的评分，评分的过程就适合用悲观锁。乐观锁定义：谁都可以修改数据，提交的时候和数据库做比较，如果数据在这期间发生了变化，有两种处理思路：1、失败；2、合并后提交。意图：并发不容易发生（乐观者经常认为某件坏事不会发生在自己身上）。场景：多个人事管理员都可以修改劳动合同，因为这种并发场景很少发生，因此此处采用乐观锁会好很多。离线定义：也叫长事务；一次业务过程需要多次的和服务器通信 阅读全文

摘要：并发可能产生的三种问题（测试代码）脏读定义：A事务执行过程中B事务读取了A事务的修改，但是A事务并没有结束（提交），A事务后来可能成功也可能失败。比喻：A修改了源代码并且并没有提交到源代码系统，A直接通过QQ将代码发给了B，A后来取消了修改。代码示例 1 [TestMethod] 2 public void 脏读_测试() 3 { 4 //前置条件 5 using (var context = new TestEntities()) 6 { 7 ... 阅读全文