Best practices for creating a reusable corporate namespace

Question

Well, that was in my opinion for a while. I am creating a reusable corporate namespace (class library) for all common mid-range objects. This assembly can be referenced by any of our developers at the stage of developing your project. Here is my question. Is it more acceptable to create a single assembly, which consists of all our intermediate-level logic, or to decompose this function 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 - Compiled in AssemblyIO.dll

System.net

System.Net - Compiles AssemblyNet.dll

I did this in the past using both methods, but I wonder what everyone else is doing and why? I'm not looking for code examples, I just want to know what other developers are doing?

Thanks in advance.

Answer 1

As a rule, I use to separate assemblies if they are not explicitly linked. For example, if you have a low-level network API and other APIs for FTP-related operations, it may later depend on the first; but for the API user, your developers; no need to have both in one assembly; perhaps the FTP API is not required for a single project, so they only need to enable the base assembly "Net". You can separate the API to be as atomic as possible, and not allow developers to include a large assembly when they use only a small part.

The downside of this approach is that if a developer needs an FTP assembly, they should also include Net; so you need to find a way to manage these dependencies, which reduces complexity for developers. I use Maven (from Apache) when running Java applications, but by this date I don't know a good maven-like alternative for .NET .

But if you are creating several APIs for your company, using the Wiki site or another document to document weights, you can solve this problem.

Answer 2

I don't think this is the right answer for this, but I tend to use a common naming approach for all of our libraries.

I have a library that handles many mid-level functions, like the usual tasks that most applications will 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

Thus, no matter what type of project you can use for your building, you can quickly identify them. Some of them have their own interfaces and can be inherited and overloaded to add more functionality depending on the requirements of the project.

Answer 3

Thanks to everyone who answered this question. Since each project is different and it is almost impossible to come up with the right answer, I will describe how I am going to approach this.

At first:

I need to determine which business / mid-range facilities will be used in all projects moving forward. Once they are identified, I will create the assembly [company] .common or [company] .common.util . They will be indicated for each of our current and future projects.

The second:

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

Third:

Make sure that each object is well documented so that future developers have the knowledge necessary to maintain and reference the correct assembly.

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

Answer 4

I used a different approach for reusable files.

I am creating a standalone solution that includes all reusable components, test, etc.

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

Projects that need some functionality from the reusable part simply link directly to the source file. ("Add existing item", "Add as link"). For convenience, I put all the reusable parts in the "utilities" folder in VS (the real utilities folder is empty because the files are linked)

This setting allows me to:

• just add the general functionality that I need.
• no additional dependencies
• Bug fixes in utilities are automatically included in the next build

The only drawback is that if you need to manually add any dependencies, added added functionality (for example, another reusable component or assembly)

Since I don't use different assemblies, the namespace just follows the function:

• Company.Utilites
• Company.Utilites.WPF
• Company.Utilites.IO