我想知道開發多ORM解決方案的最佳方法是什麼。多ORM解決方案
到現在爲止所有的項目我看到了ORM的選擇有很大的關係，他們堅持下去，直到結束。 Nhibernate，Castle ActiveRecord，Linq to SQL，WilsomORM，LLBLGen，SubSonic，Entity Framweork，其他...
我想如果我應該或不要，將這個選擇與其餘項目的強烈關係分開。在某種情況下，我可以隨時更改ORM。
現在，我已經唯一的想法是一樣的東西「工廠」檢索我ORM對象，然後我會把它映射到一些「內部」對象。
有情況，當一個項目有一些限制，並在那個時候作出的決定開始，不放棄比選擇一個特定的ORM或在不同地區的一些其他的東西，任何其他選項。
但後來時間，幾個月，一年或如此，很多事情的變化，更多的資金，更多的支持，在前進的技術，新的框架/想法，等...爲我們提供了更好的選擇，而在這種情況下它能夠在沒有對應用程序進行重大更改的情況下更改ORM真的很酷（在這段時間可能會很大）。
我想知道你的意見。
謝謝你們。
更改您的ORM始終是一個耗時的過程，由ORM提供的抽象總會溢出到自己的代碼，即使你沒有意識到這一點：（！或缺乏某些功能）功能的ORM將在您的代碼中可見。選擇一個基於linq的ORM將使查詢更容易切換，因爲查詢可以更容易地轉移到另一個ORM（如果那個還支持linq）。但是這將會是很多工作，所以選擇功能豐富的ORM是明智的。
另一個問題是映射定義，模型本身：一個轉換到另一個是困難的，甚至是不可能的，如果沒有適當的工具。如果你看看像LLBLGen Pro v3這樣的設計師（http://www.llblgen.com），你可以使用相同的項目，相同的實體模型和映射與不同的ORMs和切換很容易（你仍然需要更新自己的代碼當然）。
（免責聲明：。我LLBLGEN Pro的主要開發人員
恕我直言，這將永遠是一個硬核解決方案映射ORM類有一些內部的人總是會導致「雙工作」和一些問題數據庫模式更改將需要在此映射類中再次進行更改，由於某些原因，這需要額外注意不要忘記。
還有其他要記住的事情：事務，延遲加載，由於某些原因某些ORM行爲不同從他人的，或者具有或不具有該功能。假設所有的都差不多是不正確的。在考慮採取這個，我想，這不是那麼容易做到。
更改您的ORM可能會導致更改您的數據訪問層。 而每個ORM都有自己的Schema for Generating Codes。 我同意Frans Bouma。 （（選擇一個基於LINQ的ORM將使其更容易轉換爲查詢可能會轉移到另一個ORM（如果一個還支持LINQ）更容易）） ，你可以開發自己的ORM，並能使其產生LINQ查詢有關它！能夠 ？！ 祝你好運
可能你不需要ORM，看看這裏：http://valueinjecter.codeplex.com/wikipage?title=Data%20access%20layer%20%28ORM%29%20with%20the%20Value% 20Injecter＆referringTitle =首頁 – Omu 2010-07-29 12:00:18