Frans Bouma認為代碼先行的ORM是“愚蠢的”

　　在使用ORM構建基于數據庫的項目時，開發者可以選擇是先設計數據庫表，還是先設計類或抽象模型。為了展開討論，我們先列出Frans Bouma的結論：代碼先行的ORM是愚蠢的。

　　先寫代碼，比如實體類，與先設計表一樣有問題，它們都需要反向工程來得到抽象實體定義，以創建“對方”的元素：對類進行反向工程得到抽象實體定義，然后創建表和映射，或對表進行反向工程得到類，然后創建映射，這兩者是等價的。核心問題是，如果先設計類或表，就等于先得到了抽象實體定義的某個投影的最終結果：類不是從天上掉下來的，在決定了領域包含這樣一個類型后，它就存在了。例如，一個“Customer”，包含給定的字段：Id、CompanyName、Address等。他還說道，

　　我知道“代碼先行”的整個思想來源于開發者希望編寫代碼，用代碼來思考，然后將對象持久化到數據庫中。但事實是，你持久化到數據庫的并不是對象，而是它們的內容，是實體的實例。而一個實體類的實例(即一個對象)則很有可能比實體的實例包含更多的數據，所以看似存儲“對象”，實則無法覆蓋對象。拿序列化一個對象來打比方，我們序列化的并不是對象，而是其數據的子集，得到的結果與源并不一定匹配。在將數據反序列化為JavaScript對象的時候，我們還能將它視為原始的.NET對象嗎?當然不能，它是對象內部的數據，可以存在于任何地方。

　　那么，當“對象”序列化成JSON時，數據被序列化，這沒有異議。但當同樣的對象序列化成表行時，對象作為一個整體被序列化，這不是更奇怪嗎?如果你仍然堅信ORM就是持久化對象，那么另一個不使用ORM但使用相同數據庫的應用程序，在將“對象”持久化為表行時會發生什么呢?這個應用程序(甚至可以用完全不同的語言編寫)可以完全正常地讀取和消費存儲于表行中的實體實例，不需要知道你將其視為一個持久化的.NET對象。因為讓人驚奇的是，表行中的內容并不是持久化的對象，而是持久化的實體實例，一個抽象實體定義的實例，不是類定義的實例。Reddit用戶remy_porter對這個問題有不同的看法，

　　我認為真正糟糕的是EF中的模型先行(Model First)。我痛恨它強制你使用的GUI工具。

　　我最喜歡的方式是用代碼先行來實現一種殊途同歸的方案。我以最有意義的方式編寫對象模型，再以最有意義的方式編寫數據庫模型，然后使用FluentAPI來讓兩者匹配。

　　不過我承認，我用這種方式只是漫無目的地拋出數據庫對象圖，因為我告訴過管理層這個應用應該使用NoSQL，但他們卻充耳不聞(該數據模型是存儲不同結構的文檔，但卻要求用SQL Server)。Nishruu傾向于將其用于測試，

　　沒錯，我通常使用Fluent API來映射已經設計好的數據庫。

　　代碼先行真正有用的場景，是用內存SQLite DB或某種LocalDB來快速進行集成或單元測試。然后可以為測試概括而快速地重新創建數據庫結構。

　　NHibernate就很好，能和內存SQLite DB很好地工作。EF就不盡如人意了，使用LocalDB時只能通過MDF文件重新創建數據庫架構(schema)。

原文轉自：http://www.kuqin.com/shuoit/20140109/337516.html