在构建 N 层应用程序时，我应该如何组织我的命名空间? [英] When Building an N-Tier application, how should I organize my names spaces?

问题描述

因此，当我开始尝试在 n 层架构中构建网站时，我很担心性能.

So when I started trying to build my websites in an n-tier architecture, I was worried about performance.

回答这个问题的一个人告诉我，如果你应用了一个好的架构，你最终会获得更好的性能.它与编译 dll 和其他东西有关，但现在我不确定如何命名我的命名空间.

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.

就像我的数据访问层有主命名空间一样，假设我有这个命名空间作为我的数据层..DAL

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.

所以我应该将所有数据代码包含在一个命名空间 (DAL) 下，还是应该每个实体都拥有自己的命名空间，如 DAL.E1 和 DAL.E2，或者每个主要或子实体都应该拥有自己的命名空间，如 DAL.E1.c1, DAL.E2, DAL.E3.c1, DAL.E3.c2 .. 最后一个问题 DAL 本身是否应该包含任何类?

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 ?

推荐答案

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

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:

• 产品名称
• 产品名称.激活
• ProductName.Activation.Service
• 产品名称.核心
• 产品名称.数据
• ProductName.Data.Customers
• ProductName.Data.Engine
• 产品名称.仪器
• 产品名称.安全
• 产品名称.ShellUI
• 产品名称.ShellUI.Windows
• 产品名称.Win32

通常遵循类似于 .NET Framework 的模式是一种好方法，或者按功能是另一种方法.有些人可能会争辩说，您不希望为程序集提供有意义的名称，以免暴露应用程序的脆弱部分或引起注意，但您永远不会阻止盗版者成为盗版者.

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.

其他人更喜欢给他们的程序集起很短的名字，即使在今天，微软仍然这样做.(例如mscorlib.dll).

Others prefer to give their assemblies very short names, which is still done even today by Microsoft. (mscorlib.dll for example).

我想这完全取决于项目和正在发生的事情.我并不总是遵守相同的经验法则，但 99% 的时间我都遵循一个共同的模式，而我以前工作的公司也有他们的固定模式和做法.

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.

我的建议是按功能组织它，因为它使项目的管理变得容易.您知道 Module1 处理系统的 Part1，Module2 处理 Part2，依此类推.一个例子是 ProductName.Data.dll.在我的项目中，它处理所有数据绑定操作，例如设置、首选项和数据库交互，而 ProductName.Data.Engine 是允许 ProductName.Data 与数据层轻松通信的框架.(在本例中，ProductName.Engine 是具有其他自定义类和所需框架部件的实体框架内容).

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).

我想我遵循的另一个经验法则是，如果 Module1 有许多组成应用程序 Part1 的部分，我会将它们全部保留在 Module1 中.除非在 ProductName.Data.Engine 中该功能如此之大，否则它适合于自己的库以便于管理.

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.

这篇关于在构建 N 层应用程序时，我应该如何组织我的命名空间?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！