搞有中国特色的SOA（面向服务架构）——7

     好长时间没有更新了，原因是很多的，主要是现在工作忙碌的让人没有心情，在北京的生活总是没有自由，而且烦心。北京是中国最不适合居住的城市，空气干燥、物价奇高、交通瘫痪、节奏变态。今天一早清醒地过早，所以趁着睡不着，说两句梦话。

    这么多朋友支持，让我有些受宠若惊，先对一个问题解释下先。就是配置文件的问题，我本人是极其反对过度使用配置文件地。配置文件的用处是记录配置信息而不是应用信息，否则要数据库作什么?另外我是一个手写主义者，从配置文件到接口代码、从servlet到实体EJB都是手写，几乎从不用工具，我总喜欢那种把一切控制在自己手里的感觉，嘿嘿。

    现在接着说Hibernate，Hibernate对我的帮助很大，呵呵。当我一头扎在实体EJB的圈子出不来的时候是Hibernate拉了我一把，直到现在Hibernate对我自己在设计持久层架构的时候还有非常的参考价值，而且我还刻意的模仿Hibernate的语法来实现自己的持久层架构，以减少对程序员使用架构的培训。

    Hibernate其实是非常优秀的，但是由于其过于的通用，必然造成针对具体应用时候的相对效率低下。记得当时我在看Hibernate源代码的时候曾经统计过，Hibernate中大概用来保证数据库兼容性的代码要比其核心的逻辑实现代码多两倍。而且Hibernate中还有大量的我非常讨厌的配置文件，呵呵。Hibernate是对JDBC的简单封装，但是其实现的机制还是相对重量的。我试图实现一个非常轻量的持久化框架，却包括O/R映射的核心内容，我的想法是对JDBC的简单封装，扔掉不常用的功能，比如实体类之间的父子关系（主子表），文档、实体类、配置信息的可视化管理并可以相互生成、转化。事实上我已经实现了这个框架，非常好用，呵呵。

    我非常反对一种说法,认为持久层框架必须能够对应数据库的复杂操作，比如复杂关系的处理，并声称如果不能实现那么在做大项目的时候会有问题。我做的大型项目多了（小吹一个），但是从来没有在哪个项目中出现类似的问题，持久层框架是重要的，但是不是最重要的，数据库的合理设计才是最重要的，如果数据库设计的合理，只用JDBC一样很High。

    我提倡在数据库的设计和持久层框架的定义中大量的使用约定来保证系统的合理和稳定。比如，强行要求实体类名称和数据库名称必须相同，实体类的属性名和数据库字段名必须相同，而不是说通过配置文件来定义他们之间的关系。我讲述的都是在做具体项目的时候总结出的实际经验，如果您是搞科学研究的，就略过这段内容好了。

    最后总结一个，应用中，数据库的合理设计最重要，用什么持久层的框架，甚至说用不用持久层框架都不重要。