it:ad:patterns:many_assemblies_strategy

IT:AD:Patterns:Many Assemblies Strategy

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.

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.
  • /home/skysigal/public_html/data/pages/it/ad/patterns/many_assemblies_strategy.txt
  • Last modified: 2023/11/04 03:28
  • by 127.0.0.1