Juvy

        这篇文章的出现源于跟同事的一次争吵，其中争吵的主题是关于软件中一些控件的显示风格的问题，主要包含下面这些情况：

        1、Lable控件的对齐方式，是否在Label控件的Text最后加上冒号，也就是“：”；

        2、ListLiew控件列头文字对齐方式、是否显示网格线；

        3、……

        一个项目多个人开发，自然会出现多种不同的风格，但是萝卜白菜，各有所爱，最后做出来的软件是样式万千啊，这样做出来的东西让人用了如何爽的起来啊，用户还不得开口骂人啊？

        但是一个软件下来，控件都有几百个，如何一个一个的去改风格啊，到时候软件是改好了，用户不骂人了，估计程序员开骂了，nnd，这是个什么事儿啊？

        有时候感觉懒人在这个世界上还真有他的一片天空，如果能够一个方法来解决所有的这些问题该有多好啊，想着想着，眼前一亮，还真有，如果在每个UserControl，或者Form的PreRender方法中进行一次多所有控件的递归遍历，然后对相关的控件做相应的处理，大概代码如下：

        这样似乎从一定程度上简化了程序员修改代码的难度，从一个个的去修改控件的属性，变为通过代码循环处理来修改控件的属性，但是随之而来又会面临一个问题：本身递归就是一个很影响性能的操作，但是如果有控件嵌套使用的话，会出现对同一个控件进行多次控件遍历的情况，这样的话对性能的影响就更大了。

        有没有办法可以躲开重复遍历的问题吗？答案是：有的！

        如果我们写一个UserControl和一个Form的基类，然后只在这两个基类中编写控件遍历处理的操作，然后让所有的UserControl和Form都继承这两个基类，这样完全可以解决前面的难题，同事代码量也会减少很多。

总结：到这里，我想文章的意思应该与题目“项目开发之底层对象抽离”相呼应了，那就是：为了便于对自己写的所有代码做一个统一处理，最好的方法就是尽量将同一类对象抽象出来写一个基类，然后在基类中来做统一处理即可。想想我们平时都会有哪些对象是可以抽离出来的呢，我这里举几个例子，或许还有很多，留待慢慢发现：
        1、所有UserControl基类
        2、所有Form基类
        3、实体类基类；
        4、实体类字段基类；
        5、所有功能组件；

       说到日志，大家都清楚，无非就是记录：谁，在什么时候，做了什么/发生了什么错误，是不是觉得很简单。这次我也来做一回轮子，一步步教你如何写自己的日志帮助类。

       在开始之前我们需要分析一下日志帮助类（这里主要指文本日志）有哪些地方需要注意的：

1）、日志帮助类是用静态类，还是用？

2）、日志发生者通过什么方式传入，参数，还是？

3）、日志通过什么方式写，同步还是异步？

4）、日志文件保存位置和文件大小控制。

5）、扩展问题。

 

暂时个人只找到这么多，望大家补充。

        下面我就来说自己在这些方面是如何处理的

一、日志帮助类是用静态类，还是用？

       我的选择是非静态类，即通过实例化的方式获取日志帮助类对象，然后调用方法写日志，具体代码为：

TextLogHelper LogHelper = new TextLogHelper();

LogHelper.WriteLog(......);

       为何要这样做呢？其实说起来，自己当初写的好多东西都是静态，如静态类，静态对象、静态方法等等，因为那玩意儿好使啊，写起来方便，调用更加方便，为何不用。但是在不断的码农生活中，自己慢慢觉得有时候静态的东西也并不好使，例如：

       1）、静态公共字段/属性：并发问题，因为调用方都可能会修改值。这里只是说可能存在这种情况；

       2）、公共方法：参数个数问题。因为是静态方法，所以方法内部所需要的信息，只能通过参数的形势传入；

       3）、静态字段、属性维护问题，因为静态的字段太多，太杂，维护起来自然增加了难度。

       4）、面向对象程序开发的一个核心就是多态，所以如果用静态类的话，就不可能实现多态了。

       至于其他的这里就不一一列举了。还有一点需要指出的是，上述几点只是想说静态类存在这些问题，但并非表示任何情况都不适合用静态类，如工具类，数据转换类等，就可以采用静态类方法实现。所以采用静态类与否，还得根据实际情况而定。

二、日志发生者通过什么方式传入，参数，还是？

三、日志通过什么方式写，同步还是异步？ 

四、日志文件保存位置和文件大小控制。

五、扩展问题。

        二、三、四、五几点我就放在一块来讲述了。

        其实日志发生者存在两种情况：一种是固定的日志发生在，如系统日志，或者框架内部日志；另外一种就是用户日志，如Web应用程序中，不同的用户登录就会面临不同的日志发生发生着。

        先来给出SAS框架中的文本日志类的两个构造函数：

private TextLogHelper(string logSavePath, bool asynMechanismLog, int logFileSize){...}

public TextLogHelper(Func<ILogUser> getLogUserHandler, string logSavePath, bool asynMechanismLog, int logFileSize){...}

public TextLogHelper(ILogUser logUser, string logSavePath, string asynMechanismLog, string logFileSize){...}

       通过上面几个构造函数，你或许已经看出了上面端倪了：

       1）、日志文件保存路径、同步/异步方式保存日志内容、日志文件大小问题的控制，都是通过构造函数参数传入的.

       2）、日志用户采用ILogUser的方式，也是为了便于扩展。在扩展方面其实还有一个ILogHelper接口，而本文要将的TextLogHelper就是继承自ILogHelper接口。

       3）、日志发生着通过两种方式传入，第一种是委托方式，让调用方来决定日志发生者是谁；第二种是直接传递日志用户对象进去。

      下面给出ILogHelper接口的代码。

       日志接口包含五个写日志的方法，一个获取日志用户的属性。实现起来应该很简单，所以至于如何实现，在这里就不多讲了，留待自我发挥。

       现在说说本日志帮助类的两点不足：

       1）、日志级别问题

       2）、日志类型问题

       好了，本片SAS框架之文本日志类就讲到这里了，欢迎大家斧正！

ASP.NET开发技术交流群： 67511751

另：本人想找一些志同道合的人，可以是跟我一起交流技术的，或者是给予鼓励和支持的，非诚勿扰，谢谢！

QQ：1054930154

       自从上一次写关于ORM的文章已经是几个月前的事情了，在这里先贴一下文章的地址，如果大家感兴趣的话可以去看看。

1)、支持差异数据保存的数据库实体类设计——处女作

2)、支持差异数据保存的数据库实体类设计(二)(续)

3)、支持差异数据保存的数据库实体类设计(三)(续)

4)、SAS框架问世（本文）

       一直在埋头完善框架，博文自然就写得少了，今天来展示一下自己的框架的用法，先说说本框架的有哪些优点：

1)、支持多数据库的ORM。不仅仅只是一套支持多种数据库的ORM，而是可以在同一个应用程序中连接到多个不同的数据库（数据库类别，或者数据库连接字符串的不同）

2)、实体类工具生成

3)、IOC依赖注入

4)、AOP面向方面编程

5)、日志功能

6)、数据库对象审计跟踪功能（包括数据库的历史修改版本查看，数据恢复等功能）

7、权限管理（包括功能模块权限、角色权限、数据组权限等）

8、其他...

       本文主要讲讲ORM的常见用法，首先需要实例化一个数据层代理对象，该对象是一个全局对象，代码如下：      

DalAgent dalAgent= new DalAgent();//实例化一个数据层代理类

IDbHelperFactory dbFalctory = new MSSqlDbHelperFactory("Server=.\SQLEXPRESS;DataBase=SAS;uid=sa;pwd=123456");//实例化数据库帮助类工厂类

dalAgent.GetDbHelperHandler = dbFactory.CreateDbHelper() ;//为数据层代理类设置获取数据库帮助类委托 

注：其中IDbHelperFactory对象的实例可以通过框架中的IOC容器获取。

       1、查询操作

             List<Entity> list = dalAgent.GetListAll<Entity>(tableName);//根据表名获取全部对象的列表数据；

             List<Entity> list = dalAgent.GetListObject<Entity>(tableName, "Id > 10 and ...");//根据表名、过滤条件，获取对象列表数据； 

             List<Entity> list = dalAgent.GetListObject<T>(tableName, pageInfo, orderBy);//根据表名、分页对象、排序对象获取对象列表数据（分页功能）

             List<Entity> list = dalAgent.GetListObject<T>(tableName, "Id > 10 and ...", pageInfo, orderBy);//根据表名、过滤条件、分页对象、排序对象获取对象列表数据（分页功能）

             List<Entity> list = dalAgent.GetListObject<Entity>(queryStr, listPara);//根据查询语句、参数列表获取全部对象列表数据；

             List<Entity> list = dalAgent.GetListObject<T>(queryStr, listPara, pageInfo, orderBy);//根据查询语句、参数列表、分页对象、排序对象获取对象列表数据（分页功能）

       2、查询单个对象 

             Entity e = dalAgent.GetObjectById<Entity>(tableName, id);//根据表名、Id获取对象； 

             Entity e = dalAgent.GetObject<Entity>(queryStr, listPara);//根据查询语句、参数列表获取全部对象；

       3、插入操作

            Entity e = new Entity();//实例化一个对象，假设该对象有三个属性Id, Name, Description

            e.Name = "Name";

            e.Description = "Description";

            dalAgent.Save(e);//框架自动生成Sql语句,支持自增Id和非自增Id 

       4、更新操作

            Entity e = dalAgent.GetObjectById<Entity>(tableName, 1);

            e.Name = "Name1";

            dalAgent.Save(e);//框架自动生成Sql语句,并且sql语句中只包含更新过的字段  

       5、删除操作

            Entity e = dalAgent.GetObjectById<Entity>(tableName, 1);

            dalAgent.Delete(e);

上面的功能只是本框架这种ORM模块的调用，其他功能在这里就不一一介绍了，留待后续文章补全。

 ASP.NET开发技术交流群： 67511751

       自从上一次写关于ORM的文章已经是几个月前的事情了，在这里先贴一下文章的地址，如果大家感兴趣的话可以去看看。

1、支持差异数据保存的数据库实体类设计——处女作

2、支持差异数据保存的数据库实体类设计(二)(续)

3、支持差异数据保存的数据库实体类设计(三)(续)

4、SAS框架问世（本片博客即将登场）

由于一直忙于框架的优化，所以就很少写文章了，本文也是在不断的优化自己的ORM过程中诞生的，好了废话不多说了，下面步入正题。

       一直在使用公司内部使用的一个框架，框架的的数据层可以说是两个类，一个Entity类，一个EntityFactory类，这两个类分别是干吗就不多讲了。在不断编码的过程中总是发现在重复的写EntityFactory.Save(e)、EntityFactory.Delete(e)这样的代码，心里就在想可否做一下处理，直接调用Entity.Save()，或者Entity.Delete()这样写起来方便，看起来也很顺眼。

       直到最近在优化自己的框架代码的时候，才发现Entity.Save()是不太合适的，特别是当你的应用程序需要连接到多个不同的数据库的时候，而且你也不知道当前这个Entity对应于哪个数据库，或者说同一个Entity对应于多个数据库的时候，使用Entity.Save()操作估计就很难办了。

       假设：MSSqlDAL是Sql Server数据库的数据层，在保存实体对象的时候，你可以通过下面方法完成(Entity e)

1. MSSqlDAL.Save(e);
2. 或者你在Entity中增加一个方法public void Save(){ MSSqlDAL.Save(this);}，然后调用e.Save()。

       两种方法视乎都可以达到效果，但是现在如果我们的系统需要在另外一个数据库存一个副本，即同一个对象会存到两个不同的数据库（可能是SqlServer，也可能是Oracle），这个时候，我们需要增加一个Oracle数据库的数据层OracleDAL.所以如果这个时候来调用e.Save()方法就出现问题了。

最后总结一下，最终定下来采用Dal.Save(e)保存对象是正确的，因为强制性给实体对象增加一个Save()方法，似乎有点说不通，因为对象本身并没有保存这个动作。而是由数据层来负责保存数据库实体对象，这也符合OO原则。

ASP.NET开发技术交流群： 67511751

本文出现的源头还得从DbHelper说起，先来说说这个DbHelper的演化（产生）过程：

（一）、说起DbHelper大家都非常的熟悉了，就是一个数据库操作帮助类，如果说简单的话，几个静态的方法：

1)、public static DataSet ExecNomQuery(parameters....);

2)、public static DataTable ExecNomQuery(parameters....);

3)、public static bool ExecCommand(parameters....);

4)、public static object ExecScalar(parameters....);

5)...

（二）、如果没有特殊要求的话上面4个方法基本上就够用了,但是如果涉及到事务处理等操作，上面这个数据库帮助类就会显得有点力不从心了。也是正是由于如此，自己把原来的静态数据库帮助类进行了修改，全部采用实例成员，采用new的方式来创建DbHelper，用完后采用using方式将对象Dispose掉。程序运行效果也还可以，如果不是非常高负荷的应用，这样的DbHelper基本上都可以应付。

（三）、为了不至于到处出现new DbHelper()的操作，于是就产生了创建DbHelper对象的简单工厂类。

（四）、在不断应用的过程中，需要对数据库帮助类进行扩展，于是原本只支持MSSqlServer数据库的DbHelper又开始不够用了，为了不改变太多原来DbHelper的代码，于是直接从DbHelper中抽象出一个IDbHelper接口出来，将原来的DbHelper改名为MSSqlDbHelper，同时创建了一个支持Oracle数据库的OracleDbHelper，这样就可以根据通过工厂类创建自己需要的数据库帮助类了（MSSqlServer、OracleDbHelper，如果需要的话，可以自己扩展，只需要继承IDbHelper接口即可)。

（五）、为了消除数据库帮助类中的if；else if；分支的个数，于是产生了抽象工厂类IDbHelperFactory，先通过反射创建IDbHelperFactory，然后通过工厂类创建IDbHelper。（注：抽象工厂类彻底的消除简单工厂类的if-else if分支）

（六）、后来有一段时间一头钻入Ioc的漩涡中，于是产生了一个想法，想自己写一个Ioc容器，。。。哗啦哗啦。。。经过几天的折腾，一个自己打造的精简版的Ioc容器诞生了，通过构造函数/或者setter方式注入创建IDbHelperFactory，然后创建IDbHelper对象。

（七）、上面的IDbHelper用了一段时间，感觉还不错，但是不知不觉的使用过程中，DbHelper中增加了一个又一个的字段、属性、方法（都是实例成员），导致DbHelper对象不断膨胀，从而使得DbHelper实例化的时候，对内存的开销相比最原始的静态数据库帮助类大了许多，想到自己的Ioc容器创建对象的生命周期中有一种是Pooled类型的，即组件池模式。对于这个组件池模式，在这里好好解释一下（对Ioc有一定研究的人可以飘过），组件池模式，即容器在讲对象创建完以后，同时保存一份对象的引用在自己的Pool中，这样调用方在对象调用完毕之后，GC不会将对象回收掉，因为Pool中还有一个该对象的引用。这样在下一个创建该类对象的调用中，Ioc容器就可以先在Pool中寻找是否有可用的对象，如果有的话，就直接返回Pool中的对象，否则重新创建对象。好，问题产生了：

1）、Ioc容器如何判断哪些对象已经不在使用中;

2）、调用方在什么时候释放掉从容器中获取到的对象实例。

基于以上两点，我们可以参考微软自带的数据库连接池功能，即使用的时候，将对象标记为使用中（Status=Open），使用完毕后，将数据库连接对象Close掉，以便其他地方调用。于是一个简单的接口产生了，命名为“可重用对象”:

该接口只有一个bool类型的状态属性：IsOnUsing，用于标记该对象是否处于使用中状态。

下面给出从对象池中获取对象的代码构架：

写完上述方法后心中窃喜了一阵子，于是迫不及待的创建了30(只要大于组件池的容量即可）个线程来测，结果还没等我反应过来，就发现代码出现了死循环程序提示内存溢出了。。。。

着实让我悲剧了一阵子。。。。。。。。。。。。实在不知道为什么会出现这样的问题，难道是：

【先声明：我测试的对象就是上面的IDbHelper，DbHelper继承了IDispose和IReusedObject两个接口，并且在Dispose方法中加了“IsOnUsing = false;"，所以通过using（IDbhelper dbHelper = ....){.....}的方式调用DbHelper对象使用完毕后，对象都会被对象池重用。】

1）、组件池中的所有的对象都一直被占用在。。。。。

2）、还是什么其他原因。。。。

答案已经给出：就在代码中红色标识处。

经过大家的激烈讨论，发现有一个地方可以优化的：那就是如果调用方忘记经从Ioc容器中获取的对象Dispose()掉的话，那么这个对象就是个死角，永远也不会被释放掉，直到程序退出为止。所以下一步会针对这个Ioc容器进行优化，为组件池中的组件增加对象超时时间（即对象空闲一段时间就将该对象从组件池中释放掉）。

下面贴出优化后的代码，欢迎大家指正，谢谢！

ASP.NET开发技术交流群： 67511751(人员招募中...)

本来本文只是本人在百度知道上面的一个提问，但是由于百度知道太恶心了，半天没人给出合适答案，然后自己想回答问题，却发现字数居然限制那么死，所以把那个问题搬家到这里了。

问题的意思包括两次创建对象：
1、反射创建对象；
2、利用反射创建的对象来创建对象；
其中第二层次的创建对象可以又会有两种：
a)、new的方式构造对象
b)、反射创建对象
请问在第二层次的new方式创建对象和直接用new方式（即跳过第一层反射操作）创建对象在性能上面又多大的差异？

一直没能够等到我需要的答案，只有自己写代码测试了，测试方法还是采用傻瓜式1w，10w，100w，1000w，1ww执行，然后比较执行时间的方式。

最后发现：

1、new一个对象是最快的；

2、通过反射方式创建一个ObjectFactory，然后通过ObjectFactory来new一个Object的速度跟直接new的速度差不多；

3、直接用反射的效率是最低的

至于为什么呢，我在这里也给一个简单的个人见解：

1、其实new的第一次速度也有些慢，但是经过第一次new操作后（dll的与该对象相关的信息都被加载到内存中了）所有new操作是最快的，因为每次都是从缓存中读取；

 2、反射创建对象，是每次都需要去读取dll文件的，然后解析dll文件创建对象，这里解析就是反射的意思

3、先反射一个ObjectFactory对象，然后通过ObjectFactory方法创建对象，这个的效果跟第一种差不多，因为在反射创建ObjectFactory的时候，把要创建的对象的相关信息加载到内存中，然后从内存中读取dll信息，然后创建对象。

上一张本人的测试结果图片：

ASP.NET开发技术交流群： 67511751(人员招募中...)