The Case For Statics
time to read 5 min | 995 words

I talked about why statics are evil a couple of days ago. Now let us see why we want to use them anyway. Let us talk about a common scenario, and see what we have there. The scenario that I present here is extremely simplistic, of course, but it should be enough that you would get the point.

Let us take the common scenario of dispalying a web page. Most web pages are composed of many small pieces of data, and it is often not possible to fetch them from the same source. For the purpose of discussion, we will need to show a list of orders, the customer info as well as a set of personalization information.

The calls we need to make include the following:

  • Get Recent Orders
  • Get Current Customer
  • Get Personalization Information
  • Get Shippers Statuses

Eventually, each of those call will need to acceess a database. There are several ways to handle this issue. The simplest one will be to have each call create its own connection, like this:

using(IDbConnection connection = DataBase.CreateConnection())
{
  //do work
}

This is simple, but it moves the responsability for the data access to each of the classes involved. Even assuming that creating and disposing the connections is not important, because we have connection pooling turned on, there is still overhead associated with them. I really don't like spreading the responsability around like this, even more than the performance issue.

Let us try something different, and pass the connection from outside, like this:

void OnPageLoad(object sender, EventArgs e)
{
  using(IDbConnection connection = DataBase.CreateConnection())
  {
    connection.Open();
    OrdersCollection orders = new OrderRepository(connection).GetRecentOrders(...);
    Customer cust = new CustomerRepository(connection).GetCurrentCustomer(...);
    // etc, etc 
  }
  // do something useful 
}

This get rid of the issue of creating and disposing the connection, but it is still painful. I need to pass the connection explicitly, and now my UI layer knows about such things as databases. That in itself isn't really bad, but the code above is UI code that is managing database connections.

This is definately not the responsability of any UI layer that I have heard of.

Keep those issues in mind, let us take a look in another scenario. I need to validate the orders, so I can display their status. For that, I have a set of business rules that run on each order, and check it for consistency. At the beginning, I used this approach:

ValidationResult result = new Validator().ValidateOrder(order);

Validator will run each of the seperate business rules, and aggerate its results:

public ValidationResult ValidateOrder(Order order)
{
 ValidationResult result = new ValidationResult ();
 foreach(IBusinessRuleValidator validator in OrderValidators)
 {
    validator.Validate(order, result);
 }
 return result;
}

Very simple, isn't it? Until I need to add a business rule that need to check the database as well. For example, validate that I have a contract with a supplier in a spesific date. Now I need to modify the Validator class to pass it a connection, and all the business rules, just for the sake of a single rule. (This is assuming that the code is mine to change.)

I'm going to leave it at this point, and post my preferred way to handle these types of issues.

Ten points for the first guy/gal that can post a solution that contains "service" in its description and actually makes sense :-)

Tweet Share Share 0 comments
Tags: