Best practice when creating reusable corporate namespace_问答_开发者

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 objec开发者_开发问答ts. 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.

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.

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.

Thanks to everyone who replied to this question. Since each project is different and it's nearly impossible to come up with a correct answer I'll describe how I'm going to approach this.

First:

I need to identify which business/middle-tier objects are going to be used in all projects moving forward. Once these have been identified I will create an assembly [company].common or [company].common.util. These will be referenced for each of our current and up-coming projects.

Second:

Identify the objects that are more project specific. These assemblies may or may not be referenced. An example would be [company].security.cryptography.

Third:

Make sure that each object is well documented so that future developers will have the knowledge needed to properly maintain and reference the correct assemblies.

I wanted to thank everyone for getting back to me so quickly. This was my first post on SO but I can assure you that you'll see me here again very soon. Thanks again.

I used a different approach for reusable files.

I create a separate solution that includes all reusable components, test etc.

Each reusable "thing" (class, function, UserControl, icon, etc) is in a separate file.

The projects that need some functionality from the reusable part just link directly to the source file. ("Add existing item", "Add as link"). For convenience I place all reused parts in a "utilities" folder in VS (the real utilities folder is empty since the files are linked)

This setup allows me to: