How slow are Exceptions

I’ve seen from time to time applications that wrap a TRY – CATCH around some code, but do nothing except carry on.  So why is this so wrong?

As programmers we want to write quality code that solves problems. Unfortunately, exceptions come as side effects of our code. No one likes side effects, so we soon find our own ways to get around them. I have seen some smart programmers deal with exceptions the following way:

public void consumeAndForgetAllExceptions(){
    try {
        ...some code that throws exceptions
    } catch (Exception ex){
        ex.printStacktrace();
    }
}

What is wrong with the code above?

Once an exception is thrown, normal program execution is suspended and control is transferred to the catch block. The catch block catches the exception and just suppresses it. Execution of the program continues after the catch block, as if nothing had happened.

How about the following?

public void someMethod() 
 {
 throw new Exception();
 }

This method is a blank one; it does not have any code in it. How can a blank method throw exceptions? C# does not stop you from doing this. Recently, I came across similar code where the method was declared to throw exceptions, but there was no code that actually generated that exception. When I asked the programmer, he replied “I know, it is corrupting the API, but I am used to doing it and it works.”

This debate goes around in circles in the C# community. I have seen several C# programmers struggle with the use of exceptions. If not used correctly, exceptions can slow down your program, as it takes memory and CPU power to create, throw, and catch exceptions. If overused, they make the code difficult to read and frustrating for the programmers using the API. We all know frustrations lead to hacks and code smells. The client code may circumvent the issue by just ignoring exceptions or throwing them.

Let’s go back to basics and start with the definition of an Exception:

Exception handling is the process of responding to the occurrence, during computation, of exceptions – anomalous or exceptional conditions requiring special processing – often changing the normal flow of program execution. It is provided by specialized programming language constructs or computer hardware mechanisms.

The important words here I feel is special processing something which is out of your control.

Here is a simple example

 var a = 0;
 int b;
 try
 {
  b = 10 / a;
 }
 catch
 {
 }

So what is wrong with this?

I call it lazy and poormans programming, one correct solution to this could be:

 var a = 0;
 int b;
 if (a != 0)
  b = 10 / a;

Okay this is a very simple example of abusive Exception handling, but does it really matter?

I wrote a small benchmark test to see just what the difference is in performance.  Just a simple 10,000 parallel loop count running the same code over and over again.

I was quite overwhelmed with the performnce hit of the Exception handling, even just in this small example.  The Exception handling caused the code to slow down by over 600 times.

600 times slower code, well that does not matter if this is only happening once I hear you say…!

The performance is just one area, what about the extra memory that the exception is using.  With a few changes to the Benchmark application am able to monitor the Garbage Collector, which although it is not a true representation of how much memory is being used it will provide a very good gauge.

The results of the memory useage were quite staggering

  • 14,416 for the programming logic
  • 2,501,832 for the exception handing

Just another reason why this is not acceptable to use the exception handler in this way.

This is just a short article on Excpetion Handling, but it does frustrate me when I see Exception Handling  being abused.

ExceptionPerformance

Entity Framework Unit of Work Patterns

I’m not often shocked, but when I found out that Entity Framework was not thread safe, I was horrified.  I even had to buy a fellow college dinner as I lost a bet.

Now that I knew what the problem was how can it be resolved?

One area I recently took some time to research is how the Unit of Work pattern is best implemented within the context of using Entity Framework. While the topic is still relatively fresh on my mind, I thought I’d use this as an opportunity to create a catalog of various approaches I’ve encountered and include some thoughts about each approach.

Unit of Work

To start, it may be helpful to give a basic definition of the Unit of Work pattern. A Unit of Work can be defined as a collection of operations that succeed or fail as a single unit. Given a series of operations which need to be executed in response to some interaction with an application, it’s often necessary to ensure that none of the operations cause side-effects if any one of them fails. This is accomplished by having participating operations respond to either a commit or rollback message indicating whether the operation performed should be completed or reverted.

A Unit of Work can consist of different types of operations such as Web Service calls, Database operations, or even in-memory operations, however, the focus of this article will be on approaches to facilitating the Unit of Work pattern with the Entity Framework.

With that out of the way, let’s take a look at various approaches to facilitating the Unit of Work pattern with Entity Framework.

Implicit Transactions

The first approach to achieving a Unit of Work around a series of Entity Framework operations is to simply create an instance of a DbContext class, make changes to one or more DbSet instances, and then call SaveChanges() on the context. Entity Framework automatically creates an implicit transaction for changesets which include INSERTs, UPDATEs, and DELETEs.

Here’s an example:

public Customer CreateCustomer(CreateCustomerRequest request)
{
 Customer customer = null;

 using (var context = new MyStoreContext())
 {
 customer = new Customer { FirstName = request.FirstName, LastName = request.LastName };
 context.Customers.Add(customer);
 context.SaveChanges();
 return customer;
 }
}

The benefit of this approach is that a transaction is created only when necessary and is kept alive only for the duration of the SaveChanges() call. Some drawbacks to this approach, however, are that it leads to opaque dependencies and adds a bit of repetitive infrastructure code to each of your applications services.

If you prefer to work directly with Entity Framework then this approach may be fine for simple needs.

TransactionScope

Another approach is to use the System.Transactions.TransactionScope class provided by the .Net framework. When any of the Entity Framework operations are used which cause a connection to be opened (e.g. SaveChanges()), the connection will enlist in the ambient transaction defined by the TransactionScope class and close the transaction once the TransactionScope is successfully completed. Here’s an example of this approach:

public Customer CreateCustomer(CreateCustomerRequest request)
{
 Customer customer = null;

 using (var transaction = new TransactionScope())
 {
 using (var context = new MyStoreContext())
 {
 customer = new Customer { FirstName = request.FirstName, LastName = request.LastName };
 context.Customers.Add(customer);
 context.SaveChanges();
 transaction.Complete();
 }

 return customer;
 }
}

In general, you’ll find using TransactionScope to be a good general-purpose solution for defining a Unit of Work around Entity Framework operations as it works with ADO.Net, all versions of Entity Framework, and other ORMs which provides the ability to use multiple libraries if needed. Additionally, it provides a foundation for building a more comprehensive Unit of Work pattern which would allow other types of operations to enlist in the Unit of Work.

Caution should be exercised when using TransactionScope, however, as certain operations can implicitly escalate the transaction to a distributed transaction causing undesired overhead. For those choosing solutions involving TransactionScope, I would recommend educating yourself on how and when transactions are escalated.

While you’ll find using the TransactionScope class to be a good general-purpose solution, using it directly does couple your services to a specific strategy and adds a bit of noise to your code.

ADO.Net Transactions

This approach involves creating an instance of DbTransaction and instructing the participating DbContext instance to use the existing transaction:

public Customer CreateCustomer(CreateCustomerRequest request)
{
 Customer customer = null;

 var connectionString = ConfigurationManager.ConnectionStrings["MyStoreContext"].ConnectionString;
 using (var connection = new SqlConnection(connectionString))
 {
 connection.Open();
 using (var transaction = connection.BeginTransaction())
 {
 using (var context = new MyStoreContext(connection))
 {
 context.Database.UseTransaction(transaction);
 try
 {
 customer = new Customer { FirstName = request.FirstName, LastName = request.LastName };
 context.Customers.Add(customer);
 context.SaveChanges();
 }
 catch (Exception e)
 {
 transaction.Rollback();
 throw;
 }
 }

 transaction.Commit();
 return customer;
 }
 }

As can be seen from the example, this approach adds quite a bit of infrastructure noise to your code. While not something I’d recommend standardizing upon, this approach provides another avenue for sharing transactions between Entity Framework and straight ADO.Net code which might prove useful in certain situations. In general, I wouldn’t recommend such an approach.

Entity Framework Transactions

The relative new-comer to the mix is the new transaction API introduced with Entity Framework 6. Here’s a basic example of it’s use:

public Customer CreateCustomer(CreateCustomerRequest request)
{
 Customer customer = null;

 using (var context = new MyStoreContext())
 {
 using (var transaction = context.Database.BeginTransaction())
 {
 try
 {
 customer = new Customer { FirstName = request.FirstName, LastName = request.LastName };
 context.Customers.Add(customer);
 context.SaveChanges();
 transaction.Commit();
 }
 catch (Exception e)
 {
 transaction.Rollback();
 throw;
 }
 }
 }

 return customer;
}

This is the approach recommended by Microsoft for achieving transactions with Entity Framework going forward. If you’re deploying applications with Entity Framework 6 and beyond, this will be your safest choice for Unit of Work implementations which only require database operation participation. Similar to a couple of the previous approaches we’ve already considered, the drawbacks of using this directly are that it creates opaque dependencies and adds repetitive infrastructure code to all of your application services. This is also a viable option, but I would recommend coupling this with other approaches we’ll look at later to improve the readability and maintainability of your application services.

Unit of Work Repository Manager

The first approach I encountered when researching how others were facilitating the Unit of Work pattern with Entity Framework was a strategy set forth by Microsoft’s guidance on the topic here. This strategy involves creating a UnitOfWork class which encapsulates an instance of the DbContext and exposes each repository as a property. Clients of repositories take a dependency upon an instance of UnitOfWork and access each repository as needed through properties on the UnitOfWork instance. The UnitOfWork type exposes a SaveChanges() method to be used when all the changes made through the repositories are to be persisted to the database. Here is an example of this approach:

public interface IUnitOfWork
{
 ICustomerRepository CustomerRepository { get; }
 IOrderRepository OrderRepository { get; }
 void Save();
}

public class UnitOfWork : IDisposable, IUnitOfWork
{
 readonly MyContext _context = new MyContext();
 ICustomerRepository _customerRepository;
 IOrderRepository _orderRepository;

 public ICustomerRepository CustomerRepository
 {
 get { return _customerRepository ?? (_customerRepository = new CustomerRepository(_context)); }
 }

 public IOrderRepository OrderRepository
 {
 get { return _orderRepository ?? (_orderRepository = new OrderRepository(_context)); }
 }

 public void Dispose()
 {
 if (_context != null)
 {
 _context.Dispose();
 }
 }

 public void Save()
 {
 _context.SaveChanges();
 }
}

public class CustomerService : ICustomerService
{
 readonly IUnitOfWork _unitOfWork;

 public CustomerService(IUnitOfWork unitOfWork)
 {
 _unitOfWork = unitOfWork;
 }

 public void CreateCustomer(CreateCustomerRequest request)
 {
 customer = new Customer { FirstName = request.FirstName, LastName = request.LastName };
 _unitOfWork.CustomerRepository.Add(customer);
 _unitOfWork.Save();
 }
}

It isn’t hard to imagine how this approach was conceived given it closely mirrors the typical implementation of the DbContext instance you find in Entity Framework guidance where public instances of DbSet are exposed for each aggregate root. Given this pattern is presented on the ASP.Net website and comes up as one of the first results when doing a search for “Entity Framework” and “Unit of Work”, I imagine this approach has gained some popularity among .Net developers. There are, however, a number of issues I have with this approach.

First, this approach leads to opaque dependencies. Due to the fact that classes interact with repositories through the UnitOfWork instance, the client interface doesn’t clearly express the inherent business-level collaborators it depends upon (i.e. any aggregate root collections).

Second, this violates the Open/Closed Principle. To add new aggregate roots to the system requires modifying the UnitOfWork each time.

Third, this violates the Single Responsibility Principle. The single responsibility of a Unit of Work implementation should be to encapsulate the behavior necessary to commit or rollback an set of operations atomically. The instantiation and management of repositories or any other component which may wish to enlist in a unit of work is a separate concern.

Lastly, this results in a nominal abstraction which is semantically coupled with Entity Framework. The example code for this approach sets forth an interface to the UnitOfWork implementation which isn’t the approach used in the aforementioned Microsoft article. Whether you take a dependency upon the interface or the implementation directly, however, the presumption of such an abstraction is to decouple the application from using Entity Framework directly. While such an abstraction might provide some benefits, it reflects Entity Framework usage semantics and as such doesn’t really decouple you from the particular persistence technology you’re using. While you could use this approach with another ORM (e.g. NHibernate), this approach is more of a reflection of Entity Framework operations (e.g. it’s flushing model) and usage patterns. As such, you probably wouldn’t arrive at this same abstraction were you to have started by defining the abstraction in terms of the behavior required by your application prior to choosing a specific ORM (i.e. following The Dependency Inversion Principle). You might even find yourself violating the Liskof Substitution Principle if you actually attempted to provide an alternate ORM implementation. Given these issues, I would advise people to avoid this approach.

Injected Unit of Work and Repositories

For those inclined to make all dependencies transparent while maintaining an abstraction from Entity Framework, the next strategy may seem the natural next step. This strategy involves creating an abstraction around the call to DbContext.SaveChanges() and requires sharing a single instance of DbContext among all the components whose operations need to participate within the underlying SaveChanges() call as a single transaction.

Here is an example:

public class CustomerService : ICustomerService
{
  readonly IUnitOfWork _unitOfWork;
  readonly ICustomerRepository _customerRepository;

  public CustomerService(IUnitOfWork unitOfWork, ICustomerRepository customerRepository)
  {
    _unitOfWork = unitOfWork;
    _customerRepository = customerRepository;
  }

  public void CreateCustomer(CreateCustomerRequest request)
  {
    customer = new Customer { FirstName = request.FirstName, LastName = request.LastName };
    _customerRepository.Add(customer);
    _unitOfWork.Save();
  }
}

This approach shares many of the same issues with the previous one. While it reduces a bit of infrastructure noise, it’s still semantically coupled to Entity Framework’s approach and still lacks a defined Unit of Work boundary. Additionally, it lacks clarity as to what happens when you call the SaveChanges() method. Given the Repository pattern is intended to be a virtual collection of all the entities within your system of a given type, one might suppose a method named “SaveChanges” means that you are somehow persisting any changes made to the particular entities represented by the repository (setting aside the fact that doing so is really a subversion of the pattern’s purpose). On the contrary, it really means “save all the changes made to any entities tracked by the underlying DbContext”. I would also recommend avoiding this approach.

Unit of Work Per Request

A pattern I’m a bit embarrassed to admit has been characteristic of many projects I’ve worked on in the past (though not with EF) is to create a Unit of Work implementation which is scoped to a Web Application’s Request lifetime. Using this approach, whatever method is used to facilitate a Unit of Work is configured with a DI container using a Per-HttpRequest lifetime scope and the Unit of Work boundary is opened by the first component being injected by the UnitOfWork and committed/rolled-back when the HttpRequest is disposed by the container.

There are a few different manifestations of this approach depending upon the particular framework and strategy you’re using, but here’s a pseudo-code example of how configuring this might look for Entity Framework with the Autofac DI container:

builder.RegisterType()
 .As()
 .InstancePerRequest()
 .OnActivating(x =>
 {
 // start a transaction
 })
 .OnRelease(context =>
 {
 try
 {
 // commit or rollback the transaction
 }
 catch (Exception e)
 {
 // log the exception
 throw;
 }
 });

public class SomeService : ISomeService
{
 public void DoSomething()
 {
 // do some work
 }
}

While this approach eliminates the need for your services to be concerned with the Unit of Work infrastructure, the biggest issue with this is when an error happens to occur. When the application can’t successfully commit a transaction for whatever reason, the rollback occurs AFTER you’ve typically relinquished control of the request (e.g. You’ve already returned results from a controller). When this occurs, you may end up telling your customer that something happened when it actually didn’t and your client state may end up out of sync with the actual persisted state of the application.

While I used this strategy without incident for some time with NHibernate, I eventually ran into a problem and concluded that the concern of transaction boundary management inherently belongs to the application-level entry point for a particular interaction with the system. This is another approach I’d recommend avoiding.

Instantiated Unit of Work

The next strategy involves instantiating a UnitOfWork implemented using either the .Net framework TransactionScope class or the transaction API introduced by Entity Framework 6 to define a transaction boundary within the application service. Here’s an example:

public class CustomerService : ICustomerService
{
  readonly ICustomerRepository _customerRepository;

  public CustomerService(ICustomerRepository customerRepository)
  {
    _customerRepository = customerRepository;
  }

  public void CreateCustomer(CreateCustomerRequest request)
  {
    using (var unitOfWork = new UnitOfWork())
    {
      try
      {
        customer = new Customer { FirstName = request.FirstName, LastName = request.LastName };
        _customerRepository.Add(customer);        
        unitOfWork.Commit();
      }
      catch (Exception ex)
      {
        unitOfWork.Rollback();
      }
    }
  }
}

Functionally, this is a viable approach to facilitating a Unit of Work boundary with Entity Framework. A few drawbacks, however, are that the dependency upon the Unit Of Work implementation is opaque and that it’s coupled to a specific implementation. While this isn’t a terrible approach, I would recommend other approaches discussed here which either surface any dependencies being taken on the Unit of Work infrastructure or invert the concerns of transaction management completely.

Injected Unit of Work Factory

This strategy is similar to the one presented in the Instantiated Unit of Work example, but makes its dependence upon the Unit of Work infrastructure transparent and provides a point of abstraction which allows for an alternate implementation to be provided by the factory:

public class CustomerService : ICustomerService
{
 readonly ICustomerRepository _customerRepository;
 readonly IUnitOfWorkFactory _unitOfWorkFactory;

 public CustomerService(IUnitOfWorkFactory unitOfWorkFactory, ICustomerRepository customerRepository)
 {
 _customerRepository = customerRepository;
 _unitOfWorkFactory = unitOfWorkFactory;
 }

 public void CreateCustomer(CreateCustomerRequest request)
 {
 using (var unitOfWork = _unitOfWorkFactory.Create())
 {
 try
 {
 customer = new Customer { FirstName = request.FirstName, LastName = request.LastName };
 _customerRepository.Add(customer);
 unitOfWork.Commit();
 }
 catch (Exception ex)
 {
 unitOfWork.Rollback();
 }
 }
 }
}

While I personally prefer to invert such concerns, I consider this to be a sound approach.

As a side note, if you decide to use this approach, you might also consider utilizing your DI Container to just inject a Func to avoid the overhead of maintaining an IUnitOfWorkFactory abstraction and implementation.

Unit of Work ActionFilterAttribute

For those who prefer to invert the Unit of Work concerns as I do, the following approach provides an easy to implement solution for those using ASP.Net MVC and/or Web API. This technique involves creating a custom Action filter which can be used to control the boundary of a Unit of Work at the Controller action level. The particular implementation may vary, but here’s a general template:

public class UnitOfWorkFilter : ActionFilterAttribute
{
 public override void OnActionExecuting(ActionExecutingContext filterContext)
 {
 // begin transaction
 }

 public override void OnActionExecuted(ActionExecutedContext filterContext)
 {
 // commit/rollback transaction
 }
}

The benefits of this approach are that it’s easy to implement and that it eliminates the need for introducing repetitive infrastructure code into your application services. This attribute can be registered with the global action filters, or for the more discriminant, only placed on actions resulting in state changes to the database. Overall, this would be my recommended approach for Web applications. It’s easy to implement, simple, and keeps your code clean.

Unit of Work Decorator

A similar approach to the use of a custom ActionFilterAttribute is the creation of a custom decorator. This approach can be accomplished by utilizing a DI container to automatically decorate specific application service interfaces with a class which implements a Unit of Work boundary.

Here is a pseudo-code example of how configuring this might look for Entity Framework with the Autofac DI container which presumes that some form of command/command-handler pattern is being utilized (e.g. frameworks like MediatR , ShortBus, etc.):

// DI Registration
builder.RegisterGenericDecorator(
 typeof(TransactionRequestHandler<>), // the decorator instance
 typeof(IRequestHandler<>), // the types to decorate
 "requestHandler", // the name of the key to decorate
 null); // the name of the key to this decorator



public class TransactionRequestHandler : IRequestHandler where TResponse : ApplicationResponse
{
 readonly DbContext _context;
 readonly IRequestHandler _decorated;

 public TransactionRequestHandler(IRequestHandler decorated, DbContext context)
 {
 _decorated = decorated;
 _context = context;
 }

 public TResponse Handle(TRequest request)
 {
 TResponse response;

 // Open transaction here

 try
 {
 response = _decorated.Handle(request);

 // commit transaction

 }
 catch (Exception e)
 {
 //rollback transaction
 throw;
 }

 return response;
 }
}


public class SomeRequestHandler : IRequestHandler
{
 public ApplicationResponse Handle()
 {
 // do some work
 return new SuccessResponse();
 }
}

While this approach requires a bit of setup, it provides an alternate means of facilitating the Unit of Work pattern through a decorator which can be used by other consumers of the application layer aside from just ASP.Net (i.e. Windows services, CLI, etc.) It also provides the ability to move the Unit of Work boundary closer to the point of need for those who would rather provide any error handling prior to returning control to the application service client (e.g. the Controller actions) as well as giving more control over the types of operations decorated (e.g. IQueryHandler vs. ICommandHandler). For Web applications, I’d recommend trying the custom Action Filter approach first, as it’s easier to implement and doesn’t presume upon the design of your application layer, but this is certainly a good approach if it fits your needs.

Conclusion

Out of the approaches I’ve evaluated, there are several that I see as sound approaches which maintain some minimum adherence to good design practices. Of course, which approach is best for your application will be dependent upon the context of what you’re doing and to some extent the design values of your team.

Orginal Post

Decorator Pattern

Decorator pattern falls under Structural Pattern of Gang of Four (GOF) Design Patterns in .Net. Decorator pattern is used to add new functionality to an existing object without changing its structure. Hence Decorator pattern provides an alternative way to inheritance for modifying the behavior of an object. In this article, I would like to go over what the decorator pattern can do, and how it works.

There are some occasions in our applications when we need to create an object with some basic functionality in such a way that some extra functionality can be added to this object dynamically. For example, Lets say we need to create a Stream object to handle some data but in some cases we need this stream object to be able to encrypt the stream in some cases. So what we can do is that we can have the basic Stream object ready and then dynamically add the encryption functionality when it is needed.

One may also say that why not keep this encryption logic in the stream class itself and turn it on or off by using a Boolean property. But this approach will have problems like – How can we add the type custom encryption logic inside a class? Now this can be done easily by subclassing the existing class and have custom encryption logic in the derived class.

This is a valid solution but only when this encryption is the only functionality needed with this class. But what if there are multiple functionalities that could be added dynamically to this class and also the combination of functionalities too. If we use the subclassing approach then we will end up with derievd classes equal to the number of combination we could have for all our functionalities and the actual object.

This is exactly the scenario where the decorator patter can be useful.  Decorators provide a flexible alternative to subclassing for extending functionality.”

Before looking into the details of decorator pattern let us go ahead, let’s have a look at what this pattern is and then see the class diagram of this pattern and see what each class is responsible for.

What is Decorator Pattern

Decorator pattern is used to add new functionality to an existing object without changing its structure.

This pattern creates a decorator class which wraps the original class and add new behaviors/operations to an object at run-time.

Still none the wiser?  Let’s look at a diagram to help you picture the pattern.

Decorator Pattern – UML Diagram & Implementation

The UML class diagram for the implementation of the decorator design pattern is given below:

The classes, interfaces and objects in the above UML class diagram are as follows:

Component

This is an interface containing members that will be implemented by ConcreteClass and Decorator.

ConcreteComponent

This is a class which implements the Component interface.

Decorator

This is an abstract class which implements the Component interface and contains the reference to a Component instance. This class also acts as base class for all decorators for components.

ConcreteDecorator

This is a class which inherits from Decorator class and provides a decorator for components.

C# – Implementation Code

public interface Component
{
 void Operation();
}
 
public class ConcreteComponent : Component
{
 public void Operation()
 {
 Console.WriteLine("Component Operation");
 }
}
 
public abstract class Decorator : Component
{
 private Component _component;
 
 public Decorator(Component component)
 {
 _component = component;
 }
 
 public virtual void Operation()
 {
 _component.Operation();
 }
}
 
public class ConcreteDecorator : Decorator
{
 public ConcreteDecorator(Component component) : base(component) { }
 
 public override void Operation()
 {
 base.Operation();
 Console.WriteLine("Override Decorator Operation");
 }
}

Decorator Pattern – Example

Who is what?

The classes, interfaces and objects in the above class diagram can be identified as follows:

  • Vehicle – Component Interface.
  • HondaCity- ConcreteComponent class.
  • VehicleDecorator- Decorator Class.
  • Special Offer- ConcreteDecorator class.

C# – Sample Code

/// <summary>
/// The 'Component' interface
/// </summary>
public interface Vehicle
{
 string Make { get; }
 string Model { get; }
 double Price { get; }
}
 
/// <summary>
/// The 'ConcreteComponent' class
/// </summary>
public class HondaCity : Vehicle
{
 public string Make
 {
 get { return "HondaCity"; }
 }
 
 public string Model
 {
 get { return "CNG"; }
 }
 
 public double Price
 {
 get { return 1000000; }
 }
}
 
/// <summary>
/// The 'Decorator' abstract class
/// </summary>
public abstract class VehicleDecorator : Vehicle
{
 private Vehicle _vehicle;
 
 public VehicleDecorator(Vehicle vehicle)
 {
 _vehicle = vehicle;
 }
 
 public string Make
 {
 get { return _vehicle.Make; }
 }
 
 public string Model
 {
 get { return _vehicle.Model; }
 }
 
 public double Price
 {
 get { return _vehicle.Price; }
 }
 
}
 
/// <summary>
/// The 'ConcreteDecorator' class
/// </summary>
public class SpecialOffer : VehicleDecorator
{
 public SpecialOffer(Vehicle vehicle) : base(vehicle) { }
 
 public int DiscountPercentage { get; set; }
 public string Offer { get; set; }
 
 public new double Price
 {
 get
 {
 double price = base.Price;
 int percentage = 100 - DiscountPercentage;
 return Math.Round((price * percentage) / 100, 2);
 }
 }
 
}
 
/// <summary>
/// Decorator Pattern Demo
/// </summary>
class Program
{
 static void Main(string[] args)
 {
 // Basic vehicle
 HondaCity car = new HondaCity();
 
 Console.WriteLine("Honda City base price are : {0}", car.Price);
 
 // Special offer
 SpecialOffer offer = new SpecialOffer(car);
 offer.DiscountPercentage = 25;
 offer.Offer = "25 % discount";
 
 Console.WriteLine("{1} @ Diwali Special Offer and price are : {0} ", offer.Price, offer.Offer);
 
 Console.ReadKey();
 
 }
}

Decorator Pattern Demo – Output

When to use it?

Add additional state or behavior to an object dynamically.

Make changes to some objects in a class without affecting others.

Original Article by Shailendra Chauhan

Here is a sample application Decorator Pattern

Kendo Grid custom sort order

I’ve been racking my brains as the sorting on the Kendo Grid is pretty good, only that I need to be able to not sort in the order that is being displayed.  An example would be numbers written out in full and you want them in number sort order.

@(Html.Kendo().Grid<Number>()
 .Name("grid")
 .Columns(columns =>
 {
 columns.Bound(c => c.Id);
 columns.Bound(c => c.Item);
 })
 .Sortable()
 .DataSource(dataSource => dataSource
 .Ajax()
 .Read(read => read.Action("Numbers_Read", "Home"))
 )
)


Here is the list not in any order, but it does have a sortorder column

 private static List<Number> GetNumbers()
 {
 List<Number> numbers = new List<Number>();

 numbers.Add(new Number() { Id = 1, Item = "one", SortOrder = "1" });

 numbers.Add(new Number() { Id = 2, Item = "three", SortOrder = "3" });

 numbers.Add(new Number() { Id = 3, Item = "six", SortOrder = "6" });
 numbers.Add(new Number() { Id = 4, Item = "two", SortOrder = "2" });
 numbers.Add(new Number() { Id = 5, Item = "five", SortOrder = "5" });
 numbers.Add(new Number() { Id = 6, Item = "seven", SortOrder = "7" });
 numbers.Add(new Number() { Id = 7, Item = "four", SortOrder = "4" });
 return numbers;
 }

and now for the magic, when the request is coming back into the controller action we check to see what is being requested and then change it to another hidden column, this way it retains all the functionality of the Kendo Grid and it just works….!

public ActionResult Numbers_Read([DataSourceRequest]DataSourceRequest request)
 {
 List<Number> numbers = GetNumbers();

 foreach (var sort in request.Sorts)
 {
 // Find the sort member you need a custom sort for and change it to the custom column 
 if (sort.Member.ToLowerInvariant() == "item")
 {
 sort.Member = "SortOrder";
 }
 }
 return Json(numbers.ToDataSourceResult(request), JsonRequestBehavior.AllowGet);
 }

I have created this sample Kendo Grid project so you can see how it is all done.

kendo_grid

Code Metrics what do they mean?

 

Code metrics is a set of software measures that provide developers better insight into the code they are developing. By taking advantage of code metrics, developers can understand which types and/or methods should be reworked or more thoroughly tested.

What is the preferred score range for the code metrics calculation for the following

  • Maintainability Index
  • Cyclomatic Complexity
  • Depth of Inheritance
  • class Coupling

The theoretically optimal values are:

  • Maintainability index: 100. Higher values indicate better maintainability.
  • Cyclomatic complexity: 1. The number of different paths that code can take.
  • Depth of inheritance: 1. The number of class definitions above this one in the inheritance tree, not including interfaces.
  • Class coupling: 0. Number of other entities this entity is dependent on.

There are no hard and fast “good” ranges, though it’s possible to make some general statements.

  • Having high per-method cyclomatic complexity suggests a method is getting too complicated.
  • Having an inheritance depth more than about 3 or 4 (of your own classes, not the framework’s) is a trouble sign that you may be unnecessarily representing abstract relationships that aren’t really in your software’s domain.
  • Low class coupling is in general better, but sometimes it’s unavoidable. To the extent possible, you should definitely minimise the dependency between namespaces, since there’s much less reason for dependencies here.

A project could only reach all four values simultaneously by essentially doing nothing and being useless: software that does nothing and depends on nothing is certainly maintainable, but not a very good use of client dollars.

Therefore, all complexity is a trade-off: additional so-called inherent complexity encodes more sophistication into the program, allowing it to expand the feature set. What you would like to avoid is accidental complexity introduced by a poor or deficient implementation.

IoC Benchmark

So which is the fastest at different IoC Lifestyles.

In this benchmark we will be running, head to had, with Castle Windsor, Ninject, Spring.NET, Unity, Microsoft DI, AutoFac, and Structure Map.

Here is a working project, this uses NuGet to included the packages, so as time goes on you may find the packages go out of date, so you’ll need to refactor the code to work with the next packages.

I’m using a Parallel test as this represents a closer real life example of how the containers will be used.

ioc-benchmark

 

Factory Support Facility

Factory Support Facility allows using factories to create components. This is beneficial when you want to make available as services components that do not have accessible constructor, or that you don’t instantiate, like HttpContext.

Prefer UsingFactoryMethod over this facility: while the facility provides programmatic API it is deprecated and its usage is discouraged and won’t be discussed here. Recommended approach is to use UsingFactoryMethod method of fluent registration API to create components. This limits the usefulness of the facility to XML-driven and legacy scenarios.

UsingFactoryMethod does not require this facility anymore: In older versions of Windsor (up to and including version 2.1) UsingFactoryMethod method in the fluent API discussed above required this facility to be active in the container. That was later changed and there’s no such dependency anymore.

Using factories from configuration

In addition to code, the facility uses XML configuration. You can register the facility in the standard facilities section of Windsor’s config:

Just install the facility and add the proper configuration.

<configuration>
 <facilities>
   <facility
     id="factory.support"
     type="Castle.Facilities.FactorySupport.FactorySupportFacility, 
           Castle.Facilities.FactorySupport" />
  </facilities>
</configuration>

Configuration Schema

Broadly speaking facility exposes the following scheme, with two kinds of supported factories: accessors and methods

<components>
 <component id="mycomp1" instance-accessor="Static accessor name" />
 <component id="factory1" />
 <component id="mycomp2" factoryId="factory1" factoryCreate="Create" />
</components>

Accessor example

Given the following singleton class:

public class SingletonWithAccessor
{
 private static readonly SingletonWithAccessor instance = new SingletonWithAccessor();

private SingletonWithAccessor()
 {
 }

public static SingletonWithAccessor Instance
 {
 get { return instance; }
 }
}

You may expose its instance to the container through the following configuration:

<components>
 <component id="mycomp1"
 type="Company.Components.SingletonWithAccessor, Company.Components"
 instance-accessor="Instance" />
</components>

Using it:

var comp = container.Resolve<SingletonWithAccessor>("mycomp1");

Factory example

Given the following component and factory classes:

public class MyComp
{
 internal MyComp()
 {
 }

...
}

public class MyCompFactory
{
 public MyComp Create()
 {
 return new MyComp();
 }
}

You may expose its instance to the container through the following configuration:

<components>
 <component id="mycompfactory"
 type="Company.Components.MyCompFactory, Company.Components"/>
 <component id="mycomp"
 type="Company.Components.MyComp, Company.Components"
 factoryId="mycompfactory" factoryCreate="Create" />
</components>

Using it:

var comp = container.Resolve<MyComp>("mycomp");

Factory with parameters example

Given the following component and factory classes:

public class MyComp
{
 internal MyComp(String storeName, IDictionary props)
 {
 }

...
}

public class MyCompFactory
{
 public MyComp Create(String storeName, IDictionary props)
 {
 return new MyComp(storeName, props);
 }
}

You may expose its instance to the container through the following configuration:

<components>
 <component id="mycompfactory"
 type="Company.Components.MyCompFactory, Company.Components"/>
 <component id="mycomp"
 type="Company.Components.MyComp, Company.Components"
 factoryId="mycompfactory" factoryCreate="Create">
 <parameters>
 <storeName>MyStore</storeName>
 <props>
 <dictionary>
 <entry key="key1">item1</entry>
 <entry key="key2">item2</entry>
 </dictionary>
 </props>
 </parameters>
 </component>
</components>

Using it:

var comp = container.Resolve<MyComp>("mycomp");

Factory using auto-wire example

If your factory request as parameter some other component instance, this facility will be able to resolve it without your aid:

public class MyComp
{
 internal MyComp(IMyService serv)
 {
 }

...
}

public class MyCompFactory
{
 public MyComp Create(IMyService service)
 {
 return new MyComp(service);
 }
}

You may expose its instance to the container through the following configuration:

<facilities>
 <facility
 id="factorysupport"
 type="Castle.Facilities.FactorySupport.FactorySupportFacility, Castle.Facilities.FactorySupport"/>
</facilities>

<components>
 <component id="myservice"
 service="SomethingElse.IMyService"
 type="Company.Components.MyServiceImpl, Company.Components" />
 <component id="mycompfactory"
 type="Company.Components.MyCompFactory, Company.Components" />
 <component id="mycomp"
 type="Company.Components.MyComp, Company.Components"
 factoryId="mycompfactory" factoryCreate="Create" />
</components>

Using it:

var comp = container.Resolve<MyComp>("mycomp");

 

Registering components for IoC

Inversion of Control (IoC) is quite a big step for some developers, but the benefits once implemented are huge.  With the applications performance, maintainability, unit testing and more importantly separation of concerns, just to name a few.

Due to the nature and the new concept of IoC to many of the developers, I would strongly recommend that you take some time to go over these two PluralSight course that go into IoC in a lot more detail that we can cover here.   There are other courses that also cover IoC available on PluralSights, but these are the two I would recommend.
Inversion of Control – by John Sonmez
A comprehensive look at inversion of control and how to use common IoC containers
Practical IoC With ASP.NET MVC 4 – by John Sonmez
In this course, we’ll learn how to use an IoC container, like Unity in an ASP.NET MVC 4 application and some of the basics of the practical application of IoC containers.

Basic Registration

The starting point for registering anything in the container is the container’s Register method, with has one or more IRegistration objects as parameter. The simplest way to create those objects is using the static Castle.MicroKernel.Registration.Component class. Its For method returns a ComponentRegistration that you can use to further configure the registration.

Isolate your registration code: It is a recommended practice to keep your registration code in a dedicated class(es) implementing IWindsorInstaller.

Install infrastructure components first: Some components may require a facility or other extension to the core container to be registered properly. As such it is recommended that you always register your facilities, custom subsystems, Component model creation contributors etc before you start registering your components.

To register a type in the container

container.Register(
	Component.For(MyServiceImpl) );

This will register type MyServiceImpl as service MyServiceImpl with default lifestyle (Singleton).

To register a type as non-default service

container.Register(
    Component.For(IMyService).ImplementedBy(MyServiceImpl));

Note that For and ImplementedBy also have non-generic overloads.

// Same result as example above.
container.Register(Component.For(typeof(IMyService))
    .ImplementedBy(typeof(MyServiceImpl))
);

Services and Components: You can find more information about services and components here.

To register a generic type

Suppose you have a IRepository<TEntity> interface, with NHRepository<TEntity> as the implementation.

You could register a repository for each entity class, but this is not needed.

// Registering a repository for each entity is not needed.
container.Register(
    Component.For<IRepository<Customer>>()
        .ImplementedBy<NHRepository<Customer>>(),
    Component.For<IRepository<Order>>()
        .ImplementedBy<NHRepository<Order>>(),
//    and so on...
);


One IRepository<> (so called open generic type) registration, without specifying the entity, is enough.

// Does not work (compiler won't allow it):
 container.Register(
     Component.For<IRepository<>>()
         .ImplementedBy<NHRepository<>>()
 );

Doing it like this however is not legal, and the above code would not compile. Instead you have to use typeof()

// Use typeof() and do not specify the entity:
container.Register(
     Component.For(typeof(IRepository<>))
         .ImplementedBy(typeof(NHRepository<>))
);

Configuring component’s lifestyle

container.Register(
 Component.For<IMyService>()
 .ImplementedBy<MyServiceImpl>()
 .LifeStyle.Transient
);

When the lifestyle is not set explicitly, the default Singleton lifestyle will be used.

Register more components for the same service

You can do this simply by having more registrations for the same service.

container.Register(
    Component.For<IMyService>().ImplementedBy<MyServiceImpl>(),
    Component.For<IMyService>().ImplementedBy<OtherServiceImpl>()
);

When a component has a dependency on IMyService, it will by default get the IMyService that was registered first (in this case MyServiceImpl).

In Windsor first one wins: In Castle, the default implementation for a service is the first registered implementation.

You can force the later-registered component to become the default instance via the method IsDefault.

container.Register(
    Component.For<IMyService>().ImplementedBy<MyServiceImpl>(),
    Component.For<IMyService>().Named("OtherServiceImpl")
        .ImplementedBy<OtherServiceImpl>().IsDefault()
);

In the above example, any component that has a dependency on IMyService, will by default get an instance of OtherServiceImpl, even though it was registered later.

Of course, you can override which implementation is used by a component that needs it. This is done with service overrides.

When you explicitly call container.Resolve<IMyService>() (without specifying the name), the container will also return the first registered component for IMyService (MyServiceImpl in the above example).

Provide unique names for duplicated components: If you want to register the same implementation more than once, be sure to provide different names for the registered components.

Using a delegate as component factory

You can use a delegate as a lightweight factory for a component:

container.Register(
    Component.For<IMyService>()
        .UsingFactoryMethod(
            () => MyLegacyServiceFactory.CreateMyService())
);

UsingFactoryMethod method has two more overloads, which can provide you with access to kernel, and creation context if needed.

Example of UsingFactoryMethod with kernel overload (Converter)

container.Register(
    Component.For<IMyFactory>().ImplementedBy<MyFactory>(),
        Component.For<IMyService>()
            .UsingFactoryMethod(kernel => kernel.Resolve<IMyFactory>().Create())
);

In addition to UsingFactoryMethod method, there’s a UsingFactory method. (without the “method” suffix 🙂 ). It can be regarded as a special version of UsingFactoryMethod method, which resolves an existing factory from the container, and lets you use it to create instance of your service.

container.Register(
    Component.For<User>().Instance(user),
         Component.For<AbstractCarProviderFactory>(),
         Component.For<ICarProvider>()
             .UsingFactory((AbstractCarProviderFactory f) =>
                f.Create(container.Resolve<User>()))
);

Avoid UsingFactory: It is advised to use UsingFactoryMethod, and to avoid UsingFactory when creating your services via factories. UsingFactory will be obsoleted/removed in future releases.

OnCreate

It is sometimes needed to either inspect or modify created instance, before it is used. You can use OnCreate method to do this

container.Register(
   Component.For<IService>()
       .ImplementedBy<MyService>()
       .OnCreate((kernel, instance) => instance.Name += "a")
);

The method has two overloads. One that works with a delegate to which an IKernel and newly created instance are passed. Another only takes the newly created instance.

OnCreate works only for components created by the container: This method is not called for components where instance is provided externally (like when using Instance method). It is called only for components created by the container. This also includes components created via certain facilities (Remoting Facility, Factory Support Facility)

A good source of reference is the Castle Windsor documentation, which can be found here:

https://github.com/castleproject/Windsor/tree/master/docs

Here is a sample project with examples and a MVC application showing how it all works

castle windsor

Introduction to IoC with Windsor

I do love dependency injection, but many developers still seem to miss the point and the reason for having it. If you’re only using it on a small scale, you don’t really need any tools to use the technique. But once you’re used to this design technique, you’ll quickly start using it in many places of your code. If you do, it quickly becomes cumbersome to deal with the real instances of your runtime dependencies manually. This is where tools like Inversion Of Control (IoC) containers come in to play. There are a few solid containers available for the .NET world, and even Microsoft has released their own container. Basically, what the IoC container does for you, is take care of providing dependencies to components in a flexible and customizable way. It allows clients to remain completely oblivious to the dependencies of components they use. This makes it easy to change components without having to modify client code. Not to mention the fact that your components are a lot easier to test, since you can simply inject fake dependencies during your tests.

Lets get do to looking at a sample. Suppose we have a class called OrderRepository which exposes methods such as GetById, GetAll, FindOne, FindMany and Store. Obviously, the OrderRepository has a dependency on a class that can actually communicate with some kind of physical datastore, either a database or an xml file or whatever. Either way, it needs another object to access the Order data. Suppose we have an OrderAccessor class which implements an IOrderAccessor interface. The interface declares all the methods we need to retrieve or store our Orders. So our OrderRepository would need to communicate with an object that implements the IOrderAccessor interface. Instead of letting the OrderRepository instantiate that object itself, it will receive it as a parameter in it’s constructor:

        private readonly IOrderDataAccessor _accessor;

        public OrderRepository(IOrderDataAccessor accessor)

        {

            _accessor = accessor;

        }

This makes it easy to test the OrderRepository class, and it’s also easy to make it use different implementations of IOrderDataAccessor later on, should we need to. Now obviously, you really don’t want to do this when you need to instantiate the OrderRepository in your production code:

OrderRepository repo = new OrderRepository(new OrderDataAccessor());

As a consumer of the OrderRepository, you shouldn’t need to know what its dependencies are and you most certainly shouldn’t need to pass the right dependencies into the constructor. Instead, you just want a valid instance of OrderRepository. You really don’t care how it was constructed, which dependencies it has and how they’re provided. You just need to be able to use it. That’s all. This is where the IoC container comes in to help you. Suppose we wrap the IoC container in a Container class that has a few static methods to help you with instantiating instances of types. We could then do this:

OrderRepository repository = Container.Resolve<OrderRepository>();

That would leave you with a valid OrderRepository instance… one that has a usable IOrderDataAccessor but you don’t even know about it, nor do you care how it got there. In other words, you can use the OrderRepository without knowing anything about its underlying implementation.

Let’s take a look at the implementation of the Container class:

    public static class Container

    {

        private static readonly IWindsorContainer _container;

        static Container()

        {

            _container = new WindsorContainer();

            _container.Register(Component.For<IOrderDataAccessor>).ImplementedBy<OrderDataAccessor>());

_container.Register(Component.For<OrderRepository>).ImplementedBy<OrderRepository>());

        }

        public static T Resolve<T>()

        {

            return _container.Resolve<T>();

        }

    }

It just uses a static instance of Windor’s Container and it registers the types we need… let’s examine the following line:

_container.Register(Component.For<IOrderDataAccessor>).ImplementedBy<OrderDataAccessor>());

this basically sets up the container to return a new instance of OrderDataAccessor whenever an instance of IOrderDataAcessor is requested.

We still have to make sure the Windsor container knows about the OrderRepository class by adding it as a known component like this:

_container.Register(Component.For<OrderRepository>).ImplementedBy<OrderRepository>());

By doing this, the Windsor container will inspect the type (in this case, OrderRepository) and it will see that its constructor requires an IOrderDataAccessor instance. We ‘registered’ the IOrderDataAccessor type with the container to return an instance of the OrderDataAccessor type. So basically, whenever someone asks the container to return an instance of an OrderRepository class, the container knows to instantiate an OrderDataAccessor instance to pass along as the required IOrderDataAccessor object to the OrderRepository constructor.

At this point, you may be wondering: “Why go through all this trouble to register the concrete implementation of IOrderDataAccessor to be used in code? We could just as well instantiate the type ourselves!”. That’s certainly true. The code would be slightly uglier, but you’d get the same behavior. Of course, the Windsor container supports XML configuration (either in the app.config or web.config or in a custom configuration file) as well as explicit configuration through code. So you can configure the container through code explicitly, but if there is a config file present, the container will use that configuration instead of the one provided through code. So you could define the defaults in code, and should you need to change it later on, you can just provide a config file.

You know what bothers me about our current implementation? We’re still communicating with an OrderRepository instance. If we wanna be really flexible, it would be better if we were communicating with an object that implemented an IOrderRepository interface. So let’s just define the following interface:

    public interface IOrderRepository

    {

        Order GetById(Guid id);

        IEnumerable<Order> GetAll();

        Order FindOne(Criteria criteria);

        IEnumerable<Order> FindMany(Criteria criteria);

        void Store(Order order);

    }

After all, that’s all we care about as consumers of a IOrderRepository type. We shouldn’t really care about the concrete implementation. We just need an interface to program to. So let’s change the OrderRepository definition to this:

    public class OrderRepository : IOrderRepository

And then when we configure our IoC container we do it like this:

        static Container()

        {

            _container = new WindsorContainer();

            _container.Register(Component.For<IOrderDataAccessor>).ImplementedBy<OrderDataAccessor>());

_container.Register(Component.For<IOrderRepository>).ImplementedBy<OrderRepository>());

        }

Now we can no longer ask the contianer for an OrderRepository interface. But we can ask for an instance that implements the IOrderRepository interface like this:

IOrderRepository repository = Container.Resolve<IOrderRepository>();

So now our client is completely decoupled from the implementation of IOrderRepository, as well as the dependencies it may or may not have.

Ok, lets suppose that this implementation makes it to the production environment. Everything’s working but for some reason, someone makes a decision to retrieve the orders from a specially prepared XML file instead of the database. Unfortunately, your OrderDataAccessor class communicates with a SQL server database. Luckily, the OrderRepository implementation doesn’t know which specific implementation of IOrderDataAccessor it’s using. We just need to make sure that every time someone needs an IOrderRepository instance, it uses the new xml-based IOrderDataAccessor implementation instead of the one we originally intended.

Because we’re using Dependency Injection and an IoC container, this only requires changing one line of code:

_container.Register(Component.For<IOrderDataAccessor>().ImplementedBy<XmlOrderDataAccessor>());

Actually, if we’d put the mapping between the IOrderDataAccessor type and the XmlOrderDataAccessor implementation in an xml file, we wouldn’t even have to change any code! Well, except for the XmlOrderDataAccessor implementation obviously.

We can even take this one step further… After the change to the xml-based OrderDataAccessor went successfully, they (the ‘business’) all of a sudden want to log who retrieves or saves each order for auditing purposes.

We create an implementation of IOrderRepository which keeps extensive auditing logs so they can be retrieved later on. We could just inherit from the default OrderRepository implementation and add auditing logic before each method is executed. Then we’d only have to configure our IoC container to return a different instance of the IOrderRepository type whenever someone requests it:

        static Container()

        {

            _container = new WindsorContainer();

            _container.Register(Component.For<IOrderDataAccessor>().ImplementedBy<XmlOrderDataAccessor>());

            _container.Register(Component.For<IOrderRepository>().ImplementedBy<OrderRepositoryWithAuditing>());

        }

Again, our client code does not need to be modified in any way, yet we did modify the runtime behavior of the application. Instead of retrieving the Orders from a SQL database, it’s now retrieving them from an XML file, and the repository is performing auditing as well, without having to change any client code.

And if we were using the xml-configuration features of Windsor, we could get all of this working without even having to recompile the client-assemblies.

This was just an introduction to using an IoC contianer (Castle’s Windsor specifically) and we briefly touched on benefits that you can achieve with this way of working. The Windsor container can do much more, but you’ll either have to figure that stuff out yourself, or wait for future posts about its other features/possibilities

Updated with new methods and calls for Castle Windsor

Caching to improve the user experience

One of the most important factors in building high-performance, scalable Web applications is the ability to store items, whether data objects, pages, or even parts of a page in memory the initial time they are requested. You can store these items on the Web server or on other software in the request stream, such as a proxy server or at the browser. This allows you to avoid recreating information that satisfied a previous request. . Known as caching, it allows you to use a number of techniques to store page output or application data across HTTP requests and reuse it. When the server does not have to recreate information you save time and resources, and throughput and scalability increase.

It is possible to obtain significant performance improvements in ASP.NET applications by caching frequently requested objects and data in either the Application or Cache classes. While the Cache class certainly offers far more flexibility and control, it only appears to offer a marginal advantage in terms of increased throughput over the Application class for caching. It would be very difficult to develop a testing scheme that could accurately measure the potential advantages of the Cache class’s built – in management of lesser-used objects through the scavenging process as opposed to the fact that Application does not offer this feature. The developer needs to take decision in this case and should be based on the needs and convenience of the project and its usage patterns.

In the article I’ll be looking at the application caching and what is the most effective and scaliable options.  If you would like to know more about the web caching then take a look at the Microsoft Caching Architecture Guide for .NET Framework Applications

So we all know that caching increases performance, what I am not getting into here is when it should be used or when it shouldn’t be used.  I’m more interested in the performance and scalability of the caching used.

The performance testing I am going to use the following different caching methods:

I’ve tried to provide a number of different options that are available for Caching, if you know of any others please let me know and I’ll add them to this post.

There are two types of tests I am using a small test which waits for 30 milliseconds and then returns back the current date and time:

Thread.Sleep(30);
return System.DateTime.UtcNow.ToString(CultureInfo.InvariantCulture);

then a test to generate a much large object of 267 Mb

public IEnumerable<Block> GetData()
{
    // should eat around 267 Mb of RAM.
    var blocks = new Block[512 * 512 * 1];

    for (var i = 0; i < (512 * 512) * 1; i++)
    {
        blocks[i] = new Block();
    }
    return blocks;
}

Both are very simple tests, by no means are they a true representaion of real world methods, but they do show you how it effects the performance when using different Caching.

The idea is to iterate around these test 1,000 times and record how long it takes for each test, what I don’t do here is work out the amount of memory is being used (if you know of an easy way to include this please let me know).

I won’t go into great details here on the results of the tests as I think you’ll find them self explanatory in the test application, attached at the bottom of this post.

Few things to note about the testing and results is that you should use Paralling process for the testing, as this will be much closer to the real world multi threading environment.

Also careful consideration should be given to using locking in the Cache module, as you don’t want the same cache key function running while another one is trying to process the same function, it should wait until the process has finished and stored it into the cache to increase performance.

Here is the sample code with different sample tests showing how effective each option is

cachesample