0

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 ?

Mazen Elkashef
  • 3,430
  • 6
  • 44
  • 72

2 Answers2

1

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.

David Anderson
  • 13,558
  • 5
  • 50
  • 76
  • I understand that it's subjective and depends on each project, but If beginners need to ask some subjective questions so they could have some good guidelines to help them decide which design pattern to be used. After all thank you =) I was just concerned if there's a good/bad practices that will affect my application in either +ve/-ve way. But now I think it won't so I'll have an organization that's based on the answers here and add a little of how I'll feel that my application is organized. – Mazen Elkashef Sep 17 '11 at 08:09
  • 1
    This is dirt old, but has been a popular download none-the-less. http://www.dcomproductions.com/Downloads/developerdocument.pdf. It covers some naming guidelines I wrote way back briefly. It also covers naming conventions and other general conventions, the goal is to provide guidelines for writing high-quality code and well structure source – David Anderson Sep 17 '11 at 08:17
  • :D Ok .. I'll read it, I'm need this old stuff especially if it's still used. Because of you understood the old stuff, You'll catch on the new trends very easy – Mazen Elkashef Sep 17 '11 at 08:27
0

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.

Daniel Ferreira Monteiro Alves
  • 26
  • 4
  • So in Domain Entites should I have App.Domain.Enitiy1, App.Domain.Enitiy2 or should I list all the domain entities under one namespace ? – Mazen Elkashef Sep 17 '11 at 07:59
  • Try to group the entities by their relationship and functionality. As more dependent they are, maybe it has a great change of be together or sharing a same base namespace. But you can have something like, in Domain: EntityBase. And then in Authentication: User, Role which inherits from EntityBase, – Daniel Ferreira Monteiro Alves Sep 17 '11 at 08:14