Gil Fink's Blog : Design Patterns

Repository and Unit of Work T4 Template for Entity Framework

Gil Fink — Mon, 05 Jul 2010 18:19:00 GMT

Repository and Unit of Work T4 Template for Entity Framework

Two weeks ago I
wrote the
Revisiting the Repository
and Unit of Work Patterns
with Entity Framework
post. One thing that I
thought would be nice
was to have an automatic
code generation that will help me to build these patterns without sweating.
So I sat down and created a T4 Template to auto generate the same patterns
that I showed in the post.

The Code

One thing to understand is that the provided T4 Template isn’t bullet
proof and errors can occur (you can change the implementation as you
like). In order to use it copy and paste the code to a .tt file that needs
to be located in the library of your Entity Data Model file
(the T4 seeks edmx files in the current directory to auto generate the
classes). Another option is to download the T4 Template from here.
So here it is:

<#@ template debug="true" hostspecific="true" language="C#" #><#@ include file="EF.Utility.CS.ttinclude"#><#@ import namespace="System.IO" #><#@ output extension=".cs" #><#         if(Errors.HasErrors){    return String.Empty;} CodeGenerationTools code = new CodeGenerationTools(this){FullyQualifySystemTypes = true, CamelCaseFields = false};MetadataLoader loader = new MetadataLoader(this); string open = "<";string close = ">";string SourceCsdlPath = FindEDMXFileName();ReferenceCsdlPaths = new string[] {};string namespaceName = code.VsNamespaceSuggestion();ItemCollection = loader.CreateEdmItemCollection(SourceCsdlPath, ReferenceCsdlPaths.ToArray());EntityContainer container = ItemCollection.GetItems<EntityContainer>().FirstOrDefault();#>using System;using System.Collections.Generic;using System.Data.Objects;using System.Linq;using System.Text;using System.Linq.Expressions; namespace <#=namespaceName#>{    public interface IRepository<T> where T : class    {            #region    Methods            T GetById(int id);        IEnumerable<T> GetAll();        IEnumerable<T> Query(Expression<Func<T, bool>> filter);                void Add(T entity);        void Remove(T entity);                   #endregion    }        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      } <#    foreach (EntityType entity in ItemCollection.GetItems<EntityType>().OrderBy(e => e.Name))    {        #>        public partial class <#= entity.Name #>Repository : Repository<#=open#><#=entity.Name#><#=close#>    {        #region Ctor         public <#= entity.Name #>Repository(ObjectContext context)               : base(context)        {        }         #endregion         #region Methods         public override <#= entity.Name #> GetById(int id)           {            return _objectSet.SingleOrDefault(e => e.<#= entity.KeyMembers.First().Name #> == id);        }         #endregion            }<#     }        #>          public interface IUnitOfWork  {      #region    Methods        <#        foreach (EntitySet set in container.BaseEntitySets.OfType<EntitySet>())        {        #>        IRepository<#= open #><#= set.ElementType.Name #><#= close #> <#= set.Name #> { get; }       <#         }    #>    void Commit();        #endregion  }   public partial class UnitOfWork : IUnitOfWork  {    #region Members     private readonly ObjectContext _context;    <#        foreach (EntitySet set in container.BaseEntitySets.OfType<EntitySet>())        {        #>    private <#= set.ElementType.Name #>Repository _<#= set.Name.ToLower() #>;    <#         }    #>        #endregion     #region Ctor     public UnitOfWork(ObjectContext context)    {      if (context == null)      {        throw new ArgumentNullException("context wasn't supplied");      }       _context = context;    }     #endregion     #region IUnitOfWork Members     <#        foreach (EntitySet set in container.BaseEntitySets.OfType<EntitySet>())        {        #>    public IRepository<#= open #><#= set.ElementType.Name #><#= close #> <#= set.Name #>    {        get        {            if (_<#= set.Name.ToLower() #> == null)            {                _<#= set.Name.ToLower() #> = new <#= set.ElementType.Name #>Repository(_context);            }            return _<#= set.Name.ToLower() #>;        }    }    <#         }    #>            public void Commit()    {      _context.SaveChanges();    }     #endregion  }}<#+public string SourceCsdlPath{ get; set; }public EdmItemCollection ItemCollection{ get; set; }public IEnumerable<string> ReferenceCsdlPaths{ get; set; } string FindEDMXFileName(){                string[] entityFrameworkFiles = Directory.GetFiles(Host.ResolvePath(string.Empty), "*.edmx");    if(entityFrameworkFiles.Length > 0)    {        return entityFrameworkFiles[0];    }        return string.Empty;}#>

and this is the generated code that I get after running the T4 Template
on my testing edmx file:

 using System;using System.Collections.Generic;using System.Data.Objects;using System.Linq;using System.Text;using System.Linq.Expressions; namespace ConsoleApplication1{    public interface IRepository<T> where T : class    {            #region    Methods            T GetById(int id);        IEnumerable<T> GetAll();        IEnumerable<T> Query(Expression<Func<T, bool>> filter);                void Add(T entity);        void Remove(T entity);                   #endregion    }        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      }         public partial class CourseRepository : Repository<Course>    {        #region Ctor         public CourseRepository(ObjectContext context)               : base(context)        {        }         #endregion         #region Methods         public override Course GetById(int id)           {            return _objectSet.SingleOrDefault(e => e.CourseID == id);        }         #endregion            }        public partial 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            }        public partial class EnrollmentRepository : Repository<Enrollment>    {        #region Ctor         public EnrollmentRepository(ObjectContext context)               : base(context)        {        }         #endregion         #region Methods         public override Enrollment GetById(int id)           {            return _objectSet.SingleOrDefault(e => e.EnrollmentID == id);        }         #endregion            }        public partial class PersonRepository : Repository<Person>    {        #region Ctor         public PersonRepository(ObjectContext context)               : base(context)        {        }         #endregion         #region Methods         public override Person GetById(int id)           {            return _objectSet.SingleOrDefault(e => e.PersonID == id);        }         #endregion            }          public interface IUnitOfWork  {      #region    Methods                IRepository<Course> Courses { get; }               IRepository<Department> Departments { get; }               IRepository<Enrollment> Enrollments { get; }               IRepository<Person> People { get; }           void Commit();        #endregion  }   public partial class UnitOfWork  {    #region Members     private readonly ObjectContext _context;        private CourseRepository _courses;        private DepartmentRepository _departments;        private EnrollmentRepository _enrollments;        private PersonRepository _people;            #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<Course> Courses    {        get        {            if (_courses == null)            {                _courses = new CourseRepository(_context);            }            return _courses;        }    }        public IRepository<Department> Departments    {        get        {            if (_departments == null)            {                _departments = new DepartmentRepository(_context);            }            return _departments;        }    }        public IRepository<Enrollment> Enrollments    {        get        {            if (_enrollments == null)            {                _enrollments = new EnrollmentRepository(_context);            }            return _enrollments;        }    }        public IRepository<Person> People    {        get        {            if (_people == null)            {                _people = new PersonRepository(_context);            }            return _people;        }    }                public void Commit()    {      _context.SaveChanges();    }     #endregion  }}

Enjoy!

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.

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.

Do We Need Design Patterns?

Gil Fink — Mon, 14 Sep 2009 19:22:40 GMT

Do We Need Design Patterns?

In the previous week I have been asked “do we really need design patterns
when we write code?”. Since one of the first things that I wrote in my blog
was a design patterns series you probably would think that I answered SURE!
or other absolute answer.
That isn’t the case.
The question was raised since I saw that a developer tried to enforce a
design pattern (abstract factory) that wasn’t needed in some place in the
code. What I really believe in is that design patterns are guidelines
of how to build better object oriented design but…
sometime it is being abused like every other aspect in programming.
You don’t need to enforce a pattern in code if what you only need is very
simple implementation.
Yes, reusability, scalability and other phrases that are connected to design
patterns are very important but so does simplicity or other
object oriented design principals like S.O.L.I.D.

In conclusion, we need design patterns but there are other things to consider
when you develop an application. To write it in other words –
“When the only tool you have is a hammer, it is tempting to treat everything as
if it were a nail” - Abraham Maslow.

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.

E4D Learning

Gil Fink — Wed, 06 May 2009 18:25:14 GMT

E4D Learning

In the last two weeks I’m
working in E4D Solutions
as a senior consultant and
as a .NET instructor.
As part of my position
I’m instructing the following
courses:

Enterprise Development –
ADO.NET Entity Framework
Enterprise Library 4.1
General –
ADO.NET Data Services
Design Patterns
ASP.NET –
ASP.NET MVC Framework
ASP.NET Dynamic Data

If you are interested in one of those courses you can contact
E4D in the following link.
I’ll be happy to see you in the next course.

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)

Interpreter Pattern

Gil Fink — Fri, 08 Aug 2008 18:45:00 GMT

This is the last post in the series of design patterns. The post describe the interpreter design pattern and shows an example in C#....(read more)

Observer Pattern

Gil Fink — Mon, 04 Aug 2008 18:35:00 GMT

The post describe one of the most commonly used design pattern - the observer pattern. ...(read more)