Best practice when creating reusable corporate namespace

Question

Alright, this has been on my mind for a while now. I'm in the process of creating a reusable corporate namespace(class library) for all common middle-tier objects. This assembly can then be referenced by any of our developers during the development phase of their project. Here's my question. Is it more acceptable to create a single assembly which consists of all our middle-tier logic or to break this functionality up into smaller assemblies?

Example: Single Assembly(namespace examples)

System

System.IO

System.IO.RegEx

System.Net

System.Net.Mail

System.Security

System.Web - AssemblyFull.dll

Example: Multiple Assemblies

System.IO

System.IO.Reg - Compiles to AssemblyIO.dll

System.Net

System.Net - Compiles to AssemblyNet.dll

In the past I've done this using both methods but I'm wondering what everyone else does and why? I'm not looking for any code examples, I just want to know what other developers have doing?

Thanks in advance.

Answer 1

As a general rule, I use to separate assemblies if they are not explicit coupled. For example if you have a low level Networking API, and other API for FTP related operations, probably the later depends upon the former; but for the API user, your developers; there is no need to have both in a single assembly; maybe one project does not require the FTP API, so they only need to include the core "Net" assembly. You can separate APIs in order to be the more atomic as possible and avoid developers to include a big assembly when their will use only a small part of it.

The down side of this approach is that if the developer needs the FTP assembly they also need to include the Net one; so you have to find a way to manage those dependencies that reduces the complexity for developers. I use Maven (from Apache) when doing Java applications but by this date I do not know a good maven-like alternative for .NET.

But if your are building a few APIs for your company, with a Wiki site or other light weigh documentation tool you can address this problem.

Answer 2

I dont think their is a right answer for this but I tend to use a common naming approach for all of our libraries.

I have a library that handles a lot of the middle-tier functionality, sort of like common tasks that most apps would use.

Web.CreditCard
Web.CreditCard.Authorization
Web.CreditCard.Charge
Web.CreditCard.Batch

Web.Store.Order
Web.Store.Entities
Web.Store.Cart
Web.Store.Auth

Web.User.Auth.OpenID
Web.User.Auth.OAuth
Web.User.Account
Web.User.Preferences

So it don't matter which type of project your building you can reuse them and identify them really quick. Some of them have their own interfaces and can be inherited and overloaded to add more functionality depending on the project requirements.