构建N层应用程序时，应如何组织名称空间？

Question

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 ?

Answer 1

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:

• App.Domain; // Domain entities
• App.Domain.Authentication; // Domain entities related for the authentication
• App.Domain.Repository; // The Repository implementation
• App.Domain.Repository.Mapping; // The Mappings (NHibernate HBM, for example, of the repository)
• App.Services; // exposed functionality of the system
• App.Controllers; // controllers of view
• App.Controllers.Flex; // controllers specialized for the flex

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.

Answer 2

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
• 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

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.