在构建 N 层应用程序时，我应该如何组织我的名称空间？
因此，当我开始尝试在 n 层架构中构建网站时，我担心性能。
回答这个问题的一个人告诉我，如果你应用了一个好的架构，你最终会得到更好的性能。它与编译 dll 之类的东西有关，但现在我不知道如何命名我的命名空间。
就像我有数据访问层的主命名空间一样，假设我有这个命名空间作为我的数据层..DAL
，但现在我在应用程序中拥有多个需要由该层提供服务的实体，并且每个实体都有自己的较小的实体。
因此，我应该将所有数据代码包含在一个命名空间 (DAL) 下，还是应该每个实体都有自己的命名空间，如 DAL.E1 和 DAL.E2，或者每个主实体或子实体都应该有自己的命名空间，如 DAL.E1.c1、DAL .E2、DAL.E3.c1、DAL.E3.c2 ..最后一个问题 DAL 本身是否应该包含任何类？
So when I started trying to build my websites in an n-tier architecture, I was worried about performance.
One of the guys who answered the question told me if you applied a good architecture you'd end up with even a better performance. It's related to compiling the dlls and stuff, but now I'm not sure how to name my namespaces.
Like I have the main Namespace for my data access layer so let's say I have this namespace as my data layer ..DAL
but now I have more than entity in the application that needs to be served by this layer, and each entity has it's own smaller entities.
so should I include all the data code under one Namespace (DAL) or should I each entity have it's own namespace like DAL.E1 and DAL.E2 or each main or child entity should have it's own namespace like DAL.E1.c1, DAL.E2, DAL.E3.c1, DAL.E3.c2 .. last question should DAL itself include any classes or not ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这确实是一个主观问题，每个组织都会有完全不同或非常相似的模式。没有最好的答案，但有好的和坏的方法。业界的常见模式是根据功能来命名库名称。例如，在我们的一款产品中，我们有：
一般来说，遵循类似于 .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 中的功能如此之大，否则它适合自己的库以便于管理。
总而言之，祝你好运，因为随着项目变大，组织和结构会不断陷入困境，但如果你保持一切整洁、有组织、易于发现和理解，那么你的项目将很容易管理。
This is really a subjective question, and every organization will have a completely different, or very similar pattern. There's not a best answer, but there are good and bad approaches. A common pattern in the industry is to base your library names off of features. For example, in one of our products we have:
Generally following a pattern similar to the .NET Framework is a good approach, or by feature is another. Some may argue that you would not want to give your assemblies meaningful names that may expose vulnerable parts of your application or draw attention, but you will never stop pirates from being pirates.
Others prefer to give their assemblies very short names, which is still done even today by Microsoft. (mscorlib.dll for example).
I suppose it all depends on the project and what's going on. I don't always abide to the same rule of thumb, but 99% of the time I follow a common pattern, and the former company I worked for had their set patterns and practices as well.
As far as logical organization inside your projects, well, good luck. Most other developers I've talked to say the same thing I do. 'I just picked a structure/name and went with it'. Of course not blindly, but with some thought into it, but its hard to have a best approach, only guidelines.
My suggestion is to organize it by feature, because it makes management of the project easy. You know that Module1 handles Part1 of the system and Module2 handles Part2, and so on. An example would be ProductName.Data.dll. In my project, it handles all data-bound operations such as Settings, Preferences, and Database interaction, while ProductName.Data.Engine is the framework that allows ProductName.Data to communicate easily with the data tier. (In this case ProductName.Engine is the Entity Framework stuff with other custom classes and required framework parts).
I guess another rule of thumb I go by is if Module1 has many parts that make up Part1 of the application, I would keep it all in Module1. Unless like in ProductName.Data.Engine where that feature was so large, it was suited to its own library for easier management.
All in all, good luck, because organization and structure is constant struggle as projects become large, but if you keep everything tidy, organized, and well found and understood then your project will be easy to manage.
嗯……这更像是一个组织问题。
我通常更喜欢根据系统的功能来组织一个命名空间中的项目（类、结构体……），然后，如果需要，通过对对象类型进行分组。
例如：
性能始终是一个需要考虑的问题，但不是关键问题，至少在非实时应用程序。可维护性和可靠性是我认为最重要的。
Humm... it more like an organization problem.
I usually prefer to organize the items in one namespace (classes, structs, ...) by the functionality on the system, and then, if needed, by grouping types of objects.
For example:
Performance is always a point to consider but not the essential one, at least on non real-time applications. The maintainance and realibility is the one that I think are the most important.