hibernate和LinQ To SQL还是没有弱类型的DataTable好用

最近一个项目，使用java的ssh框架去实现。使用了hibernate这个自带的实体到数据库映射的框架，自己也用映射类封装了一个ResultSet到实体List的转换类（这样就可以不用hibernate自带的转换，可以直接调用自己的函数将sql语句转换成实体List，不用编写繁琐的hibernate xml文件）。

 

但是，大家应该知道实体List的方式是强类型的，每个表都要建立一个实体与其相对应，真是多累人的事情。

 

个人感觉hibernate还是没有.net的DataTable 这种弱类型的转换好用，每个数据的表都建一个实体实在太累人了，虽然代码生成工具可以代替生成，但是要处理关系复杂的表关联查询，或者表结构做了改动，每次都要修改几个文件，实在是太令人讨厌了，而且对于表结构是用户动态创建的一些动态网站来说，做这样的映射也不灵活。所以我个人觉得，这类框架还只是适合于做很简单的应用，复杂一点的应用改起来真是是事倍功半。

 

微软的.net也有一个类似的，名叫LinQ To SQL的数据框架是类似hibernate的实体到数据库的映射框架，但是我要说，这些数据库框架的开发效率其实被远远夸大了，没错，对于一些简单的应用，关联少、表结构修改少的应用，用代码生成工具一下就生成了。但是项目在设计阶段实在不可能将数据库所有字段都那么准确地去设计了出来，关联查询也可能很复杂。用了这些框架之后，以后的改动就知道非常痛苦了，数据库的一个改动，要修改好几个文件，甚至关联的实体也要改。

 

其实实体的实现是为了什么？其实目的就是为了service层（比如MVC框架的Action）到view层的传递用的。其实.net早已经有了一个这样的传递特性。比如.net的MVC框架里面，在action里面可以使用ViewData["mytable"]=datatable，在view的页面上可以通过Datatable datable=(Datable)ViewData["Message"]去获取，实现代码分离。.net的WebForm框架就更简单，可以直接通过变量名或者ViewState来获取。

 

当然，实体也有实体的好处，比如view的字段到action后，action可以自动通过setter给各字段赋值到实体对象，不用一个一个地赋值。其实这就是做实体的唯一好处了。其实这个问题完全可以自己通过.net或java都有的Reflection类来封装一个表单变量到action变量的自动赋值类，假如单单因为view到action的自动赋值而建实体的话，我觉得实在值得三思。除非你的系统表关联非常简单，表的改动也非常少。否则datatable的弱类型转换绝对应该是首选。其实java开发者也可以完全可以编写一个这样的弱类型的datatable类，不用每个项目每个表都建实体。通过一些封装好的SQLHelper类，直接将sql语句转化为弱类型的datatable，无论表关联是多么的复杂，生成的都是弱类型的datatable ，简单直接。

 

其实在框架的开发上，我还是觉得采用Action+SQLHelper类+view或者.net的WebFrom 的Service后台+SQLHelper类+aspx这样的开发模式，通过SQLHelper类将sql语句生成弱类型的datatable去传递。从代码维护、开发高效性都是最好的选择。