CODEWITHSUNDEEP
.net
mathieu
mathieu

Reputation: 31192

What is better, many small assemblies, or one big assembly?

All is in the title :)

Currently, we have a VS2005 solution with 20+ projets. Like

MySolution
MySolution.Modules.Foo
MySolution.Modules.Bar
[insert many here]
MySolution.Modules.Baz

Can there be a harm to "merge" MySolution.Modules.* in one project ? All namespaces will be preserved, so no problem here.

But is there anything I didn't think about ?

Note : Currently, there can't be circular references : if MySolution.Modules.Foo references MySolution.Modules.Bar, MySolution.Modules.Bar can't reference MySolution.Modules.Foo. So we'll have to be careful not to create some.

Upvotes: 15

Views: 3762

Answers (5)

MikeJ
MikeJ

Reputation: 14565

We use ILMerge to bind up all our little assemblies into a larger block. Especially assemblies that are in different projects but are ultimately part of the same name space.

For example, we have a lot data entities for records and views spread over a number of assemblies, MJ.DE.views.dll, MJ.DE.tables.dll, MJ.DE.sprocs.dll etc. but in the end we use ILMerge to put bind them together into a single MJ.DE.DLL. - makes updating/synchronizing the app easier as there are fewer piecesto fiddle with on the production server and we know that all the related classes come from the same compile.

Upvotes: 5

Brian
Brian

Reputation: 118895

Advantages of one assembly:

  • potentially perf
  • potentially easier deployment

Advantages of many assemblies:

  • Everything else. Assuming these are good cohesive modules, it helps with separation of concerns, keeps dependencies in check by forcing you to think about levelling/layering of your architecture, etc.

Upvotes: 11

Lasse V. Karlsen
Lasse V. Karlsen

Reputation: 391604

For one thing, Visual Studio starts taking longer and longer to load your solution if you have tons of projects, as opposed to few projects with tons of code in them.

This is not necessarily a good enough reason to just have one project, over all the others mentioned here, but something to keep in mind.

Upvotes: 3

Kevin Babcock
Kevin Babcock

Reputation: 10247

Compile time. If you have your project broken into pieces, only the piece that was modified needs be compiled. If it's all part of one big project, you'll have to recompile everything any time you change something. Depending on how big your project is, this can be a big deal.

Upvotes: 3

Jon Skeet
Jon Skeet

Reputation: 1503140

I have been in a couple of companies where having far too many projects has been a pain in various ways. I haven't yet been anywhere which had too few projects, although that's certainly possible.

Think about a project as a unit of reuse, amongst other things. Is any product going to need Foo but not Bar, or vice versa? If not, merge them together.

I like to keep different layers (presentation, business logic, data access) apart, and it's nice to have a common, product-agnostic utility library, but that's about it in many cases.

Oh, and keep tests in a different project to your production code, of course :)

Upvotes: 15

Related Questions