How to partition your classes between assemblies

Eric Gunnerson has great post with some performance inspired assembly guidelines for fewer larger assemblies. Versioning and Security units of work. Good reasons.

But a non-performance reason for partitiioning into more assemblies is to stop developers from doing things like referencing your data access layer classes from a user interface layer (without going through a business object layer). If you have your classes in 3 assemblies/projects: UI, BUS and DA, where UI references BUS and BUS references DA, then it's hard for a class in UI to call a class in DA - without going out of their way to add a project reference.

Should a project always correspond to an assembly? Well that's the default but you can create intermediate assemblies called netmodules and link them together with the assembly linker (AL.exe). Net Modules are MSIL but without a manifest. You create the new assembly which links the modules together (and adds metadata) with the AL.exe.

The only problem with all of this is that you have to use the command line to compile your projects into .netmodules and link them afterwards. The net result however is that still end up satisfying Eric's performance tips with the requirement for binary partitioned UI, Business, and Data Access layers.