2010-04-16 110 views
1

我正試圖在我的項目中處理組織代碼 的最佳做法。我已經瀏覽了互聯網上的 以獲得很好的例子,到目前爲止,我已經看到 帶有一個或多個支持的 類庫的Web項目的示例或遵循其命名空間慣例的具有 子文件夾的Web項目的示例。代碼組織Connundrum:具有多個支持DLL的Web項目?

假如沒有正確的答案,這是我目前 對組織代碼:

MyProjectWeb

這是我的網站。我在這裏引用我的類庫。

MyProject.DLL

隨着基地的命名空間,我使用這個DLL爲 需要是一般消費品的文件。例如,我的課程「枚舉」 具有我的項目中的所有枚舉生活在那裏。由於 對所有異常處理都執行MyProjectException類。

MyProject.IO.DLL

這是用於處理文件的上傳和下載 (到目前爲止),也許20個文件的分組。

MyProject.Utilities.DLL

我所有的普通類和方法在一個 一般消費品DLL揉成了一起。每個類遵循 「XHelper」 公約 如「提供SQLHelper,化AuthHelper,SerializationHelper,等等...

MyProject.Web.DLL

我使用這個DLL作爲主要的客戶端界面。 權現在,多數這裏的類文件是:

1)性能(如學校,地點,賬戶,帖子) 2)授權的東西(如自定義成員,自定義角色, &自定義配置文件提供者)

我的問題很簡單 - 這看起來合乎邏輯嗎?

另外,我該如何避免必須從一個 項目庫中交叉引用DLL到下一個?例如,MyProject.Web.DLL 使用MyProject.Utilities.DLL中的代碼,MyProject.Utilities.DLL 使用MyProject.DLL中的代碼。這是通過點擊屬性並選擇「依賴」來解決的嗎?我試過,但似乎還沒有訪問我選擇的程序集 的命名空間。我必須參考每個類庫需要的每個 程序集嗎?

非常感謝您的耐心等待。

回答

0

從邏輯上講,它從邏輯上從你的假設中獲益。你問這個問題的事實導致我相信你可能不會認爲它是合理的

一般來說,事物應該沿概念邊界而不是技術邊界分解。 MyProject.IO.DLL是您在當前設計中體現這一原理的一個例子。所有的IO事物邏輯上都是,所以它們最終成爲一個二進制。說得通。

根據它們的技術類型 - 枚舉,類等將事情分解到命名空間 - 將會有點問題。

依賴關係問題與你打破一個類的問題相同,它使用相同的技術解決:依賴性的反轉。如果兩件事情看起來需要互相依賴,那就加入一個代表前兩者之間契約的中介。這可以是抽象的,常量,調解員等......無論你需要做什麼,而是取決於事物B而取決於事物A,取決於事物A的事物B取決於事物A和取決於事物C的事物A和B.