正確的應用程序的.NET DLL結構

Question

...如果有這樣的事情。下面是在.NET應用程序中構建DLL /引用的兩種方法的圖像：http://www.experts-exchange.com/images/t80668/compArch.png。該應用程序可以是一個網站（在這種情況下）或Winform。每個框表示一個DLL。對於winform應用程序，只需將「webcontrols」替換爲「winformcomponents」即可。

第一張（頂部）圖片是我喜歡的圖片。您可能想要擴展「某些」基本Web控件並直接使用其他Web控件。第二張圖片讓你通過界面擴展任何網頁控件。對我來說這看起來有點過分，因爲你可能只想簡單地使用已經存在的內容而不需要修改。哪個更好，有哪些優點/缺點？

第一張圖片將最低的公共構造（例外，fileIO，常量等）放入common.dll中。第二張圖片將應用程序業務邏輯和常見功能放入一個DLL中。哪個更好，每個apporach的優缺點是什麼？

Answer 1

我認爲這真的是一個程序員偏好。

這一切都歸結爲依賴關係。一個DLL中的更多事情意味着它自然會在該DLL上創建更多的依賴關係。

我個人傾向於沿着類似的路線到MS結構遵循，原因如下：

• 這使得它更容易爲新人定製的「框架」中找到自己想要的（如CompName.Web.UI和CompName.Data什麼。
• 它有助於減少依賴於「明顯」的選擇。我不是太熱衷於CompName.Common型DLL的，因爲它沒有明確指出可能的家屬，而CompName.Web.UI表明，它很可能通過任何Web應用程序中使用。
• 明顯的大小r教育，因爲DLL內容將更加「相關」。

DLL的一個應用程序內層是有意義的，中的類型應該只由商業模式所需要的那些類型，其他對象（如公用事業，數據訪問等）應在自己的圖書館。

Answer 2

大量的引用通常是不好的，因爲加載DLL具有不可忽略的成本。它可能並不高雅，但擁有更少的模塊可以提高您的性能。在我們的工藝中，經常需要找到總體模塊化優雅與性能嚴酷現實之間的平衡點。像往常一樣，在我們的工藝中，直到開始分析測量應用程序的性能時，纔會知道平衡是什麼。