How do you decide what assemblies to split your project into?

Question

What's the most important consideration when deciding how to partition your application into assemblies? Do some people just create one assembly per unique namespace (or perhaps per root namespace) for convenience? Or one per app-layer (like Presentation, Business/Services, Data)? Or more subtle perhaps, put the entire Model in one assembly? Does any of this really matter?

Does having too many assemblies slow things down, is there a critical mass or a "good" number of assemblies that an application should have? Likewise, is there a tipping point for when a single assembly is too big, and does a large assembly also affect performance?

I know it depends on the specific app of course - so I'm mainly interested in general guidelines, and what criteria to use when deciding.

Thanks!

---

(Although in my particular case, if anyone wants to comment on it, I'm building a WCF service with a business and DAL layer underneath, and a web site to consume the service. I've traditionally created lots of smaller assemblies, but now I'm thinking the simplicity of "Web", "Service", "Model" and maybe "Data" (for repositories etc) looks pretty appealing. Web references Service only, Service references Model only, and Model references Data only. Not sure how much it matters.)

Answer 1

To me, the main reasons why I would isolate some code into a dll are :

• Functionality sharing between several projects
• Easy delivery of new versions of this functionality without updating others
• Interface sharing between a client and a server for example

If you need one of those things, you should consider making a dll

On the downside, you get some tricky cyclical dependencies to solve (usually done using callbacks)

Answer 2

One per layer, one for any "top to bottom" app-specific things (like the model, probably) and one for "common utilities" seems reasonable to me. One benefit of splitting between layers is that then internal types and methods etc will only be visible within their layer, which can be a nice aid to encapsulation.

I've seen various applications with far too many projects - it becomes unwieldy very quickly, particularly when you then double up the projects with unit tests.

Answer 3

I tend to go for the one/layer which is vertical split, once the code base starts to grow I then look at splitting out horizontally, normally oriented around specific chunks of business functionality. For instance if my persistance layer is talking to > 20 or so tables, I'd be looking to split that down, knowing where to split is a bit of a black art, it's highly domain and project specific.

The rule of thumb I use is, what reasonable set of classes would I be likely to re-use elsewhere. Having just been through this process on my own code base, it's interesting how much other stuff then becomes clear candidates for re-factoring to base, abstract, or interface classes, and they in turn are pushed into a lower level generic assembly.