最近一個項目，使用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去傳遞。從代碼維護、開發高效性都是最好的選擇。