当持久化兴起的时候，逐渐形成了实体层这个概念了。hibernate,jdo,以及博客园的nbear都可谓是大名鼎鼎！有的公司不使用这种ORM框架,他们使用一些自动生成工具生成实体(例如用Codesmith生成)，并生成和该表对应的业务逻辑，于是乎感觉我们的程序好像一下子全都写好了，下一步就轻松了，我们只要扩展业务即可了!莫非这样真是那么方便了？在维护上真的是最便捷吗？
     其它的持久层解决方案不敢说，但至少我觉得像orm的鼻祖hibernate那种开发机制,在维护还是相当之麻烦呀！一个实体还得对应一个xml文件（虽说这些都可以自动生成）,但是你深入项目的时候去想想，我们的业务真能一切都可以定下来吗？人的思想总是在变的，客户的需求就更难以着磨了！哪天我们要给程序加个字段，你想想你必须要走几步改动？首先我们必须重新生成xml和实体，然后我们必须还得在业务逻辑中增加代码，还得在视图层加一个界面(如加一个input输入框等)！讲实话，加一个字段对这种orm框架的改动还是最少的，哪天假如说我们修改了哪个字段的名称、修改了字段类型，你想想，天呐！很难想像，和这个字段关联的程序都得改动!如果名称改了，ok，你可以全部替换它的原先名称，改成你新的名称。那类型改了呢？没办法只能手工一个个改掉所有的赋值的类型吧？视图层、控制层中的验证（js验证,业务验证）、逻辑层、实体层，xml配置等等都必须动。搞啥个hsq，这和sql不差不多了吗（虽然说hsq，抽象了数据库模型）？不过我想没有程序员不懂sql的吧？况且hsq对复杂的语句还是会力不从心的吧！
     运用ORM框架势必会运用大量的反射，代价是牺牲性能。当然现在的各种ORM框架都在尝试使用各种方法来减轻这块（LazyLoad，Cache），效果还是很显著的。可是我们牺牲了这么大的性能，而且我是觉得在维护上ORM还是最便捷。
      真不知道为啥像hibernate这样的框架还有一个xml配置文件？如果我真ORM的话，我不能把这些数据关系缓存起来，动态取关系不就行了吗？这样我不更灵活了吗？
     当然使用ORM也有它的活的活之处，在维护上那种自动生成的方式(petshop模式)比使用ORM框架维护量上更大一些，那种构架如果是每个数据操作对应一个存储过程的改动会更会让人晕头转向的。其构架大致如以下描述：
     主要由BLL,MODEL,DAL三层构架方式实现，BLL存放的是相关业务，MODEL是相关的数据库表格实体，DAL业务的SQL语句（或存储过程参数）.为了松散耦合，在BLL层和DAL层中间加入了工厂层(Factory)，其作用是方便DAL层的载体变动(如把Sqlserver改成Mysql),在DAL层有一个setObject数据库字段到实体属性设置,便于数据库表格映射成实体。
     程序编写的最大问题就是耦合高，怎么降耦也是开发的一个重中之重。以上述的程序构架来看，如果我改动了数据库中的其中一个表格的某个字段，程序改动的至少就有三层。如果再按照自动生成方式那种看，DAL中的update,insert,select, setObject都需要改动，如果存在存储过程的话，像get,getAll,update,insert都必须改动，想象一下这里改动地方有几处了？而且还需改动Model层，修改量之大可见一斑。当然我们这里可以用自动生成工具生成并替换，可又有谁知道这里面的替换工作量多少?
     总之，提倡"高内聚，低耦合"是构架永恒的话题，寻找便捷亦是构架的终级目标。
 待续（下步讲讲我的开发框架）