hibernate的一些缺陷（转）

例如用户在系统中，保存的信息包括简要信息(用户名、联系电话、Email、性别）和一些图像信息（照片）。

 

     但是在系统设计时，我的设计方式都是遵循业务的需要，设计一个“用户”类，包含用户名、联系电话、Email、性别和照片信息。这个时候我是不会考虑数据库设计的，这是一个设计原则：“ 不因为实现妨碍设计 ”。

 

     在后面的数据库设计中因为照片比较大，所以保存的时候，会设计成两个表：用户简要信息表和用户照片表，两个表通过“用户ID”字段关联。

 

     如果使用JDBC实现比较简单，直接使用SQL，使用联合查询查到用户所有信息，返回成为对象，比较简单。但是因为项目早期的设计开发人员选择了Hibernate，只有沿着这个方向做了，我发现比较困难，因为Hibernate的机制就是一个表对应一个“实体对象”。

 

     没有办法，我只能建立两个实体对象，业务对象User中，改成这样：

 

class User{
          UserSimpleInfo sinfo;
          UserPhotoIfo   pinfo;
     }

 

     感觉真够滑稽的。也许还有好的解决方案，只是我没有找到而已，我也会继续去寻找。就现在看来，没有找到这方面好的资料。

 

     我现在觉得这是不可思议的一个做法。对象的设计，应该是从业务的分析和业务逻辑中来，和设计没有那么紧密的关系。应该是由设计觉得实现，不应该由实现决定设计。一种实现或是一种框架，不管功能是否强大，都不能“绑架”设计，要设计“屈从”，这是框架设计的一个基本原则。

 

     实际上，一个表对应一个实体对象是很多情况下一个很自然的选择，但并不是必须的做法，如果限制了一定要这么设计实现，那就是非常荒谬的。我经常面向的领域和客户，经常面对的场景里，一个对象拆成几个表是非常有可能的事情。所以，ORM应该支持这种场景。

 

     从另外一个方面看，一个表对应一个实体类是一个有欠考虑的理念。当然，ORM如果支持一个类映射多个表，复杂度增大了很多，用起来也更困难了。没办法，想做通用的东西，肯定比转做一个领域和业务要困难啊。

 

     我本来就不喜欢ORM这东西，这让我更加讨厌Hibernate这类ORM框架，为此特意找了一些网上的资料，觉得这东西还是很不错的，尤其是一些需求简单的场景里，但是支持它的一些说法和理由却站不住脚：

 

     有人说： Hibernate出现的目的，是为了可以让我们这些写代码的，可以更集中精力处理业务代码，而不是把心思放在怎么构建SQL语句。

 

      我的意见： SQL本身也就是体现业务逻辑的。一个产品，本身包含的不仅有功能需求，还有效率、存储方面等等需求。

 

     有人说： 在还没有O/R MAPPING之前，我们在团队开发的时候，实现一个业务逻辑前的事情，就是跑去问DBA或者找系统的数据库 字典，要先把这个逻辑所用到的字段类型、大小、约束都搞清楚，才能开始做编码工作，因为我们需要构建特定的SQL语句、在代码放入各种的逻辑判断…… 
     在有了O/R MAPPING之后，这种现象才得到基本解脱，因为我们要操作表里的数据，只需要直接对映射类操作即可，O/R MAPPING会自动生成所需要的SQL语句……

 

     我的意见： 类型、大小、约束和需要在代码里放入的逻辑判断本身也是业务逻辑的一个部分。不管你用何种理念和工具，都要考虑和面对的。

 

     有人说： 不使用ORM，那么多的get/set多烦人啊，写那些SQL多烦人啊。而且不容易维护。

 

     我的意见： 即便不使用现有的ORM，也肯定会采用面向对象的方式，把数据库的对象和业务对象封装起来给上层使用。业务层面看到的，也是非常清晰的存、取功能调用而已。不会到处都是JDBC的调用和ResultSet的set和get，更不会SQL满天飞。这在一定程度上其实和Hibernate、MyBatis差不多，但是因为不用考虑通用性，所以设计实现起来比较容易，且都是根据自己产品需要来设计，量体裁衣，最最适合自己的产品使用。

     另外说到写SQL，我认为，写好SQL是设计和实现人员的基本功，不能在这里偷懒。我觉得有个人说的（忘了是谁了）：“SQL是丑陋的，难以理解的。”这句话是站不住脚的。如果SQL是邪恶的，那么JNI是什么样的呢？SQL是一门非常精炼和优雅的语言，更是一门艺术。SQL中蕴藏了非常简练干净、清晰的概念，非常稳定的架构。

 

     我不会只是从效率方面考虑问题，我更多的考虑是：

      对象应该从业务的分析中来，对象和数据库表毫无关系，对象应该能够从数据存储层取出来，应该能通过存储层保存起来------至于什么表格式等等，都不影响这些上层设计。从数据库表产生实体对象很糟糕；从实体对象产生表结构也一样不好。如上一条所说，对象从业务中来；表的设计，是要根据对象的设计和数据库自身的特点、产品或项目的需求(例如效率需求和不同数据库自身的不同特性)而来的。

      一个项目和产品，很多时候就是应该设计师、实现者和DBA共同努力来做好的，或者另外一种情况，一个团队里，本身就应该有一个或几个精通数据库或SQL的人，来一起做，不能因为说“SQL我不熟悉”或者“写好SQL太困难”为理由，对效率和存储方面的需求视而不见。或者简单的说“OO和关系数据库直接由天然阻抗”。做好数据持久层，一定是需要熟悉或精通数据库和SQL的人。

 

     或者，你做一个对效率、存储、持续性都没有什么要求的项目或产品，那另当别论。又或者经过一段时间的学习和体验，我会改变自己现在的看法。