Gil Fink's Blog : Architecture

Building N-Tier Applications with Entity Framework 4 Slide Deck

Gil Fink — Tue, 30 Nov 2010 16:40:45 GMT

Building N-Tier Applications with Entity Framework 4 Slide Deck

I just finished my session in Teched Israel 2010. The subject was building N-Tier applications with Entity Framework. I want to thank all the attendees who joined me at this morning after yesterday’s party. The subjects that I covered are how to build N-Tier applications on top of Entity Framework in three different approaches – Self-Tracking Entities, Data Transfer Objects and POCO. If you are interested you can download the slide deck and demos from here.

Enjoy!

Too Much Abstractions? Follow up

Gil Fink — Sat, 17 Jul 2010 14:39:00 GMT

Too Much Abstractions? Follow up

I asked a question about how to know when you have too much
abstractions in your code? and do more abstractions implies better
design?
I promised to do a follow up post and give my humble opinion.
So here it goes.

As architect I’m using abstractions a lot. It allows me to hide the
implementation details and create API’s for my consumers. Also, it
lets me the ability to change the implementation at a later stage of
the project if I need to and of course it makes the code more testable.
One other thing about abstractions is that they decouple the code
we are writing which is a good thing to do. But as always with every
good there can be bad and we can abuse the use of abstractions.

One sentence that I used when I was consulting about
architecture at a customer was “too much abstractions will kill you”.
What I meant was that since we can abstract everything we need to
get the “feeling” when it is appropriate to use this method.
In the customer code there were abstractions on top of other
abstractions which provided less details or identical interface to what
they tried to abstract. So in this situation I preferred to follow the KISS
principle and remove some of the abstractions away. Now the solution is
clearer and more readable with less unneeded abstractions.

The customer’s example shows that even though abstractions are a good
practice you should understand were to apply them. For example to
abstract your infrastructure is a very good practice. Take a look at the
Enterprise Library or Spring.NET code to see how you can leverage
abstractions. On the other hand to create an interface to a Data Transfer
Object which abstract its properties is something that I’ll prefer to avoid.
The reason is that DTOs are meant to be data holders that have no
behavior. If I abstract the properties I gain nothing since in most cases
the implementation will be a getter and a setter and nothing more.
These two examples show exactly what I meant when I wrote that you
should understand were to apply abstractions.

In conclusion, there are times that we use too much abstractions in
our code. If an abstraction doesn't add any value you shouldn’t create it
because it will complicate your code. There is no such thing as abstractions
compass which can tell you when the abstraction is needed or not (or when
you have created too much abstractions). This is why I start with a simple
implementation and then refactor my code and create the needed
abstractions. As a last statement more abstractions don’t imply better
design.

Too Much Abstractions?

Gil Fink — Thu, 15 Jul 2010 17:01:58 GMT

Too Much Abstractions?

Yesterday I had an architecture consulting session at a major customer.
One of the questions that were raised was how to know when you
have too much abstractions in your code?
or to make it even more interesting – do more abstractions implies
better design?
I want to make it an open discussion and to hear what is your opinion
about this subject before I’ll post my own.

Eager Loading with Repository Pattern and Entity Framework

Gil Fink — Tue, 22 Jun 2010 13:11:00 GMT

Eager Loading with Repository Pattern and Entity Framework

One question that I
received yesterday
after I published the
Revisiting the Repository
and Unit of Work Patterns
with Entity Framework post was
how to include the eager loading
ability of Entity Framework.
This post is offering a solution.

Revisiting Eager Loading and Lazy Loading

Lazy loading is a design pattern that is commonly used to defer
initialization of an object up until it is needed by the program.
The gains of using the pattern include efficiency (if it’s used right)
and sometime performance. Eager loading is the opposite pattern of
lazy loading. In this pattern we initialize the object before hand and
don’t wait to the second we really need it.
In Entity Framework we can use the Include method in order to
eager load an entity graph.

Eager Loading with Repository Pattern

In the interface of the Repository I will add a new method which
will be called QueryObjectGraph. That method will receive a string
which indicate the children to load. Now the interface will look like:

public interface IRepository<T> where T : class{            T GetById(int id);    IEnumerable<T> GetAll();    IEnumerable<T> Query(Expression<Func<T, bool>> filter);    IEnumerable<T> QueryObjectGraph(Expression<Func<T, bool>> filter, string children);    void Add(T entity);    void Remove(T entity);   }

and the implementation of the abstract Repository will change to

public abstract class Repository<T> : IRepository<T>                                  where T : class{  #region Members   protected ObjectSet<T> _objectSet;   #endregion   #region Ctor   public Repository(ObjectContext context)  {    _objectSet = context.CreateObjectSet<T>();  }   #endregion   #region IRepository<T> Members   public IEnumerable<T> GetAll()  {    return _objectSet;  }   public abstract T GetById(int id);   public IEnumerable<T> Query(Expression<Func<T, bool>> filter)  {    return _objectSet.Where(filter);  }   public IEnumerable<T> QueryObjectGraph(Expression<Func<T, bool>> filter, string children)  {    return _objectSet.Include(children).Where(filter);  }   public void Add(T entity)  {    _objectSet.AddObject(entity);  }   public void Remove(T entity)  {    _objectSet.DeleteObject(entity);  }   #endregion}

Pay attention that I replaced the IObjectSet<T> into it’s
Entity Framework implementation of ObjectSet<T>. The reason
is that the IObjectSet<T> interface doesn’t include the Include method.
Now I can continue using the same Unit of Work implementation and
also use the eager loading ability like in the following example:

using (SchoolEntities context = new SchoolEntities()){  UnitOfWork uow = new UnitOfWork(context);  foreach (var department in uow.Departments.GetAll())  {    Console.WriteLine(department.Name);  }   foreach (var department in uow.Departments.Query(d => d.Budget > 150000))  {    Console.WriteLine("department with above 150000 budget: {0}",        department.Name);  }   foreach (var department in uow.Departments.QueryObjectGraph(d => d.Budget > 150000, "Courses"))         {    Console.WriteLine("department with above 150000 budget: {0}, {1}",        department.Name, department.Courses.First().Title);  }}

Summary

In the previous post I only showed the way to implement your
repositories. As you can see in this post I can take the offered
solution and make it specific to my needs.

Revisiting the Repository and Unit of Work Patterns with Entity Framework

Gil Fink — Mon, 21 Jun 2010 11:51:00 GMT

Revisiting the Repository and Unit of Work Patterns with Entity Framework

In the past I wrote two
posts about the
Repository and the
Unit of Work patterns
(here and here). Today
I want to show a better
and less naive solution
for imposing the Unit of Work and the Repository patterns with
Entity Framework.

Revisiting The Repositoy Implementation

In the Repository pattern, I added to the interface two new
methods for adding and removing an entity:

public interface IRepository<T>                where T : class{  T GetById(int id);  IEnumerable<T> GetAll();  IEnumerable<T> Query(Expression<Func<T, bool>> filter);      void Add(T entity);  void Remove(T entity);}

Also I’ve changed the return type of the Query from IQueryable
to IEnumerable in order not to enable additional composition
on that query that will hit the database.
The implementation of the Repository itself will change as follows:

public abstract class Repository<T> : IRepository<T>                                  where T : class{  #region Members   protected IObjectSet<T> _objectSet;   #endregion   #region Ctor   public Repository(ObjectContext context)  {    _objectSet = context.CreateObjectSet<T>();  }   #endregion   #region IRepository<T> Members   public IEnumerable<T> GetAll()  {    return _objectSet;  }   public abstract T GetById(int id);   public IEnumerable<T> Query(Expression<Func<T, bool>> filter)  {    return _objectSet.Where(filter);  }   public void Add(T entity)  {    _objectSet.AddObject(entity);  }   public void Remove(T entity)  {    _objectSet.DeleteObject(entity);  }   #endregion

One of the things to notice is that I hold an IObjectSet as my data
member of the Repository itself instead of holding the context like
in my previous post. The IObjectSet is a new interface in EF4
which helps to abstract the use of the created entity sets.
Now the Repository is better implemented and looks like an
in-memory collection as it was suppose to be. If I need more specific
methods I can inherit from this Repository implementation and add the
desired functionality. As you can see I don’t implement the GetById
method and enforce my concretes to implement it.
The DepartmentRepository from the previous post will look like:

public class DepartmentRepository : Repository<Department>{   #region Ctor    public DepartmentRepository(ObjectContext context)     : base(context)   {   }    #endregion    #region Methods    public override Department GetById(int id)   {     return _objectSet.SingleOrDefault(e => e.DepartmentID == id);   }    #endregion}

Revisiting The Unit of Work Implementation

After we have our Repository we would like to create a
Unit of Work to hold the application repositories and to
orchestrate the persisting of data for some business transactions.
The new interface for the Unit of Work will look like:

public interface IUnitOfWork{  IRepository<Department> Departments { get; }      void Commit();}

By of course if you have more repositories in your application you
will add them to the IUnitOfWork (in the example I only have the
departments repository). Now the implementation of the Unit of Work
won’t be a part of the repository (like in the old post) and will look like:

public class UnitOfWork : IUnitOfWork{  #region Members   private readonly ObjectContext _context;  private DepartmentRepository _departments;   #endregion   #region Ctor   public UnitOfWork(ObjectContext context)  {    if (context == null)    {      throw new ArgumentNullException("context wasn't supplied");    }     _context = context;  }   #endregion   #region IUnitOfWork Members   public IRepository<Department> Departments  {    get    {      if (_departments == null)      {        _departments = new DepartmentRepository(_context);      }      return _departments;     }  }   public void Commit()  {    _context.SaveChanges();  }   #endregion}

As can be seen the Unit of Work holds the ObjectContext but
you could use an IContext interface instead if you like to be more
abstract and with no dependency on Entity Framework at all. This can be
achieved by using the T4 templates that were provided in EF4 which you
will use to add the IContext interface implementation. The
Unit of Work has a constructor that can be injected using an IoC container.
The testing program will change into:

using (SchoolEntities context = new SchoolEntities()){  UnitOfWork uow = new UnitOfWork(context);  foreach (var department in uow.Departments.GetAll())  {    Console.WriteLine(department.Name);  }   foreach (var department in uow.Departments.Query(d => d.Budget > 150000))  {    Console.WriteLine("department with above 150000 budget: {0}",        department.Name);  }}

Some thing to notice here is that I create the context during
the running of the program. As I wrote earlier, this can be changed
to using an IoC container instead which will inject the constructor
dependency.

Summary

Lets sum up, this offered solution is much better then the naive
example I gave in the previous posts. It is much more testable and
abstract and as I wrote you could go further and use an IoC container
to inject the use of Entity Framework in the Unit of Work
implementation.

Cache Retrieval Pattern

Gil Fink — Sun, 13 Jun 2010 12:32:00 GMT

Cache Retrieval Pattern

In my previous post I wrote about cache layer and its position
in every application. In this post I’m going to explain what is
the cache retrieval pattern and show an example of how to
implement it.

Cache Retrieval Pattern

When we implement a cache layer we need a strategy in order to
retrieve cached items. The cache retrieval pattern is very
simple and can be imposed into any application very fast.
So how does it work?
The business logic component will use the cache API in order to
check whether some data exists in the cache. If the data doesn’t exists
in the cache, the business logic component responsibility will be to
insert the data into the cache. Since cache is volatile you can’t depend
on it to hold the data you need. This is why you always need to check
whether the data exists in the first place. The business logic component
will use a data access component to retrieve the relevant data from a
data storage. After it has the data in hand it will place the data in
the cache and return it to its consumer. The following diagram
shows how this pattern work:

Cache Retrieval Pattern Example

After we understood the what lets take a look at the how.
The following BL class implement the data retrieval pattern:

public class BLComponent{  #region Properties   private ICacheManager CacheManager { get; private set; }       #endregion   #region Ctor   public BLComponent(ICacheManager cacheManager)  {    CacheManager = cacheManager;  }   #endregion   #region Methods   public Department GetDepartmentById(int departmentId)  {    if (!CacheManager.Contains(departmentId.ToString()))    {      DALComponent dataAccessor = new DALComponent();      Department department = dataAccessor.GetDepartmentById(departmentId);      CacheManager.Insert(departmentId.ToString(), department);      return department;    }    return CacheManager.Get<Department>(departmentId.ToString());  }   #endregion}

As you can see I use the ICacheManager interface in order to
create an abstraction against the cache layer. This will enable
me to create a class which uses the cache API of my chosen
cache implementation (in memory, distributed and etc).
The ICacheManager can look like:

public interface ICacheManager{  /// <summary>       /// Add a new object into the cache       /// </summary>       /// <param name="key">The key of the object to add</param>       /// <param name="value">The value of the object to add</param>       void Add(string key, object value);   /// <summary>       /// Check whether the key is contained by the cache       /// </summary>       /// <param name="key">The key to check</param>       /// <returns>Returns true if the key is contained by the cache</returns>       bool Contains(string key);   /// <summary>       /// Returns the number of items in the cache       /// </summary>       /// <returns></returns>       int Count();   /// <summary>       /// Insert a new object into the cache        /// </summary>       /// <param name="key">The key of the object to insert</param>       /// <param name="value">The value of the object to insert</param>       void Insert(string key, object value);   /// <summary>       /// Get the object that its key is given      /// </summary>       /// <typeparam name="T">The object</typeparam>       /// <param name="key">The given key to check</param>       /// <returns>returns the object or null if it doesn't exists</returns>       T Get<T>(string key);   /// <summary>       /// Removes the object that is referenced by the given key       /// </summary>       /// <param name="key">The given key</param>       void Remove(string key);   /// <summary>       /// Get/Set the the given key and object       /// </summary>       /// <param name="key">The given key to the indexer</param>       /// <returns>Returns the object that the given key reference</returns>       object this[string key]  {    get;    set;  }}

The data access component isn’t relevant to our discussion because
underneath it can be implemented by IRepository, some service or
whatever method you pick to retrieve your relevant data. Also,
pay attention that this example isn’t thread safe.

Summary

The cache retrieval pattern is simple to understand and implement
in any application. As I wrote in my previous post using caching in
applications is a must and the pattern for retrieving data will help
you to insure you have the relevant data close to your application.

Cache Layer

Gil Fink — Fri, 11 Jun 2010 15:51:00 GMT

Cache Layer

Lately I found myself in some architecture consulting sessions at
some customers. In every one of those customers I found myself
explaining how to implement a cache layer in order to decrease
the amount of round trips to the database and for better scalability.
In this post I’ll try to explain in high level how to build a cache layer.

Deciding to Build a Cache Layer

Every application that performance is important to its developers
and managers must contain some sort of caching. The cache is a very
fast in memory resources container which holds relevant data close to the
application itself. I explained in the past the candidate resource types
for caching in this post. So you have decide to implement caching
in your application, what next?
The answer is simple – create a cache layer.

Cache Layer Position in Application Architecture

The next thing to understand is the location of the cache layer in your
application. The next diagram shows were you should place the cache layer:

As you can see the cache layer's best place is between the business
logic layer and the data access layer. The business logic responsibility
will be to check whether an entity or some data exists in the cache
and then if not to make a round trip to the database (using the data
access layer of course) and bring the data to application. When the data
exists we first put it in the cache and then we have the data in hand
and also it exists our the cache. This is called the cache retrieval pattern.
There are many ways to create a cache layer for example by using
distributed cache like AppFabric caching services, Enterprise Library
Caching Application Block, ASP.NET caching and many more cache services.
It’s your responsibility to evaluate which cache technology to use in your
application by answering to your application requirements.

Summary

Caching in applications is a very vital way to improve the application
performance and make the application more scalable. It’s our
responsibility to create a cache layer which will exists between
your business logic and data access layer. By using the cache retrieval
pattern you will be able to use your cache in a very efficient way.

Using Unit of Work Pattern with Entity Framework

Gil Fink — Fri, 05 Feb 2010 20:22:04 GMT

Using Unit of Work Pattern with Entity Framework

In a previous post
I explained how
to create a
simple repository
on top of
Entity Framework.
In this post I’ll explain the Unit of Work pattern and how
we can use it with our data access layer.

What is Unit of Work Pattern?

In his famous and developer must read book
“Patterns of Enterprise Application Architecture”, Martin Fowler
defines the Unit of Work as “Maintains a list of objects affected by a
business transaction and coordinates the writing out of changes and the
resolution of concurrency problems.”
What it means is that a unit of work is a context/session/unit object that
tracks the changes of business entities during one business transaction. It is
also responsible for the manage of concurrency problems when they occur.

How to Use The Pattern?

As in the repository pattern we will start with an interface which was
suggested by Martin Fowler:

     public interface IUnitOfWork<T>

    {

        void RegisterNew(T entity);

        void RegisterDirty(T entity);

        void RegisterClean(T entity);

        void RegisterDeleted(T entity);

        void Commit();

    }

As you can see we register changes of entities inside the unit of work
and in the end of every transaction we commit it using the commit method.
In all the major ORMs out there you get all that functionality within the
session/context objects. It is the unit of work object that holds the details
of every change you do to an entity. Since this is the case you don’t
have to have all the four register methods when you use frameworks
like Entity Framework, NHibernate or other ORMs.
In my example I’m going to use the following unit of work interface:

    public interface IUnitOfWork<T>

    {

        void RegisterNew(T entity);

        void RegisterDeleted(T entity);

        void Commit();

    }

Entity Framework Example

Lets return to the example of the repository I used in the previous post.
I can transform the DepartmentRepository that I’ve built into a
unit of work that handle departments like this one:

    public class DepartmentRepository : IRepository<Department>,

        IUnitOfWork<Department>, IDisposable

    {

        #region Members

        private SchoolEntities _context;        

        #endregion

        #region Ctor

        public DepartmentRepository() 

        {            

            _context = new SchoolEntities();

        }

        #endregion

        #region IRepository<Department> Members

        public Department GetById(int id)

        {

            return _context.Departments.

                Where(d => d.DepartmentID == id).

                FirstOrDefault();

        }

        public Department[] GetAll()

        {

            return _context.Departments.ToArray();

        }

        public IQueryable<Department> Query(Expression<Func<Department, bool>> filter)

        {

            return _context.Departments.Where(filter);

        }

        #endregion

        #region IUnitOfWork<Department> Members

        public void RegisterNew(Department entity)

        {

            _context.AddToDepartments(entity);

        }

        public void RegisterDeleted(Department entity)

        {

            _context.DeleteObject(entity);

        }

        public void Commit()

        {

            _context.SaveChanges();

        }

        #endregion

        #region IDisposable Members

        public void Dispose()

        {

            if (_context != null)

            {

                _context.Dispose();

            }

            GC.SuppressFinalize(this);

        }

        #endregion

    }

This is a really simple example of how to implement the pattern.
There are a lot of other examples in the web like in the following link:
Entity Framework 4.0 Beta 1 – POCO, ObjectSet, Repository and UnitOfWork

Summary

Lets sum up, every ORM that respect itself (like Entity Framework) includes
implementation for the unit of work pattern. If we want to add our abstraction
layer which include a unit of work then we need to create our implementation.
We will start with an interface such as the one that Martin Fowler suggested.
Then it is our responsibility to track changes and to persist all the work that was
done in a time period as a transaction and also manage concurrency issues.

Table Per Type Inheritance in Entity Framework

Gil Fink — Fri, 22 Jan 2010 16:22:00 GMT

Table Per Type Inheritance in Entity Framework

The first inheritance
mapping I’m going to
show is called
Table Per Type
or TPT. Before
I start with the example
lets define what is TPT.

Table Per Type Definition

TPT is an inheritance described in the database with separate tables.
Every table provides additional details that describe a new type
based on another table which is that table’s parent.
In the following database ERD the OnlineCourse table is a concrete
type of Course:

As you can see the CourseID of both Course and OnlineCourse table
are the same identity.

TPT Example

The following steps will help you to understand how you can create
a TPT inheritance mapping. I’m going to use the exactly database
from the first figure I showed.

Step 1
The first step is to create the Entity Data Model from the database.
Here is the EDM I’m going to use in the example:

As you can see I created an EDM with only the relevant tables for
simplicity. Also, pay attention to the association that was created
(1 - 0..1) between the tables. This is happening because of the use of
the same ID in both of the tables.

Step 2
After we have our EDM ready to work we need to define the
inheritance instead of using the created association.
First remove the association by clicking on the association in
the designer and pressing delete. Then from the designer surface
press on the right mouse button and use the Add –> Inheritance
to open the Add Inheritance dialog.

In the Add Inheritance dialog make the Course the base entity and
the OnlineCourse the derived entity like in the following figure:

We you finish you will have an inheritance arrow between OnlineCourse
and Course like:

Step 3
After we have created the inheritance we need to fix our model.
The CourseID field in the OnlineCourse isn’t relevant anymore since
it is part of the base entity. So lets remove it. Also we need the
CourseID database field to be mapped to something which is the
parent CourseID:

That is it for this kind of model. There will be more model fixing when
we have associations to other entities.

Step 4
Test the created model. The following piece of code will print the
count of the online courses we have in our database:

using (var context = new SchoolEntities()){    var query = context.Courses.OfType<OnlineCourse>().Count();    Console.WriteLine("Number of online courses: {0}", query);    Console.ReadLine();}

As you can see I’m using the OfType method which enable me to
do operations on derived types.

Summary

Lets sum up, I showed how to use Table Per Type inheritance in
Entity Framework. As I wrote in a previous post this kind of mapping
isn’t used only by EF and it is also used by other ORMs. In the
next post in this series I’m going to describe and show the Table
Per Hierarchy inheritance.

Using Repository Pattern with Entity Framework

Gil Fink — Wed, 20 Jan 2010 18:35:14 GMT

Using Repository Pattern with Entity Framework

One of the tools
for reaching for
persistence
ignorance is to
build a facade between
the data access layer and
your business logic. Such facade will prevent the knowledge of
how the data access is working and with which technology. That
abstraction can be achieved by using the Repository Pattern.
In the post I’ll show how you can use the Repository Pattern in order
to make an abstraction layer on top of Entity Framework.

The Repository Interface

When we want to use the Repository Pattern we
start with an interface which will be our data access facade.
I’ll be using the following interface in my example:

     public interface IRepository<T>

    {        

        T GetById(int id);

        T[] GetAll();        

        IQueryable<T> Query(Expression<Func<T, bool>> filter);                                

    }

This interface only include some of the functionality which I’ll
put in a repository. You may notice that I removed any CUD
(Create/Update/Delete) operations. In a follow up post I’ll show
how to implement these operations by using the Unit of Work
pattern.

A Repository Implementation

The following is a naive implementation for a department repository:

    public class DepartmentRepository : IRepository<Department>, IDisposable

    {

        #region Members

        private SchoolEntities _context;        

        #endregion

        #region Ctor

        public DepartmentRepository() 

        {            

            _context = new SchoolEntities();

        }

        #endregion

        #region IRepository<Department> Members

        public Department GetById(int id)

        {

            return _context.Departments.

                Where(d => d.DepartmentID == id).

                FirstOrDefault();

        }

        public Department[] GetAll()

        {

            return _context.Departments.ToArray();

        }

        public IQueryable<Department> Query(Expression<Func<Department, bool>> filter)

        {

            return _context.Departments.Where(filter);

        }

        #endregion

        #region IDisposable Members

        public void Dispose()

        {

            if (_context != null) 

            { 

                _context.Dispose(); 

            } 

            GC.SuppressFinalize(this);

        }

        #endregion

    }

This is a naive implementation since I hold a context inside my
department repository. A better solution will be to create a
context helper that will be used in order to create contexts when
they are needed. After we have the implementation we can start
using it.
The following code demonstrate how we can use the department
repository:

    IRepository<Department> repository = new DepartmentRepository();

    foreach (var department in repository.GetAll())

    {

        Console.WriteLine(department.Name);

    }

    foreach (var department in repository.Query(d => d.Budget > 150000))

    {

        Console.WriteLine("department with above 150000 budget: {0}",

            department.Name);

    }            

    Console.ReadLine();

Why to use the Repository Pattern?

There are a lot of reasons for using the Repository Pattern.
For example:

Testability. Using the pattern we can create stubs that
can replace the real data access objects. This can
help us to test our business logic without concerning what the
data access is doing.
Abstraction. Using the pattern we create an abstraction above
our data access functionality. This abstraction can help us when we
want to change the implementation of the data access without
affecting our business logic code. For example, I had to change
implementation of data access with a call to a web service. Using
the pattern I only needed to change the object that I used and that is
it.
Dependency Injection. Using the pattern we can use DI containers to
inject the relevant object that we want to use in the code.

Summary

Lets sum up, the Repository Pattern is a very useful pattern to use
when we build data access layers. Like all other patterns sometimes
it can be an overkill in abstraction (in particular in small and simple applications).
In the post I showed one way to create a repository on top of Entity Framework.
I could have used any other data access frameworks as well and this is the beauty
of the pattern. In a follow up post I’ll explain what is the Unit of Work pattern and
will continue building the repository I used in this post so stay tuned.

Applying Strategy Pattern Instead of Using Switch Statements

Gil Fink — Sun, 22 Nov 2009 14:53:00 GMT

Applying Strategy Pattern Instead of Using Switch Statements

Once in a while I’m stumbling on switch statements during a
Code Review session. Whenever this is happening my first reaction
is to understand why did the developer use it.
Since using switch statement sometime implies spaghetti code and
also can get very crowded (in case statements of course) in this post
I’m going to show an alternative method that I prefer to use.

Alternative Method for Switch Statements

Whenever you start to use a switch statement you should
ask yourself whether you can use Strategy Pattern instead.
The Strategy Pattern help us to divide an algorithm from a host class
and then move it to another class. By doing so the client can choose
which algorithm will be performed in runtime from a set of algorithms
that were implemented earlier.
The Strategy Pattern can also help us when we want to replace a
switch statement. We can look at every case as a different
algorithm that we want to use which differ only by some condition
or a key. Since this is the case, for every case we can build a class that
do an action (the algorithm) and by that we can prevent the horror of
using an “endless” switch or spaghetti code.

Applying Strategy Pattern Over a Switch Statement

The following code shows how to replace a switch statement with
a Strategy implementation. We start with the first implementation
before we refactor it:

class Program{    public enum ePassengerTitle    {        Mr,        Mrs,        Doctor,    }     static void Main(string[] args)    {        ePassengerTitle title = ePassengerTitle.Doctor;        switch (title)        {            case ePassengerTitle.Mr:                // do something                break;            case ePassengerTitle.Mrs:                // do something                break;            case ePassengerTitle.Doctor:                // do something                break;            default:                break;        }    }}

As you can see I have an enum which holds a passenger title.
This title can get crowded for example when we want to add
more titles like Reverend, Miss or more.
Lets see how we can change this implementation to use the
Strategy Pattern:

#region Strategy Interface public interface IPassengerTitleStrategy{    void DoAlgorithm();} #endregion #region Concrete Classes public class MrPassengerTitleStrategy : IPassengerTitleStrategy{    #region IPassengerTitleStrategy Members     public void DoAlgorithm()    {        throw new NotImplementedException();    }     #endregion} public class MrsPassengerTitleStrategy : IPassengerTitleStrategy{    #region IPassengerTitleStrategy Members     public void DoAlgorithm()    {        throw new NotImplementedException();    }     #endregion} public class DoctorPassengerTitleStrategy : IPassengerTitleStrategy{    #region IPassengerTitleStrategy Members     public void DoAlgorithm()    {        throw new NotImplementedException();    }     #endregion} #endregion #region Context public class Context{    #region Members     private static Dictionary<ePassengerTitle, IPassengerTitleStrategy> _strategies =        new Dictionary<ePassengerTitle, IPassengerTitleStrategy>();     #endregion     #region Ctor     public static Context()    {        _strategies.Add(ePassengerTitle.Mr, new MrPassengerTitleStrategy());        _strategies.Add(ePassengerTitle.Mrs, new MrsPassengerTitleStrategy());        _strategies.Add(ePassengerTitle.Doctor, new DoctorPassengerTitleStrategy());    }        #endregion     #region Methods     public static void DoAlgorithm(ePassengerTitle title)    {        _strategies[title].DoAlgorithm();    }     #endregion} #endregion

You can see that I register all the algorithms inside a dictionary
which will help us to imply the relevant algorithm whenever we
need it. The registration is done inside the Context class which
then exposes the DoAlgorithm method which gets the relevant
passenger title and implies to it the relevant algorithm.
Lets see how our program change when we use the Strategy
implementation:

public enum ePassengerTitle{    Mr,    Mrs,    Doctor,} class Program{    static void Main(string[] args)    {        ePassengerTitle title = ePassengerTitle.Doctor;        Context.DoAlgorithm(title);    }}

This is only one way to implement the Strategy Pattern. There are other
ways to do the same thing but without dictionaries which you can find in
the internet.

What we gain by using Strategy Pattern?

The code is easier to read. I don’t need to go and read (or
search) an “endless” switch statement to understand each
aspect of the code.
The code is more maintainable. I only need to go to the
relevant class that implement the algorithm in order to change it
or refactor it when needed.
It is easier to add more algorithms. I only need to add more classes
to the pile of algorithms and that is it. Doing so helps us to imply
the Open / Closed Principle because in switch statement we are going
to have to change our code (add another case statement) in opposed
to Strategy which we add another algorithm class.
Strategy Pattern is more testable.

Even so, there are times that switch statement is preferable then
Strategy Pattern but when you find yourself having an “endless” switch
or repeat the same switch all over the place this should alert you that
Strategy Pattern is needed.

Summary

In the post I showed an alternative method for switch statement use. I
always prefer the use of Strategy Pattern instead of switch statements.
This approach is more OOP for developing even though it will force you to
implement more classes. In the end you can choose either the switch
statement or Strategy Pattern but if you have chosen a switch statement
do it in the right place.

My Next Month Courses Schedule

Gil Fink — Wed, 13 May 2009 12:37:44 GMT

My Next Month Courses Schedule

Next month I’m scheduled for
the following courses:

ADO.NET Entity Framework
Scheduled for 16.6
Advanced ASP.NET 3.5
Scheduled for 14.6
Design Patterns
Scheduled for 11.6

If you want to participate in one of those courses or more details, you can
contact E4D in the following ways:

Contact Form in the this link
Call Michal - 054-5612259
Call Oranit - 03-6325707

See you there.

The Benefits of Building a Layered Application

Gil Fink — Sat, 09 May 2009 15:16:00 GMT

The Benefits of Building a Layered Application

During the last two weeks I’m consulting at a customer that built
a very simple application very badly. One of the problems that I found was
the lack of layers separation which made the application very tangled.
One example for that is the calling of stored procedures from UI user
controls. I talked to the managers about that issue and explained the
benefits of building a layered application. This post will explore those
benefits.

Layered Application Pattern

Before talking about the benefits first we need to understand what is
layered application pattern. The pattern is very easy. You separate the
application components to layers. The components in each layer should
be cohesive and should have very close related in their functionality. Each
layer should be loosely coupled to the layers that are below it.
The following figure shows layers:

(the figure is taken form the Enterprise Solution Patterns Using Microsoft .NET
book)
The main subject in layers is dependency management. Every component
in one layer can interact with components in the same layer or components
from lower layers. There are many approaches to layers building but it won’t
be covered in the post. For more details you can read about the subject in
the following books:

Enterprise Solution Patterns Using Microsoft .NET
Patterns of Enterprise Application Architecture

The Benefits of Building a Layered Application

Other applications will be able to reuse the functionality exposed
by your layers.
You will be able to distribute your layers over multiple physical
tiers. This can make a very good impact on your application by
improving performance (sometimes), scalability and fault
tolerance.
The maintenance of your application is easier because of the low
coupling between layers.
Adding more functionality to your application is made easier.
Layers make your application more testable.
Building a well formed layers makes the orientation in your
application more easier.

Summary

Lets sum up, the post explained what is the layered application pattern.
It also explored the benefits of building a layered application. Building
layered application can make your life easier. I encourage you to use the pattern.

ADO.NET Data Services Introduction

Gil Fink — Sun, 10 Aug 2008 18:30:00 GMT

ADO.NET Data Services Introduction Introduction From the early ages of development, the separation of presentation and data was very necessary and was considered (and is considered) a good practice. As you all know, the current trend in the web development world is building Rich Internet Applications ( RIA ) and buzz words like Ajax and Silverlight are very popular today. The RIA technologies ( Ajax , Silverlight and etc) are built on the concept of separation between the presentation and data in...(read more)

Farewell Design Patterns Series

Gil Fink — Fri, 08 Aug 2008 19:11:00 GMT

Farewell Design Patterns Series Today I finished my series in the subject of design patterns . It was an intensive and satisfying writing and I hope that you will find the series helpful and use it. You can read all the series in the following links: Structural patterns Decorator pattern Proxy pattern Facade pattern Adapter pattern Composite pattern Bridge pattern Flyweight pattern Creational patterns Singleton pattern Abstract Factory pattern Prototype pattern Factory Method pattern Builder pattern...(read more)