在构建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; // Mappings（例如，NHibernate HBM，存储库）
• App.Services; //系统的公开功能
• App.Controllers; //视图控制器
• App.Controllers.Flex; //专门用于flex的控制器

至少在非实时应用程序中，性能始终是需要考虑但不是必需的。维护和可行性是我认为最重要的。

Answer 2

这确实是一个主观问题，每个组织都会有完全不同或非常相似的模式。没有最好的答案，但有好的和坏的方法。业界常见的模式是将您的库名称基于功能。例如，在我们的一个产品中，我们有：

• 产品名称
• ProductName.Activation
• ProductName.Activation.Service
• ProductName.Core
• ProductName.Data
• ProductName.Data.Customers
• ProductName.Data.Engine
• ProductName.Instrumentation
• ProductName.Security
• ProductName.ShellUI
• ProductName.ShellUI.Windows
• ProductName.Win32

通常，遵循类似于.NET Framework的模式是一种很好的方法，或者功能是另一种模式。有些人可能会争辩说，你不想给你的程序集提供有意义的名字，这些名字可能暴露你的应用程序的易受攻击的部分或吸引注意力，但你永远不会阻止海盗成为海盗。

其他人更愿意为他们的程序集提供非常简短的名称，即使在今天，微软仍然会这样做。 （例如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中的功能如此之大，否则它适合自己的库以便于管理。

总而言之，祝你好运，因为随着项目变得庞大，组织和结构将不断进行斗争，但如果你保持一切整洁，有条理，易于发现和理解，那么你的项目将很容易管理。