9

I'm working on a Silverlight application. I've split it up in several assemblies:

  • Domain
  • Repositories (everything with persisting to the Sterling database)
  • UI
  • ...

This is how I've learned it, but I wondered. If you know the DLLs are not going to be reused, is it necessary to split them up? Or could you put everything in one assembly and use folders and namespaces to keep it tidy?

I've also seen projects that have too many assemblies. Instead of using namespaces where it would have been appropriate.

So: when do you create a new assembly for some new piece of code? Any good resources on this subject? And do you split code up technically (domain, data, ui, etc.) and/or functionally (i.e. patient-administration, patient-medical, hospital-logistics, ... - probably only for bigger, enterprise level applications)?

Improve this question

2 Answers 2

Reset to default
1

I recommend creating separate assemblies for classes that logically fall into "modules". Not only is this good for reuse and maintainance but it's also a way to enforce the least amount of dependencies between classes.

The mission will be to minimize the number of references to other assemblies that each assembly needs, mostly this will be done through interfaces and events. Having classes in different assemblies will make dependencies very obvious. Contrast that to if you just use one assembly, then it very easy to neglect thinking about dependencies since everything is accessible.

Of course you shouldn't exaggerate but separate where appropriate. Think about it like this: "These classes belong together and doesn't need to know about these classes" and separate along those lines

Improve this answer
6
  • 1
    Depends what you mean by "modules", but I typically divide related logic using namespaces rather than assemblies. Remember, namespaces can span assemblies. Assemblies are the unit of deployment and so you should consider cutting your assemblies to match your deployment scenario.
    – Ed James
    Jul 6, 2011 at 11:15
  • 3
    Not a good idea. VS becomes very sluggish when a solution contains more than a few projects.
    – nikie
    Jul 6, 2011 at 11:52
  • 4
    If your VS becomes too sluggish you're either running an old version or a slow computer. I have huge projects with 30+ projects that compiles in seconds. Then again I do have lots of ram, cores and a SSD :) You shouldn't exaggerate of course but only separate where appropriate, think about it like this "These classes belong together and doesn't need to know about these classes" and separate along those lines
    – Homde
    Jul 6, 2011 at 12:44
  • Marked this as answer because of the remark about dependencies. Ed James' answer is at least as valuable and correct, but this answer is more applicable to my situation.
    – Peter
    Jul 11, 2011 at 7:52
  • 2
    Following this approach you could end up with a bunch of assemblies: A,B,C,D,E,F,G,H,I,J,K. Wherever you reference assembly A, you must also reference its dependent assemblies: B,C,D. But assembly C is dependent on: E,F,G,H so we're going to need those too. So whenever you need some function of A you've got to pull down 7 additional assemblies to get it working; making sure you get the correct versions of each assembly. Welcome to the new DLL Hell.
    – Ed James
    Jul 11, 2011 at 13:48
14

An Assembly is the unit of deployment for a .NET application; therefore you should consider matching the cut of your assemblies with your deployment architecture.

Assemblies are also useful when you need separate version control on some code. For example, when you have common interfaces that would benefit from independent version control, you should separate that code into an assembly.

Remember that namespaces can span assemblies. In a lot of cases it is enough to separate behaviour using namespaces. Look at the .NET mscorlib.dll that in a single assembly contains code that covers a vast array of behaviours separated only by namespace.

If you want some authority on this subject, look no further than:

Framework Design Guidelines

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition) by Krzysztof Cwalina and Brad Abrams.

Improve this answer
2
  • Thanks for the book reference indeed. I'll check that out. Could you elaborate on the deployment architecture? How would deploying 10 DLL files differ from deploying 1? Unless you are able to update one of ten files, while the others remain untouched?
    – Peter
    Jul 7, 2011 at 6:47
  • 1
    @Peter: if you coded 10 assemblies that are always deployed together, then you could have simplified version control and deployment by putting all code into a single assembly. If the 10 assemblies are not always deployed together then having separate assemblies can be useful.
    – Ed James
    Jul 7, 2011 at 13:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.