最近一直在忙新公司的基础库建设，对系统架构、开发框架及快速开发平台的设计实施都积累了一定的实践经验。
一般的中小型的软件开发公司，如果按照技术储备来衡量软件项目的技术含量的评定依据是可行的。但如果光是按照人头来衡量软件的技术含量是不可靠的。所以我们在选择跳巢的时候是选择大公司还是选择有技术含量的公司要根据自己的职业规划来。(本人最近体会到的一点跳巢经验分享给大家)
由于我现有单位技术部门刚刚成立不久，需要一些基础的开发框架，ORM当然是跑不了的。在后面的文章中我将陆续写下我在建设基础框架中的一些实践检验，里面可能包括对UI层的封装、基础控件的封装等等。我就废话少扯了，进入主题。
这篇文章的重点是无反射的ORM框架，为什么会有这样的想法？其实前不久群里的朋友就问了一些问题，他们在构建自己的ORM框架的时候频繁的在使用反射来编写功能。从跟他们的交流上来看他们似乎很喜欢使用反射来写功能，但是没有仔细的研究过ORM框架的作用是在系统架构的哪个位置，在对性能要求十分严格的情况下反射会有点无能为力。
反射的好处当然是毋庸置疑的，一些技术稍微好点的或者大牛们通常会用动态编译的技术来平滑的过度这个系统最重要的性能瓶颈点。我总觉的可以用高层的抽象和约定来解决这个ORM使用反射的问题。下面我们来分析一下通常ORM框架为什么需要用反射，反射的目的是什么。[王清培版权所有，转载请给出署名]
当然我们这里讨论的是最普通的问题也是必须的问题。
ORM框架的种类形态各异，不同的公司不同的ORM实现。其实目的是为了能有一套属于自己公司的开发框架，这不是技术所定而是公司高层领导所要求的。(我们没有说话的权利，为了保住饭碗，我们只能听从指挥)
但是大部分的ORM框架的设计思想和实现思路都离不开那几点的“思维实现约束”。我为什么要说“思维实现约束”，这也是我们程序员的一些通病之一吧，都喜欢用复杂的技术。不管三七二十一用了心里舒服。这是好事，为了练习技术可以理解。没有这份好奇心这份激情我们也很难走到专家的位置。
目的之一：为了表达实体与表的对应关系
ORM是实体与表的一种映射关系，逐渐被发展为一种复杂的技术实现模型。
在传统的分层架构中，在实体的定义上都会使用一个特性来标记该实体所表示的表名称是什么。如：
[Serializable()]
[HZ.Table(TableName = "member")]
public class Member{}
特性HZ.Table中的属性TableName来保存静态的表名，在ORM中通过获取对象的类型然后反射出该类型的特性元数据。然后读取相关成员属性值，作为拼接SQL语句的必备条件。
目的之二：为了表达属性与字段的对应关系及一些主、外键
ORM中将实体的属性映射成数据库中表的字段，一般通过两种方式来表达这中关系。
第一种：通过属性特性来表示该属性代表的字段名称；
[HZ.Column(PrimaryKey = true,ColumnName=”MemberId”)]
public string MemberCode { get; set; }
第二种：直接通过属性名称来表示字段的名称；
public string MemberId { get; set; }
目的之三：获取实体属性中的值
在进行插入或更新的时候需要获取实体中的属性的值，这个时候只能使用反射的方式获取到属性的值，然后拼接插入或更新语句。
目的之四：设置实体属性的值
通过实例化泛型对象，然后反射对象的属性通过SetValue方法设置属性的值。
简结：这几点是最常用的，可能还包括其他复杂的功能，这里我就不涉及了。上面这几点都是通过反射获取实体的信息，不管是增、删、改、查都需要反射。尤其是对于查询数据来说，如果是大数据量的查询性能问题很吓人。
通过抽象、多态设计不需要特性的ORM实体
大部分ORM框架是需要代码生成器做支持的，不是所有的代码都是需要程序员手动去敲的，可以通过一些模板引擎类的代码生成器，编辑好自己的模板然后生成大部分的实体代码。包括.NET里面的EntityFramework、LinqToSql也是用IDE集成的代码生成器。
所以这里就会涉及到对企业代码生成器的考虑，这里就先不扯了，后续文章我们再来针对性讨论。
那么我们先来讨论如何设计实体结构，让它能包含我们ORM所需要的必备信息。其实我们的思路稍微转变一下利用抽象来解决问题。提高抽象层次，将实体视为两个层面。顶层抽象类被ORM使用，子类被调用者使用。
图：
我们的要求就是ORM中不能存在一个反射的代码。所以我们约定了BasicEntityObject抽象类，通过定义顶层抽象基类来包含子类所要用到的一些属性信息。
我们看一下抽象类中包含了哪些东西。