从部队转业到地方，转眼已经快３年了。回首３年里，比较欣慰的是我的框架已经逐渐成熟了，把在部队里的想法已经慢慢的实现了。
由于部队是个相对封闭的环境，主要是靠自己对技术方向的把握。转业之后没有选择在上海当公务员，靠着自己对于计算机的热爱，选择了走计算机技术的道路，去实现自己的梦想。

可能是我接触的环境的原因，我呆的公司都是比较小的公司，小公司在技术方面的实力通常都是相对比较弱的，再加上国内的急功近利的一贯作风，多数小公司在技术上没有多少的沉淀，也可能是我的目光太短浅。中间的言论也可能有不妥之处，请大家能够见谅。

从我开始整理这个框架，就走上了创新的道路，可能大家在别的地方也可能看见过相似的解决方案，那纯属巧合。

废话少说，从今天开始慢慢的介绍自己的框架。

框架从层次结构上分主要分为：ORM层、Meta层、BO层、SO层、数据交换层、DTO层、服务层、代理层、外观层，这几大层。
ORM层：主要提供，存储过程、配置文件的翻译，实现数据库与实体数据的映射。由框架提供。
Meta层：主要提供，数据库与对象的映射，由工具生成，在98%的应用场合不用更改
BO层：业务逻辑层，核心的业务逻辑，基本关联已经由工具生成，可以在此层处理特定业务逻辑，如果涉及分布式数据访问，需要在此进行稍加改动。对于关联结构、主从结构要在此加上关联处理，重写OnBeforeAdded/onAfterAdded/等。加入特定业务。建议通用查询/配置过程的处理，在这里重写一下，不要以ActionId对外开放。（在Demo里面没有给出通用查询/配置过程的处理，类似于Ibatis的配置文件）
SO层：业务外观层，主要是与客户端打交道，提供客户端所需要的数据。SO层与DTO和数据交换相互配合，传输客户端需要的数据。提供声明性事务、声明性服务。工具根据BO业务层生成SO层代码。
数据交换层：实现DTO层与BO层的数据交换，实现客户端的数据与业务数据的连接。工具生成基本代码。
服务层：根据BO生成的配置文件，提供基于Http信道的服务。（可以提供TCPIP等其他信道）主要服务主框架提供，需要在此配置基本连接字符串，设置配置文件的路径等。
代理层：由工具生成，配置文件根据服务生成。
外观层：当前只提供CS的界面生成，BS界面下一步加入。主要提供了列表的配置、列表界面、明细界面的生成，对于主从、关联结构的自动触发机制。客户端生成代码的质量非常高，基本应用的改动很小。

下面把每一部分的代码一一介绍