6

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.

TCNS-Bob
  • 63
  • 6
  • How large would the assembly be if it just contained everything? Do you expect projects in your company to use all of the common functionality? If not, can you logically separate it into related sub-units (that could then be good candidates for putting in different assemblies)? – Richard Ev Sep 25 '11 at 16:33
  • google for reuse/release equivalence principle – driushkin Sep 25 '11 at 16:35
  • Richard - The [full] assembly will be comprised of 100's of objects. Most projects will always use 75%-85% of the functionality exposed but could still use other pieces as well. My initial thought was to handle this just as you stated. Take the most widely used objects and build into a common assembly then take the other objects and break them into separate units. But on the other hand I can see how a single assembly could make other developer's lives easier. You would only need to reference the middle-tier assembly and be done with it. I have a feeling this is 6 to 1 half a dozen to the other – TCNS-Bob Sep 25 '11 at 16:59
  • driushkin - thanks for the tip. An old PM I used to work with turned me on to this. The biggest problem I'm facing is how any future developers are going to be accessing these assemblies. I want to make it as painless as possible. I personally document that crap out of all my objects so the next guy understands what each object's purpose is. I really don't think there is a right or wrong answer. You could create a single, all encompassing assembly or 20 different assemblies that are each responsible for their own unique action/task. – TCNS-Bob Sep 25 '11 at 17:11

4 Answers4

4

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.

Community
  • 1
  • 1
Lorenzo Solano Martinez
  • 346
  • 3
  • 8
  • Lorenzo - thanks for the quick response. That's the first time I've heard of Maven, sounds pretty cool. The more I think about this breaking my objects up makes the most sense. Well separating them as much as possible. If one of the developers needs access to email functionality there really is no reason for the cryptography objects to be visible/accessible. Thanks for all the quick responses guys, I really appreciate getting input from others. Plus I see I'm not the only one working on Sunday. – TCNS-Bob Sep 25 '11 at 17:59
  • @lorenzo NuGet (www.nuget.org) is as close as you're going to get to Maven on .NET – x0n Sep 25 '11 at 18:11
1

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.

Michael D. Irizarry
  • 6,186
  • 5
  • 30
  • 35
  • This is almost exactly what I'm looking at in our repository. I just wanted to make it as easy as possible for other developers. I'm going to move forward with a common assembly that will be used for all projects then separate assemblies for not so common functionality. Thanks to everyone who got back to me so quickly, I really appreciate it. – TCNS-Bob Sep 25 '11 at 18:24
0

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.

TCNS-Bob
  • 63
  • 6
  • 1
    I for one do not like using the Company name within a namespace, I used to work with Verizon and a lot of namespaces where Verizon.[Name] and now that chunk of the company is no longer named Verizon but it still has that namespace stuck there. – Michael D. Irizarry Sep 26 '11 at 18:36
  • Valid point. I typically do use the company name due to the fact that we're usually performing some form of integration where it's easier to identify where the assembly came from. If you were creating a generic namespace what would you use as your top-level? – TCNS-Bob Sep 27 '11 at 15:22
0

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:

  • just add the common functionality I need
  • no extra dependencies
  • Bug fixes in utilities are automatically included in next build

The only drawback is that if you manually need to add any dependencies the added functionality got (e.g. another reusable component or an assembly)

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

  • Company.Utilites
  • Company.Utilites.WPF
  • Company.Utilites.IO
adrianm
  • 14,468
  • 5
  • 55
  • 102