需要大型.net數據訪問層的建議

Question

啟動一個新項目，它是針對一個非常大的（300個表）遺留數據庫的100％新開發。 數據庫與業務模型的匹配程度不高，所以我最初想到了使用ORM的位置。

我得到了與NHibernate合作的概念證明......但是有很多管理人員推遲使用“不支持的”“開源”工具。

有關其他ORM解決方案的建議嗎？ 或NHibernate論點的建議？

非常感謝。

Answer 1

如果您的管理層願意為商業ORM付款，那么您應該明智地考慮這條路線。

您對NHibernate（目前）的一個限制（除非您願意使用NHibernateContrib項目中的Alpha代碼）是您目前沒有使用LINQ / IQueryable機制來使用日益熟悉的LINQ語法進行查詢的奢侈。 你仍然會擁有非常靈活的Criteria和HQl機制，這取決於你是否想要開始投資做所有“LINQ方式”？

從我的研究到目前為止，你有很多選擇（都支持LINQ查詢）：

原始實體框架（有商業合作伙伴也在其上添加工具和功能。）

Lightspeed似乎是一種LINQ到[很多數據庫]，具有良好的設計時間支持。

Telerik OpenAccess看起來類似於Lightspeed。

IdeaBlade DevForce構建於EntityFrmework之上，但增加了一些可用性功能。 如果您不使用SQL Server，則使用IdeaBlade還需要從DevArt或DataDirect等單獨的供應商處購買ORACLE-EF提供程序。

LLBLGen Pro良好的功能和積極的發展。 已經很久了。

DevArt還為LINQ提供了良好的數據訪問工具和特定於供應商的提供程序。

[更新]現在可以在NHibernate中使用生產就緒的LINQ支持 ！

Answer 2

你為什么不問管理這個？

在Hibernate / NHibernate出現的時候，微軟創建並殺死了多少數據訪問解決方案？

• ADO
• ADO.NET
• 強類型的DataSet
• LINQ2SQL
• 實體框架
• 實體框架V2

在此期間，Hibernate / NHibernate已經越來越成熟。 它不會消失。

Answer 3

我在我的最后兩個項目中使用了Entity Framework，這些項目具有相似數量的表。 它對我們來說效果很好。 我們將表拆分為幾個Entity Framework模型，最大值為ca. 一個模型中有80個表。

實體框架更容易出售給管理層，因為它是微軟。