Information Technology Reference
In-Depth Information
Sure, you could reuse the source code and create different assemblies for
the client and server-side business rules, but that would complicate your
delivery mechanism. That leaves you with two builds and two installations
to perform when you update the rules. Instead, separate the client-side
validation from the more robust server-side validation by placing them in
different assemblies. You are reusing binary objects, packaged in assem-
blies, rather than reusing object code or source code by compiling those
objects into the multiple assemblies.
An assembly should contain an organized library of related functionality.
That's an easy platitude, but it's much harder to implement in practice.
The reality is that you might not know beforehand which classes will be
distributed to both the server and client portions of a distributed applica-
tion. Even more likely, the set of server- and client-side functionality will
be somewhat fluid; you'll move features between the two locations. By
keeping the assemblies small, you'll be more likely to redeploy more eas-
ily on both client and server. The assembly is a binary building block for
your application. That makes it easier to plug a new component into place
in a working application. If you make a mistake, make too many smaller
assemblies rather than too few large ones.
I often use Legos as an analogy for assemblies and binary components.
Yo u c a n p u l l o u t o n e L e g o a n d r e p l a c e i t e a s i l y ; i t ' s a s m a l l b l o c k . I n t h e
same way, you should be able to pull out one assembly and replace it with
another assembly that has the same interfaces. The rest of the application
should continue as if nothing happened. Follow the Lego analogy a little
farther. If all your parameters and return values are interfaces, any assem-
bly can be replaced by another that implements the same interfaces (see
Item 22).
Smaller assemblies also let you amortize the cost of application startup.
The larger an assembly is, the more work the CPU does to load the assem-
bly and convert the necessary IL into machine instructions. Only the rou-
tines called at startup are JITed, but the entire assembly gets loaded and the
CLR creates stubs for every method in the assembly.
Time to take a break and make sure we don't go to extremes. This item is
about making sure that you don't create single monolithic programs, but
that you build systems of binary, reusable components. You can take this
advice too far. Some costs are associated with a large program built on too
many small assemblies. You will incur a performance penalty when pro-
