Things to Consider When Designing .NET Applications

When working on designing and architecting a solution it is critical to consider that various functionalities, classes and interfaces, and so on should be part of one single chunky assembly or should be divided across multiple smaller assemblies.

The following are points to consider

• To help reduce your application's working set (in simple terms a set of memory pages required to host the application in the process), you should prefer single larger assemblies rather than multiple smaller assemblies. If you have several assemblies that are always loaded together, you should combine them and create a single assembly.
• Reasons to avoid multiple smaller assemblies:
  • Since you have multiple assemblies consider the cost required in loading metadata for multiple smaller assemblies.
  • JIT compile time will be much more depending on the count of assemblies.
  • Security checks are needed for multiple assemblies.
• At times, the project architecture demands splitting assemblies into multiple ones; for example, for versioning and deployment reasons. If you need to ship types separately, you may need separate assemblies. If you have a valid scenario(s) feel free to do so.

Code Refactoring by Logical Layers

You can read my article on Logical and Physical Separation here.

Code refactoring suggestions are the most common comments developers receive during their code review. Hence, we usually follow the best practices of Separation of Concerns, and so on.

Here are points to consider.

• The class's internal design needs to be considered to decide how you factor code into separate methods.
• Better code refactoring boosts up the ease of tuning to improve performance; simplify maintainability and adding new functionality.
• Like many things code refactoring needs a proper end where you stop further refactoring. In other words, clearly re-factored code improves maintainability but a developer needs to be cautious of over-abstraction and dividing functionality into many layers.
• Try to keep your application's design simple, effective, and efficient, as much as you can.

Threads are Resources Worth Sharing

Many applications use threads internally and behind the scenes, which works well and doesn't cause much noise. The problem starts when we take control of ourselves and don't follow the right practices.

Here are points to consider.

• Threads use both managed and unmanaged resources and are expensive to initialize. The following code shows a new thread is created and maintained for each request.

  private void Page_Load(object sender, System.EventArgs e)  
  {  
       if (Page.IsPostBack)  
       {  
            // Create and start a thread  
            ThreadStart newTS = new ThreadStart(CalFunc);  
            Thread th = new Thread(newTS);  
             newTS.Start();  
             ......  
  } 

• This may result in the processor spending most of its time performing thread switches; it also places increased pressure on the garbage collector to clean up resources.
• Use the CLR thread pool to execute thread-based work to avoid expensive thread initialization. The following code shows a method being executed using a thread from the thread pool.

  WaitCallback methodTarget = new WaitCallback(myClass.UpdateCache);
  ThreadPool.QueueUserWorkItem(methodTarget);
  

• When QueueUserWorkItem is called, the method is queued for execution, and the calling thread returns and continues execution. The ThreadPool class uses a thread from the application's pool to execute the method passed in the callback as soon as a thread is available.