Differences

This shows you the differences between two versions of the page.

Link to this comparison view

it:ad:patterns:many_assemblies_strategy [2019/03/24 12:02] (current)
Line 1: Line 1:
 +# IT:​AD:​Patterns:​Many Assemblies Strategy #
 +
 +
 +
 +<callout type="​Navigation"​ class="​small">​
 +* [[../​|(UP)]]
 +{{indexmenu>​.#​2|nsort tsort}}
 +
 +
 +</​callout>​
 +
 +
 +<panel title="​Summary">​
 +
 +A hallmark of modular, testable, maintainable code is the use of as multiple assemblies in the application -- as many as possible being reusable library code.
 +
 +
 +</​panel>​
 +
 +
 +### Pros and Cons ###
 +Spoiler Alert: there are no Cons:
 +
 +* Memory Use: If all your code is one assembly, whether you use it or not, you have it in memory. If broken down into multiple assemblies, it doesn'​t get loaded until needed.
 +* Speed: a common fallacy is that using multiple assemblies slows application startup. Total hogwash: the amount of time to read x Bytes of data from an HD is the same whether in one assembly, or several -- the only difference is the time for the head to seek the beginning of the new file. 50 assemblies * 8ms (average seek time for most HD's these days) = 400ms. Less than half a second. Cry me a river.
 +* Modularity: by refactoring an application'​s code into discrete assemblies, depending on the way you did it (ie refactored it into being generic, and not too tightly tied to the specifics of the app), you have a chance of reusing the logic in other applications later.
 +* Testability:​ better yet, small discrete refactored assemblies can be unit tested in isolation from the rest of the app.