为什么使用void FilllXX(TypeA pParm1, TypeB pParm2)
应用场景色：void FillXX的好处是可以不用关心实例情况；如果在方法体中需要一个实例，而方法体只知道基类，无法提供继承类的实例，那么就需要外界出入子类的实例，来进行填充，从而实现了对某些操作的“闭”；
比如早期在DataAccesor中的：
public static BaseBizEntity FillBizDataByID(int pID, BaseBizEntity pBizEntity) { …
context.TryGetObjectByKey(key, out o);
Util.DataEntityToBizObjTrans((EntityObject)o,
pBizEntity
);
…
} 因为这里牵涉到将获取的Entity向业务Entity进行赋值，这个时候方法体是不知道业务实体具体类型的，无法实例化，所以只能依赖参数传递，这个就是void FillXX（TypeA pParm1, TypeB pParm2)的应用场景；
UtilLib的应用
对于高层抽象一定要封装在一起，比如基类的使用；这样最大的好处就是以后新的工程项目，子类是不相同的，相同的倒是高层抽象；比如BaseService，BaseBizEntity等等，新的项目来了，只需要把UtilLibrary加入工程，就有的框架可以遵循了。
主表和自表联动插入的方式
对于一对一的关系，外键放在任何一个表中都可以，对于一对多的情况，外键毫无疑问的应该放在从表中；对于ROMapping模式的开发，关联的处理方式，则是主表一定要先插入DB，因为需要返回主键，作为从表的外键，这里可以在程序中做一下校验，如果没有主键做外键，那么就直接抛出异常：
public void Add(BizWorkflowSequeuece pNode) { if (this.Id == 0) { throw new Exception("工作流实例为空，不能添加节点"); } pNode.WfId = this.Id; this.nodes.Enqueue(pNode); pNode.StepNo = this.allNodes.Count + 1; pNode.Create(); }
日志的设计
日志一定是要讲求“一条龙”，通过日志是可以将操作的一条线体找到的；比如从创建一条任务，业务类，到保存到DB，再到创建一条工作流，保存到DB，添加到业务类；最后是添加节点，每添加一个节点就会存到DB中；一个任务的创建应该是一个主线，通过ID是可以追踪到整条线的。
枚举的滥用
首先，不要将枚举值和下拉框相关，而是最好配置DB化，并提供配置页面来进行配置；这样对于增加、减少项可以达到不修改代码即可，如果枚举和下拉直接相关：将会导致变更以来代码。
其次，枚举不要作为Entity的类型，DB的字段向Entity转化，以及做处理在页面端显示其实是一件特别扯淡的事情；
最后，要明白，枚举只是一种表达方式，一种只适用于应用层处理逻辑的直观性，便利性，但是不要将他穿插跨域方面（应用层、DB层）。
为什么消息都放在一个类中
提示消息统一放在一个类中，这就是集中效应；所有同类别的内容都放在一起，这样便于索引，便于发现类似的内容，进而加以简化，比如可以方便发现相同的消息；另外如果修改可以尽快定位到修改点。