所以当我开始尝试在 n 层架构中构建我的网站时，我担心性能。
其中一位回答问题的人告诉我，如果你应用了一个好的架构，你最终会获得更好的性能。它与编译 dll 和东西有关，但现在我不确定如何命名我的命名空间。
就像我的数据访问层有主命名空间一样，假设我有这个命名空间作为我的数据层..DAL
但现在我在应用程序中有多个实体需要由该层提供服务，并且每个实体都有自己的较小实体。
所以我应该将所有数据代码包含在一个命名空间 (DAL) 下，还是每个实体都有自己的命名空间，如 DAL.E1 和 DAL.E2，或者每个主实体或子实体都应该有自己的命名空间，如 DAL.E1。 c1, DAL.E2, DAL.E3.c1, DAL.E3.c2 .. 最后一个问题 DAL 本身是否应该包含任何类？
【问题讨论】：
标签： c# asp.net architecture namespaces n-tier-architecture
嗯……这更像是一个组织问题。
我通常更喜欢通过系统上的功能来组织一个命名空间（类、结构等）中的项目，然后，如果需要，通过对对象类型进行分组。
例如：
性能始终是一个需要考虑的重点，但不是必不可少的，至少在非实时应用程序中是这样。维护性和可实现性是我认为最重要的。
【讨论】：
这确实是一个主观问题，每个组织都会有完全不同或非常相似的模式。没有最佳答案，但有好的和坏的方法。行业中的一种常见模式是根据功能来命名您的库名称。例如，在我们的一款产品中，我们有：
通常遵循类似于 .NET Framework 的模式是一种好方法，或者按功能是另一种方法。有些人可能会争辩说，您不希望为您的程序集赋予可能会暴露应用程序的易受攻击部分或引起注意的有意义的名称，但您永远不会阻止盗版者成为盗版者。
其他人更喜欢给他们的程序集起非常短的名称，即使在今天，微软仍在这样做。 （例如 mscorlib.dll）。
我想这完全取决于项目和正在发生的事情。我并不总是遵循相同的经验法则，但 99% 的时间我都遵循一个共同的模式，而我工作的前公司也有他们的既定模式和做法。
就项目内部的逻辑组织而言，祝你好运。与我交谈过的大多数其他开发人员都跟我说同样的话。 “我刚刚选择了一个结构/名称并使用它”。当然不是盲目的，而是经过深思熟虑，但很难有最好的方法，只有指导方针。
我的建议是按功能组织它，因为它使项目管理变得容易。您知道 Module1 处理系统的 Part1，Module2 处理 Part2，依此类推。 ProductName.Data.dll 就是一个例子。在我的项目中，它处理所有数据绑定操作，例如设置、首选项和数据库交互，而 ProductName.Data.Engine 是允许 ProductName.Data 轻松与数据层通信的框架。 （在这种情况下，ProductName.Engine 是具有其他自定义类和所需框架部分的实体框架内容）。
我想我遵循的另一条经验法则是，如果 Module1 有许多组成应用程序的 Part1 的部分，我会将它们全部保存在 Module1 中。除非在 ProductName.Data.Engine 中该功能如此庞大，否则它适合自己的库以便于管理。
总而言之，祝你好运，因为随着项目变得越来越大，组织和结构一直在挣扎，但如果你保持一切都井井有条、井井有条，并且找到并易于理解，那么你的项目将很容易管理。
【讨论】：