構建N層應用程序時，應如何組織名稱空間？

Question

因此，當我開始嘗試以n層架構構建網站時，我擔心性能。

回答問題的一個人告訴我，如果您應用了良好的體系結構，最終將獲得更好的性能。 它與編譯dll和東西有關，但是現在我不確定如何命名我的命名空間。

就像我的數據訪問層擁有主要的命名空間一樣，假設我將此命名空間作為數據層..DAL

但是現在，在應用程序中我需要的不僅僅是實體，還需要由該層提供服務，並且每個實體都有自己的較小實體。

因此，我應該將所有數據代碼都包含在一個命名空間（DAL）下，還是每個實體都具有自己的命名空間，例如DAL.E1和DAL.E2，或者每個主實體或子實體都應該具有其自己的命名空間，例如DAL.E1.c1，DAL .E2，DAL.E3.c1，DAL.E3.c2 ..最后一個問題DAL本身是否應包含任何類？

Answer 1

嗯...它更像是一個組織問題。

我通常更喜歡通過系統上的功能，然后在需要時通過對對象類型進行分組來在一個名稱空間（類，結構等）中組織項目。

例如：

• App.Domain; //域實體
• App.Domain.Authentication; //與身份驗證相關的域實體
• App.Domain.Repository; //存儲庫實現
• App.Domain.Repository.Mapping; //映射（例如，存儲庫的NHibernate HBM）
• 應用服務； //公開的系統功能
• App.Controllers; //視圖控制器
• App.Controllers.Flex; //專門針對flex的控制器

至少在非實時應用程序上，性能始終是要考慮的一點，但不是必需的。 我認為最重要的是維護和實用性。

Answer 2

這確實是一個主觀問題，每個組織都會有一個完全不同或非常相似的模式。 沒有最佳答案，但是有好辦法。 行業中的一種常見模式是使庫名稱基於功能。 例如，在我們的一種產品中，我們有：

• 產品名稱
• ProductName.Activation
• ProductName.Activation.Service
• 產品名。核心
• 產品名稱。數據
• 產品名稱。數據。客戶
• 產品名稱。數據。引擎
• 產品名稱。儀器
• 產品名稱。安全性
• 產品名稱.ShellUI
• 產品名稱.ShellUI.Windows
• 產品名稱.Win32

通常，遵循類似於.NET Framework的模式是一種好方法，或者按功能是另一種方法。 有人可能會爭辯說，您不希望為程序集提供有意義的名稱，而這些名稱可能會暴露應用程序的易受攻擊的部分或引起注意，但是您永遠不會阻止海盜成為海盜。

其他人則希望為其程序集使用非常短的名稱，即使到了今天，Microsoft仍然使用該名稱。 （例如，mscorlib.dll）。

我想這一切都取決於項目以及正在進行的事情。 我並不總是遵循相同的經驗法則，但是我有99％的時間遵循共同的模式，而我曾任職的前一家公司也有固定的模式和實踐。

就項目內部的邏輯組織而言，祝您好運。 我交談過的大多數其他開發人員都在說同樣的話。 “我只是選擇了一個結構/名稱並使用了它”。 當然不是盲目地，而是經過一些思考，但是很難有最好的方法，只有指南。

我的建議是按功能組織它，因為它使項目的管理變得容易。 您知道Module1處理系統的Part1，而Module2處理Part2，依此類推。 例如ProductName.Data.dll。 在我的項目中，它處理所有數據綁定操作，例如設置，首選項和數據庫交互，而ProductName.Data.Engine是允許ProductName.Data輕松與數據層通信的框架。 （在這種情況下，ProductName.Engine是帶有其他自定義類和必需框架部分的Entity Framework東西）。

我猜想我要遵循的另一條經驗法則是，如果Module1具有構成應用程序Part1的許多部分，則將其全部保留在Module1中。 除非像ProductName.Data.Engine中那樣具有如此大的功能，否則它適合於自己的庫以簡化管理。

總而言之，祝您好運，因為隨着項目規模的擴大，組織和結構將一直處於斗爭之中，但是如果您將所有事情保持整潔，有條理，易於發現和理解，那么您的項目將易於管理。