企業圖書館的利弊

Question

我正在開發一個復雜的業務應用程序，其中將有一個數據訪問層。 截至目前，我們有兩個選擇 - 要么創建我們自己的自定義數據訪問層，要么使用Microsoft內置庫。 我正在尋找一些基本的理由來選擇其中一種。

任何回復將受到高度贊賞。

Answer 1

另一個需要考慮的選擇是實體框架4，因為它為您提供完整的ORM。 使用最新的CTP 5代碼，首先使用Entity Framework看起來非常有前景。

據說，只要您的SQL表列與ExecuteSprocAccessor和ExecuteSqlStringAccesor的對象屬性匹配，Enterprise Library 5就會使數據訪問變得微不足道。 如果你使用這兩種擴展方法，你可以擺脫處理IDataRecord ， IDataReader和通常的命令對象，你的數據訪問最終看起來像這樣：

var books = DataBase.ExecuteSqlStringAccessor("SELECT [Id], [Name], [ISBN] FROM Books", rowMapper).ToList();

一些優點

1. Enterprise Library確實提供了一個強大的框架，其中包括Unity（IoC），日志記錄，驗證，異常處理和策略注入等等。
2. 各種應用程序塊的大量文檔和快速入門。
3. 可擴展和可配置，幾乎可以做任何事情。
4. 在Ent Lib5中，引入了一個流暢的配置構建器來減輕來自山區配置部分的一些壓力。

一些缺點

1. 非常大的框架，您可能會發現自己需要引用2個以上的程序集才能使一個東西正常運行。

2. 潛在的配置噩夢，但是使用流暢的配置構建器和更新的應用程序塊配置編輯器確實減少了一些痛苦。

最后我使用Enterprise Library，因為它可以幫助我更快地構建應用程序，而且我不必重新發明輪子。 最好的辦法是嘗試每一個，ADO.NET，EF4，Ent Lib5或許多其他選項，只需看看哪一個適合您的需求 。

Answer 2

我當然不會推薦企業庫。 顧名思義，大多數子項目非常“企業化”，這意味着它們大多過度設計並需要大量的XML配置。 除非您覺得有吸引力，否則可以提供更好的產品。

我已經有過滾動自己的ORM以及使用大量不同框架的一些經驗，現在我已經基本上決定使用EF4（實體框架），因為它是內置的，因此即使在對開源持謹慎的商店也很容易獲得甚至商業第三方組件。

如果您正在使用現有數據庫，則EF提供了一種從該數據庫生成起始實體模型的方法，您可以隨后在可視化設計器中對其進行修改和同​​步。 如果您沒有數據庫，或者您不喜歡設計人員並且不喜歡使用代碼，那么Microsoft已經提供了一個CTP下載，它能夠以“代碼優先”的方式使用EF，其中數據庫映射以代碼表示。 隨后可以使用定義的類生成數據庫。

如果您願意使用開源，NHibernate是一個優秀且成熟的選擇，具有良好的第三方支持（可視化地圖設計師，剖析器等）。

我幾乎忘了提到在任何情況下你都不應該推出自己的數據庫訪問框架。 考慮到此特定功能可用的豐富選項，請花時間編寫應用程序的內容而不是HOW。

Answer 3

如果你在ORM（對象關系映射器）之后看看Habanero。 這是一個開源項目，允許您從數據庫構建完整域或反向工程域。 它有一點學習曲線，但有很好的支持和一些額外的工具來支持它。 FireStarter Modeller就是這樣一個工具，它為您提供了一個Windows界面，用於構建域對象或從數據庫反向設計它們。

您可以從SourceForge下載最新版本。 欲了解更多信息，您可以在HabaneroLabs注冊和/或查看哈瓦那人 維基 。