解析大型.NET ERP系统 高质量.NET代码设计模式

1缓存Cache

系统中大量的用到缓存设计模式，对系统登入之后不变的数据进行缓存，不从数据库中直接读取。耗费一些内存，相比从SQLServer中再次读取数据要划算得多。缓存的基本设计模式参考下面代码：

privatestaticConcurrentDictionary<string,LookupDialogEntity>_cachedLookupDialogEntities=newConcurrentDictionary<string,LookupDialogEntity>();
if(!_cachedLookupDialogEntities.ContainsKey(key))
lookupDialog=_cachedLookupDialogEntities.GetOrAdd(key,lookupDialog);
else
_cachedLookupDialogEntities[key]=lookupDialog;

主要用到的数据结构是字典，字典中的项目不存在时，向其增加，以后再调用时，直接从内存中取值。

列举一下，我可以看到的ERP系统中应用缓存设计模式的地方，主要分数据缓存和对象缓存，资源缓存：

1)系统翻译ERP系统中的文句翻译内容保存在数据库表中，只需要在系统登入时读取一次，缓存到DataTable中。

2)系统参数登入系统之后，当前的财年，会计期间，采购单批核流程，物料编码长度，是否实施批号和序号，记帐凭证过帐前是否需要审核，成本核算的来源(物料成本，物料成本+人工成本，物料成本+人工成本+机器成本），这些参数都可以缓存在Entity中，用户修改这些参数值，需要提醒或是强制用户退出重新登入。

3)系统查询系统中可预定义一组查询语句，在代码中将查询语句转化为查询对象，将查询对象缓存，节省SQL语句到查询对象的转化时间。

4)对象实例以插件方式在搜索程序集中包含的系统功能时，搜索到后，会将程序功能对应的类型缓存，所以第二次执行功能的速度会相当快。参考下面的例子代码加深印象：

publicvoidOpenFunctionForm(stringfunctionCode)
{
functionCode=functionCode.ToUpper().Trim();
TypeformBaseType=null;

if(!_formBaseType.TryGetValue(functionCode,outformBaseType))
{
Assemblyassembly=Assembly.GetExecutingAssembly();
foreach(Typetypeinassembly.GetTypes())
{
try
{
object[]attributes=type.GetCustomAttributes(typeof(FunctionCode),true);
foreach(objectobjinattributes)
{
FunctionCodeattribute=(FunctionCode)obj;
if(!string.IsNullOrEmpty(attribute.Value))
{
if(!_formBaseType.ContainsKey(attribute.Value))
_formBaseType.Add(attribute.Value,type);

if(formBaseType==null&&attribute.Value.Equals(functionCode,StringComparison.InvariantCultureIgnoreCase))
formBaseType=type;
}

if(formBaseType!=null)
{
gotoFound;
}
}

}
catch
{

}
}
}
Found:
if(formBaseType!=null)
{
objectentryForm=Activator.CreateInstance(formBaseType)asForm;
FormfunctionForm=(Form)entryForm;
OpenFunctionForm(functionForm);
}

}

在我的通用应用程序开源框架中，有上面这个例子的完整代码。

5)资源缓存系统中会用到一些以嵌入方式编译到程序集中的资源文件，在搜索到资源文件后，也是以字典的方式缓存资源(图标Icon，图片Image，文本Text，查询语句Query)。

2查询优化QueryOptimize

这是个很容易理解的设计模式，贵在坚持。我们在读取数据时，只读取最少的可用的数据，避免读取不需要的数据。用查询语句表达如下，下面是没有效率的查询数据：

SELECT*FROMCompany

经过改善之后的语句，改成只读需要使用的数据，改善后的查询如下：

SELECTCompanyCode,CompanyNameFROMCompany

后者的性能会好很多。对于我使用的LLBLGenPro，把上面的代码转化为程序代码，也就是下面的例子程序所示：

IncludeFieldsListfieldList=newIncludeFieldsList();
fieldList.Add(FiscalPeriodFields.Period);
fieldList.Add(FiscalPeriodFields.FiscalYear);
fieldList.Add(FiscalPeriodFields.PeriodNo);

IFiscalPeriodManagerfiscalPeriodManager=ClientProxyFactory.CreateProxyInstance<IFiscalPeriodManager>();
FiscalPeriodEntityfiscalPeriodEntity=fiscalPeriodManager.GetFiscalPeriod(Shared.CurrentUserSessionId,this.VoucherDate,null,fieldList);

this.Period=fiscalPeriodEntity.Period;
this.FiscalYear=fiscalPeriodEntity.FiscalYear;
this.PeriodNo=fiscalPeriodEntity.PeriodNo;

即使没有接触过LLBLGenPro，也可感受到类型IncludeFieldsList的作用是为了挑选要读取的数据列，也就是要使用什么字段，就读什么字段，避免读取不需要的字段。

对于上面的程序，它的性能开销主要在读取数据和创建对象方面，为了性能再快一点，考虑读取数据转化为DataTable，可读性上有所降低但性能又提升了一些。

IRelationPredicateBucketfilterBucket=newRelationPredicateBucket();
filterBucket.PredicateExpression.Add(ShipmentFields.CustomerNo==this.CustomerNo);
filterBucket.PredicateExpression.Add(ShipmentFields.Posted==true);

filterBucket.Relations.Add(newEntityRelation(ShipmentDetailFields.OrderNo,SalesOrderDetailFields.OrderNo,RelationType.ManyToMany));
filterBucket.PredicateExpression.Add(ShipmentDetailFields.QtyShipped==SalesOrderDetailFields.Qty);

ResultsetFieldsfields=newResultsetFields(4);
fields.DefineField(ShipmentFields.RefNo,0);
fields.DefineField(ShipmentFields.PayTerms,1);
fields.DefineField(ShipmentFields.Ccy,2);
fields.DefineField(ShipmentFields.ShipmentDate,3);
System.Data.DataTableshipments=userDefinedQueryManager.GetQueryResult(Shared.CurrentUserSessionId,fields,filterBucket,null,null,false,false);

继续改善查询的性能，假设场景是销售订单表要读取客户编号和客户名称，我们直接在销售订单表中增加客户名称字段，这样每次加载销售订单时，可直接读取到销售订单表自身的客户名称字段，而不用左连接关联到客户表读取客户名称。

EntityFramework或是第三方的ORM查询接口，应该都具备上面列举的特性。

ORM查询不推荐使用LINQ，性能是主要考虑的方面。ORM框架将查询转化为实体对象时，因为不能预料到后面会用到实体的哪些属性，预先读取所有的字段绑定到属性中，性能难以接受，这跟前面提到的SELECT*读取所有字段是同样的意思，延迟绑定属性，用到属性时再读取相应的数据库字段，每用一个属性都去读取一次数据库，对数据库的连接次数过于频繁，也不可接受。

下面的写法是我最不能忍受的查询写法，参考代码中的例子：

EntityCollection<AccountsReceivableJournalEntity>journalCollection=adapter.FetchEntityCollection<AccountsReceivableJournalEntity>(filterBucket,1,sorter,null,fieldList);

AccountsReceivableJournalEntitylastJournal=journalCollection[journalCollection.Count-1];

为了取一个表中的最后一笔记录，居然将整个表都读取到内存中，再取最后一条记录。

这种查询可以改善成SELECTTOP1+ORDERBY，读一笔数据的性能肯定优于读取未知笔数据记录。

3延迟加载DelayLoad

在使用对象时，只有当需要使用对象的方法或属性，我们才实例化对象。设计模式的代码例子如下：

PayTermEntitypayTerm=null;
payTerms.TryGetValue(dataRow["PayTerms"].ToString(),outpayTerm);
if(payTerm==null)
{
payTerm=payTermManager.GetPayTerm(Shared.CurrentUserSessionId,dataRow["PayTerms"].ToString());
payTerms.Add(payTerm.PayTerms,payTerm);
}

突然想到这种模式就是系统缓存的实现方法。在类型中定义一个私有静态变量，使用这个变量时我们才去初始化它的实例。延迟加载避免了系统启动时创建所有缓存对象耗费的内存和时间，有些对象或许根本不会用到，也就不应该去创建。

比如用户仅登入进系统，没有做任何业务单据操作然后退出。如果在登入时就创建货币或付款条款的缓存，而用户又没有使用这些数据，影响了系统性能。

4后台线程与多线程BackgroundWorker/WorkerThreadBase

.NET提供了后台线程控件，解决了长时间操作避免主界面卡死的问题。在系统中，凡是涉及到数据库操作，不能在很短时间内完成的，都放到BackgroundWorker后台线程中执行。系统中大量使用BackgroundWorker的地方：

1)单据增删查改所有单据对数据的Insert,Delete,Update都用BackgroundWorker操作。

2)查询所有关于数据的查询封装到BackgroundWorker中执行。

3)数据操作类功能：数据初始化，数据再开始，核算供应商帐，核算客户帐，数据存档，数据备份，数据还原。

4)业务单据过帐，业务单据完成，业务单据取消，业务单据修改。

当没有界面时，无法使用BackgroundWorker，可以用多线程组件改善性能。参考下面的例子代码：

privatesealedclassLoadItemsWorker:WorkerThreadBase
{
privateMrpEntity_mrp;
privateConcurrentBag<DataRow>_itemMasterRows;

protectedoverridevoidWork()
{
//longtimeoperation
}

调用上面的多线程组件，参看下面的例子代码：

List<LoadItemsWorker>workers=newList<LoadItemsWorker>();
for(inti=0;i<MAX_RUNNING_THREAD;i++)
{
LoadItemsWorkerworker=newLoadItemsWorker(sessionId,this,mrp);
workers.Add(worker);
}
WorkerThreadBase.StartAndWaitAll(workers.ToArray());

多线程组件WorkerThreadBase可以在CodeProject上找到源代码和讲解文章。

5数据字典DataDictionary

主要介绍不可变的数据字典的设计模式，先看一下性别Gender的数据字典设计：

publicenumGender
{
[StringValue("M")]
[DisplayValue("Male")]
Male,

[StringValue("F")]
[DisplayValue("Female")]
Female
}

为枚举类型增加了二个特性，StringValue用于存储，DisplayValue用于界面控件中显示，这跟数据绑定中的介绍的数据源的ValueMember和DisplayMember是一样的原理。再来看使用代码：

Employeeemployee=...
employee.Gender=StringEnum<Gender>.GetStringValue(Gender.Male);

也可以这样调用获取显示的值DisplayValue:

stringdisplayValue=StringEnum<Gender>.GetDisplayValue(Gender.Male);

这样设计模式解决了数据字典的文档更新的烦恼。编写源代码同时就设计好了文档，想知道数据字典的值，直接打开枚举类型定义即可。

6校验-执行-验证Validate-Post-Verify

对业务逻辑的业务操作，遵守校验-执行-验证设计约定，来看一段代码加深印象：

try
{
adapter.StartTransaction(IsolationLevel.ReadCommitted,"PostInvoice");

this.ValidateBeforePost(sessionId,accountsReceivableAllocation);
this.Post(sessionId,accountsReceivableAllocation);
this.VerifyGeneratedVoucher(sessionId,accountsReceivableAllocation);

adapter.Commit();
}
catch
{
adapter.Rollback();
throw;
}

先校对要执行操作的数据，再对数据进行操作，操作完成之后，再对期望的数据进行验证。

比如发票生成凭证，先要验证发票上的金额是否大于零，开发票的时间是否是当前期间等业务逻辑，再执行凭证生成(Voucher)动作，最后验证生成的凭证的借贷方是否一致，是否考虑到小数点进位导致的借货方不一致，生成的凭证金额是否与原发票上的金额相等。

7执行前-执行-执行后OnBefore-Perform-OnAfter

第六条讲解是的业务记帐方法，第七条这里讲解的是公共框架与应用程序互动的方法。继承的.NET窗体或派生类要能改变基类的行为，需要设计一种方法来达到此目的。先看一段代码熟悉这种设计模式：

CancelableRecordEventArgse=newCancelableRecordEventArgs(this.CurrentEntity);
this.OnBeforeCancelEdit(e);
if(this._beforeCancelEdit!=null)
this._beforeCancelEdit(this,e);
if(e.Cancel)
returnfalse;

boolflag=this.DoPerformCancelEdit(this.CurrentEntity);

RecordEventArgsargs2=newRecordEventArgs(this.CurrentEntity);
this.OnAfterCancelEdit(args2);
if(this._afterCancelEdit!=null)
this._afterCancelEdit(this,args2);

为了加深了解这种设计模式，我对上面的代码段用两行空格分开成三个部分，下面详细讲解这三个部分：

OnBefore在执行操作前，派生类可以设定参数到基类中，影响基类的行为。比如可以执行一个事件，也可以向基类传递取消条件，派生类向基类传递Cancel=true的标志位，完全取消当前的操作。这是派生类影响基类行为的一种设计方式。另一种方法是抛出异常，异常会导致整个堆栈回滚。

Perform执行要做的操作，这个命名是按照.NET的规范。比如我们想在代码中直接执行按钮的点击事件，可以这样写调用代码的方法：btnOK.PerformClick();

OnAfter在执行完成后。可以对执行的结果重写，也可以调用派生类中的事件。

8元数据Metadata

框架能完成很多应用程序一句话调用就能完成的功能，元数据的功劳最大。系统中的实体对象的每个字段都有一张附加属性表，参考下面的代码定义：

privatestaticvoidSetupCustomPropertyHashtables()
{
_customProperties=newDictionary<string,string>();
_fieldsCustomProperties=newDictionary<string,Dictionary<string,string>>();
_customProperties.Add("SupportDocumentApproval",@"");
_customProperties.Add("SupportExternalAttachment",@"");
Dictionary<string,string>fieldHashtable;
fieldHashtable=newDictionary<string,string>();
_fieldsCustomProperties.Add("Recnum",fieldHashtable);
fieldHashtable=newDictionary<string,string>();
fieldHashtable.Add("AllowEditForNewOnly",@"");
fieldHashtable.Add("CapsLock",@"");
_fieldsCustomProperties.Add("RefNo",fieldHashtable);
fieldHashtable=newDictionary<string,string>();
fieldHashtable.Add("ReadOnly",@"");

看到上面的代码，当前实体的每一个属性都可以绑定一个Dictionary对象，这段代码是用代码生成器完成。于是发挥想象力，将字段的特殊属性放到实体属性的附加属性中，框架可完成很多基础功能。

看到上面的RefNo属性中增加了AllowEditForNewOnly和CapsLock两条元数据。在系统框架部分，代码参考如下：

Dictionary<string,string>fieldsCustomProperties=GetFieldsCustomProperties(boundEntity,bindingMemberInfo.BindingField);
if(fieldsCustomProperties!=null)
{
if(fieldsCustomProperties.ContainsKey("CapsLock"))
{
base.CharacterCasing=CharacterCasing.Upper;
}
elseif(!(this.AlwaysReadOnly||!fieldsCustomProperties.ContainsKey("AllowEditForNewOnly")))
{
this._allowEditForNewOnly=true;
}

元数据通过代码生成器的实体设计完成，框架获取实体代码的元数据，做一些控件属性上的公共设置，节省了大量的重复的代码。以上是属性上的元数据，也可以增加实体层级上的元数据，元数据的存在给框架设计带来了便利。

如果正在设计一套ORM框架，考虑给实体和实体的属性增加元数据(自定义属性)，它会为系统的可扩展带来诸多方便。