Information Technology Reference
In-Depth Information
gram flow crosses assembly boundaries. The CLR loader has a little more
work to do to load many assemblies and turn IL into machine instruc-
tions, particularly resolving function addresses.
Extra security checks also are done across assembly boundaries. All code
from the same assembly has the same level of trust (not necessarily the
same access rights, but the same trust level). The CLR performs some secu-
rity checks whenever code flow crosses an assembly boundary. The fewer
times your program flow crosses assembly boundaries, the more efficient
it will be.
None of these performance concerns should dissuade you from breaking
up assemblies that are too large. The performance penalties are minor. C#
and .NET were designed with components in mind, and the greater flexi-
bility is usually worth the price.
So how do you decide how much code or how many classes go in one
assembly? More important, how do you decide which code goes in an
assembly? It depends greatly on the specific application, so there is not one
answer. Here's my recommendation: Start by looking at all your public
classes. Combine public classes with common base classes into assemblies.
Then add the utility classes necessary to provide all the functionality asso-
ciated with the public classes in that same assembly. Package related pub-
lic interfaces into their own assemblies. As a final step, look for classes that
are used horizontally across your application. Those are candidates for a
broad-based utility assembly that contains your application's utility
library.
The end result is that you create a component with a single related set of
public classes and the utility classes necessary to support it. You create an
assembly that is small enough to get the benefits of easy updates and eas-
ier reuse, while still minimizing the costs associated with multiple assem-
blies. Well-designed, cohesive components can be described in one simple
sentence. For example, “Common.Storage.dll manages the offline data cache
and all user settings” describes a component with low cohesion. Instead,
make two components: “Common.Data.dll manages the offline data cache.
Common.Settings.dll manages user settings.” When you've split those up,
you might need a third component: “Common.EncryptedStorage.dll
manages file system IO for encrypted local storage.” You can update any
of those three components independently.
