Should internal .NET applications be placed in the same namespace as the internal libraries they depend on?

Question

The company where I work has recently decided to use a combination of .NET and Java for all future development efforts. We've been trying to standardize how we organize our code into namespaces (.NET) and packages (Java) and no one really has experience trying to organize namespaces for multiple products involving multiple platforms.

Recently, I got involved with a new product that uses a Java frontend (it runs on Blackberry devices) with a .NET backend (a message broker that allows the Java frontend to communicate with our legacy VB6/COM code, because we didn't want to deal with COM on the Java side and it's easy to make .NET work with our existing VB6 code). Right now I'm just focusing on the .NET side of things.

I created a new .NET solution called CompanyName.ProductName.Broker, and ended up with two subprojects: a Core class library project that implements the majority of the broker code, and a BrokerConsole console project that allows the broker to started and stopped from the commandline (the broker will be running on a server along with a RabbitMQ message queue server).

Right now, both projects are in subnamespaces of the CompanyName.ProductName.Broker namespace. The question is, does this make sense?

On the one hand, the BrokerConsole project is pretty tightly-coupled to the Core project, but on the other hand, the BrokerConsole compiles to a standalone EXE. I was thinking it might make more sense to put the BrokerConsole project into a separate root namespace, maybe something like CompanyName.Apps.ProductName, because it's really a front-end to CompanyName.ProductName.Broker.Core.dll and is an application as opposed to a library.

My rationale for creating an entirely new CompanyName.Apps root namespace is that typically when you create an application, you put it into a separate namespace from the libraries you are referencing anyway (i.e. you wouldn't put your web server application into the System.Web namespace). I'm thinking along the same lines, except that the referenced libraries happen to be libraries developed by the company.

Is this a good idea, or should I try and keep everything related to a "product" (in marketing terms) under a common CompanyName.ProductName namespace? Are there better ways to manage multiple projects that together make up a single product?

Answer 1

I would separate the two into CompanyName.ProductName.Broker.Console and CompanyName.ProductName.Broker.Core. The only potential problem with this is the use of Console as a name, given the presence of System.Console. (This can be avoided using CompanyName.ProductName.Broker.BrokerConsole, but that's a bit ugly.)

Separating the two out will make it clearer for future apps which may also want to use the Core functionality.

Answer 2

I think your approach makes sense, and it follows pretty much the same logic that I usually follow, and that is also followed at my current client (a rather large company).

I think that the difference might be this if I was giving the names: the assembly CompanyName.ProductName.Broker.Core would most likely have CompanyName.ProductName.Broker as its "top-level" namespace (excluding the word Core), while the Console app (that I would name CompanyName.ProductName.Broker.Console; the namespace has already established the Broker part) would have a one-to-one relationship between the assembly name and the namespace name.

I see no point in separating the Console from the library by putting it in a completely separate namespace, quite the opposite. I think that they should be live in the same namespace, since they are part of the same product.

Answer 3

I have traditionally broken out executable applications into their own namespace. From my understanding, namespaces are there to help out with code organization, so I think it's pretty rare where someone will be referencing the BrokerConsole application from another project.

So, basically, I would create:

• CompanyName.ProductName.Broker.Core
• BrokerConsole

Answer 4

We normally split it up so that each project within a solution has it's own namespace, within each project there may be sub-namespaces. Each project, and therefore each namespace is therefore contained in it's own dll.

Answer 5

I generally use namespaces as a way to partition how a class relates to other classes in terms of responsibility and interdependencies - and occasionally intent.

I use assemblies to partition classes based on whether they are distributed together and whether functionality is co-located. I also use assemblies to partition elements of my system that are either deployed independently, are used by multiple projects, or may be substituted or replaced in production.

Based on your description, I think that your physical separation of assemblies makes sense, as it provides an opportunity for reuse and replacement.

I might, however, choose to have some of the namespaces shared between the assemblies if the intent of the classes is similar or logical dependendencies exist.

For example, I may have a CompanyName.ProductName.Utility namespace that both assemblies use to organize utility code - even if it is not shared between assemblies.