使用企業庫的優點和缺點

Question

我剛剛開始一個項目，由於這個項目是個人的，我想知道什麼是使用企業庫的優勢？我們對辦公室中的幾個項目使用第2版，但我不太確定（不包括良好實踐）的優點，特別是在數據庫組件中。有什麼建議？謝謝

Answer 1

對於數據庫應用程序塊，主要優點是它可以更輕鬆地生成與數據庫無關的代碼。開發人員主要與通用數據庫和DbCommand對象交互，而不是像SqlConnection，SqlCommand等。因此，切換到不同的數據庫（如Oracle）變得更加可行。根據您的業務需求，這可能是一個明顯的優勢。 EntLib還在使用DbParameter查詢參數的方向上輕輕地鼓勵開發人員，這樣可以降低SQL注入攻擊的風險。

另一個海報提到，數據應用程序塊比直接的ADO.NET類稍高一些，所以它往往需要更少的代碼行來完成同樣的事情。

從我的角度來看，數據，異常和日誌記錄塊是最有用的。異常和記錄在一起使得將例外（duh）記錄到多個位置並以多種格式很容易。例如，他們可以將整個異常日誌條目（包括堆棧跟蹤）放入Windows事件日誌中，這使得診斷問題變得相對容易。

EntLib的一個缺點是某些應用程序塊會在配置文件中放置相當多的邏輯。所以你的邏輯更加分散。其中一些在代碼中，一些在配置文件中。好處在於配置可以在構建後甚至部署後進行修改。

Answer 2

我們的團隊在2年前對Microsoft Patterns and Practices Enterprise Library進行了評估，作爲對我們產品線進行重新設計的一部分。我們最終使用的唯一部分是數據庫塊。我們甚至將它包裝在一些我們可以實例化的類中，這樣我們就可以剔除DAL進行單元測試; Microsoft代碼塊使用數據庫工作的靜態調用。我不確定Microsoft是否已將任何LINQtoSQL或Entity Framework內容集成到db塊中。如果沒有使用db塊，我會猶豫是否使用db塊。

就日誌記錄而言，我們發現Log4Net是一個更加健壯和靈活的解決方案，即Microsoft日誌記錄。我們爲此滿足了我們的採伐需求。

對於異常處理，我們推出了自己的。微軟的代碼沒有處理我們想處理的遠程處理案例，而且由於我們使用的是第三方日誌記錄框架，編寫我們自己的異常庫並與之集成更有意義。我發現將日誌框架集成到異常框架中的某種程度可能非常有用。我們在Log4Net上編寫了一些輕量級的包裝類，並從我們的異常日誌記錄中調用了這些類，所以我們沒有在Log4Net上引入依賴關係。

Answer 3

除了Paul提及的有關數據應用程序塊的內容外，我還想指出，根據我的經驗，數據應用程序塊也提供了一種更快的方式來編寫所需的數據庫代碼， 。我用它來保持一致的外觀/感覺和發展速度。