Jason,
Except for the simplest of applications, I normally put each layer in their
own project, with each project having a distinct namespace, with a common
root. Similar to what you & Z D stated.
However I start with the Namespace Naming Guidelines from the .NET Design
Guidelines for Class Library Developers:
http://msdn.microsoft.com/library/d...enref/html/cpconNamespaceNamingGuidelines.asp
Instead of Technology qualifier I will include an Application Qualifier.
So if the name of your company is MyCompany, my namespaces would be
something like:
MyCompany.X.Business - Business Layer
MyCompany.X.Data - Data Layer
MyCompany.X.Framework - common framework used across the layers
MyCompany.X.UI - User Interface
Also as you can see, I don't normally include the word Layer in the
namespace itself. I will create sub namespaces as required.
MyCompany.X.UI.Design
MyCompany.X.UI.Controls
Some projects the "Business" layer (really the Domain Model/Layer
http://www.martinfowler.com/eaaCatalog/domainModel.html) is where its at, I
will not have a suffix on that layer.
MyCompany.X - Domain Model (Business Layer)
MyCompany.X.Data - Data Layer
MyCompany.X.Framework - common framework used across the layers
MyCompany.X.UI - User Interface
Note I normally call the Projects themselves Business, Data, Framework, UI
in the X solution. However using the Project Properties I will change the
root namespace to the above names and change the assembly name to match the
namespace.
Project: Business
Assembly: MyCompany.X.Business
Namespace: MyCompany.X.Business
Project Data
Assembly: MyCompany.X.Data
Namespace: MyCompany.X.Data
Note the Framework project is where I keep Separated Interfaces
http://www.martinfowler.com/eaaCatalog/separatedInterface.html, support
class, and utilities... Unless said item is more specific to one or two
layers.
Remember that namespaces are used to Organize your application, if you have
a single namespace with all your types (Classes, Structures, Interfaces,
Delegates, Enums) it makes finding a specific type harder sometimes. At the
same time, I would not have a namespace for just classes, and a namespace
for just Structures, I tend to partition based on what "layer" the type is
in. In other words a namespace is another form of Encapsulation, related
types should be in the same namespace based on a specific subject.
Hope this helps
Jay
Jason said:
Simple design, have a .net class library called BusinessLayer and one
called DataLayer. Business layer has PurchaseHandler class and data layer
has PurchaseDA class.
As these are different projects, the default namespaces for an application
X would be X.BusinessLayer.PurchaseHandler and X.DataLayer.PurchaseDA
Is it better to keep this namespace convention or override the class
namespaces to X.Purchase.PurchaseHandler and X.Purchase.PurchaseDA so the
layering is hidden from the developer and it keeps the objects related to
their subject.
I accept that this will be hard as I would be changing the namespace for
each class in each layer e.g. X.Employee etc
