developer.* Blogs - Organizing .NET Namespaces - Comments

Great...

ChrisG — Mon, 10 Jul 2006 08:50:17 -0700

Great article, well written and in total agreement with all my design principles.

Congrats...

Response

trevor.conn — Wed, 07 Dec 2005 12:53:26 -0800

In order, here are my responses.

#1) You've said you know the difference between the three items you mention, but I'll re-iterate anyway so we're on the same page. I think of them like this:

Project = source code organized via a "project" file that is then included in a solution in Visual Studio.

Assembly = the compiled output of a project.

Namespace = a logical grouping of common functionality.

Given the above, one project can contain code belonging to multiple namespaces if necessary. And since the assembly is the compiled output of a project, so can the assembly.

#2) No. The way I've worked until very recently is to, as much as possible, create one project for every namespace I need. Similarly, if using VS.NET, only one project will go into a solution file. This keeps the code seperated out into the most cohesive chunks possible for ease of maintenance. I have had to combine namespaces into a single assembly before, and that might not be a problem if you work in a traditional build-n-ship software company. But I've found that it creates nightmares in a highly volatile web shop where multiple development efforts can bottleneck on the same project because too much functionality is tied up in it. The only time I would combine namespaces into a single assembly is to deal with an otherwise circular relationship that can't be factored out of the design....and that should almost never happen.

Having said that, I'm sure it's possible to get VS.NET to copy your built assemblies to a common directory from which all of your projects reference their dependent assemblies. Then when you build, all your other projects using that common directory will be automatically updated when you refresh their references or recompile them in turn. Similarly, you could create one monolithic solution file that contains all of your namespace projects, and specify the build order in the solution so that everything gets built at compile time. This has the pleasant side effect of also telling you when you've unwittingly introduced a circular reference somewhere. This is the strategy I've been using more recently since I've started working with .NET 2.0.

#3) If Assembly B needs to use classes in Assembly A, you have to add a reference. Your hunch is correct that your business class assemblies should reference the data namespace and not the other way around. Nor should you consider tightly coupling the data classes with the business classes as in compiling them into the same assembly. I'm not exactly sure what you mean when you say you map the output of your data readers to your business classes, but if your business classes are building statements or feeding sproc calls via the data layer to the database, they should be the ones handling the output of the data reader and then transforming that into a "state" class that's handed back to the caller from the application layer.

Feel free to post a pseudo-code example if you want.

Great article. I have a

Guest — Wed, 07 Dec 2005 09:19:02 -0800

Great article.

I have a few questions that I was hoping you would answer.

1. I am a little confused by the differences between a .NET project, an assembly and a namespace. I know what each of these are, but it seems that I am constantly having to add references so that one assembly can see another.

2. In your example, did you create one project (CompanyName) and then create folders under the CompanyName project so that namespaces like CompanyName.Web.UI.Private can see CompanyName.Web.UI without adding references to CompanyName.Web.UI.Private?

3. Is there a way for CompanyName.Data to see CompanyName.Customer without adding references?

I am asking these question because I have created as separate projects:

CompanyName
CompanyName.Web.UI
CompanyName.Business
CompanyName.Data

On my current project I need to map the output of datareaders from my data classes to my business classes. This would suggest that I have a reference from Data to Business. I was always under the impression that it should be the other way around.

Thanks

Organizing .NET Namespaces

trevor.conn — Sun, 20 Feb 2005 16:30:20 -0800

A couple months ago I posted the following entry on a discussion forum myself and some friends participate in. A buddy was asking for tips on how to transition this massive VB/COM+ project over to .NET and how he should start thinking about structuring functionality into namespaces assemblies. I'm just going to post it here in case it proves helpful for anyone else. I haven't really revised this post at all, so it may read sort of open-ended. Anyone with questions is welcome to ask.