Monthly Archives: June 2013

Tiered Applications

We design systems in tiers to enable us to simplify complex problems and to give us greater understanding of the solutions we are attempting to create.

The most common separation is to split Data, Display and the methods to convert one to the other (generally known as Business Logic). This three tier structure can be seen across many different applications, and extends throughout the entire software industry. Often developers will be hired to only work on a single tier, the skills for working at each level can be very different.

If we achieve a good separation into tiers, we can replace the implementation of one tier with another. The commonest replacement is to implement new Display modes, adding a mobile display to an existing website, switching a windows display to the web.

Changing the data source is almost always more problematic, as you must move your data as well, but it is still possible.

We give up the possibility of the most efficient system when we create a tiered system, but in exchange we gain simplicity and understanding. As technology gets ever more powerful the systems we ever more afford this trade-off in the interest of creating maintainable and extendable systems.

Advertisements

Azure – Roles

My simple Azure application, Magic Deck Statistics, makes use of two of the different types of Azure roles, web roles and worker roles.

Very simply, web roles are used to run web applications, via IIS. Worker roles do not have access to IIS (by default), and are used to run processes that don’t have user interaction.

In my application the worker role runs a daily job to download data from various sources and process it into a SQL database. The web roles deal with the presentation of this data, handling requests from visitors and querying the processed data.

The advantage of Web and Worker roles is that you don’t have to worry about the underpinnings of the setup. The server details are abstracted away and managed for you. You can very quickly scale up by provisioning additional web and worker roles through the management console.

If you need to deal with more complex software scenarios you can make use of the more general VM options, which allow you full configuration control over the VM. The cost here is that you must then maintain the entire machine, dealing with any patching and updating yourself.

Extension Methods

Extension methods in C# are a way to expand the functionality of a class without creating new derived types.

You need to be careful when you use an extension method, once you start it’s very easy to just make everything into an extension.

Try to be controlled, only make an extension method if you really need to. Usually this is to add functionality to classes you do not control the source code to. You also want to only add an extension that makes sense for the whole problem domain. Don’t extend int to give values relating to time, or other such oddness.

The most common modern use is to create new Html Helpers in MVC.


namespace MyProject.Extensions
{
  public static class HtmlHelperExtensions
  {
    public static string BeHelpful(this HtmlHelper helper)
    {
      return "I'm Helping";
    }
  }
}

To use this extension in your view, you need to make sure that the namespace it’s in is included in the ~/Views/web.config file. You will also need to reference the namespace with a using directive.

@using MyProject.Extensions
@Html.BeHelpful()

If you want to pass additional data to your helper, then you would include these parameters in the method definition

public static string ShortenString
  (this HtmlHelper helper, string value)
  {
    return
      value.Length() > 10 ? value.Substring(0, 10) : value;
  }

One further thing to consider, when creating extensions you cannot override an existing method, if you attempt to do this it will not work, the original method will always be called.

So, use extension methods carefully, otherwise you will clutter up your code. They are useful, but not a cure to all your problems.

Sql Indexes

Indexes are vital for good database performance. Pick the correct index and your queries will be fast and responsive. Pick the wrong ones, and you’ll waste a lot of time and resources.

An index on a table is simply a way of looking up the data contained within the table. It should be as small as possible whilst still being useful.

For example, you might have a table that contains information about people. Your primary key might be a simple ID number, and you’d also store things like Forename, Surname, Date of Birth etc.

ID  Forename  Surname  DateOfBirth
1   John      Smith    1990-01-01
2   James     Apple    1980-12-10
3   Phil      Barns    1975-06-06
4   Mary      Stokes   1987-09-23

It would be very common to query this table by searching on Surname.

SELECT
  Forename, Surname, DateOfBirth
FROM
  People
WHERE
  Surname LIKE 'A%'

If you turn on the “Include Actual Execution Plan” with this query in Sql Server Management Studio, you will see a “Table Scan”. This occurs when every record in the table must be search through to find matches. In a large table this would be very slow.

You could add a simple Index the table to speed the query up massively

CREATE INDEX IX_Surname ON People (Surname)

When this index has been created, the query optimiser will look-up the values in the index, and only then get the data from the table for the rows that match, a much faster operation.

If you want to find out the Indexes that SQL Server believes you need, then you can use the dynamic maangement view sys.dm_db_missing_index_details

Don’t rely on this view to be comprehensive, just use it as a guideline to begin investigation. Sometimes it’s a bit enthusiastic, whilst the indexes may be useful, the performance trade-off may not be ideal.

This is only a very basic introduction to indexes, I’ll be going over them in more detail in further posts. If there’s anything you want to see covered sooner rather than later, let me know and I’ll see what I can do.