Pages

Sunday, January 16, 2011

The Repository Pattern - Entity Framework

Introduction
In many applications, business logic accesses data from data stores. There are lot of potential issues when accessing them directly, for example:
  • Code duplication
  • Higher chances of programming errors
  • Problems in testing business logic in isolation from external dependencies
  • Difficulty in implementing centrally managed consistent rules and logic
So it is a good idea to build a layer of abstraction which mediates between the business layer and data source layer of the application. This is where repository pattern comes in to achieve our objectives.

What is Repository
As described on Martin Flower's website:

"A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers."

Implementation
We will discuss the implementation of repositories in context of DDD(domain driven design) for entity framework. Using generics we will create a base repository which will have all the common functionality. And then we will inherit from the base repository to create model/domain specific repositories.

Repository Interface
This is how the repository interface will look like. IRepository<T> is the contract where T is a POCO class. For testing we can later write an fake implementation to remove the dependency.

    public interface IRepository<T> where T : class
    {
        IQueryable<T> GetQuery();

        IEnumerable<T> GetAll();
        IEnumerable<T> Find(Expression<Func<T, bool>> where);
        T Single(Expression<Func<T, bool>> where);
        T First(Expression<Func<T, bool>> where);

        void Delete(T entity);
        void Add(T entity);
        void Attach(T entity);
        void SaveChanges();
    }

Generic Repository Implementation
The base repository takes an IObjectContext as a constructor argument for dependency injection.

    public abstract class EFRepositoryBase<T> : IRepository<T> where T : class
    {
        readonly IObjectContext _objectContext;
        readonly IObjectSet<T> _objectSet;

        public EFRepositoryBase(IObjectContext objectContext)
        {
            _objectContext = objectContext;
            _objectSet = _objectContext.CreateObjectSet<T>();
        }

        public IQueryable<T> GetQuery()
        {
            return _objectSet;
        }

        public IEnumerable<T> GetAll()
        {
            return GetQuery().ToList();
        }

        public IEnumerable<T> Find(Expression<Func<T, bool>> where)
        {
            return _objectSet.Where(where);
        }

        public T Single(Expression<Func<T, bool>> where)
        {
            return _objectSet.Single(where);
        }

        public T First(Expression<Func<T, bool>> where)
        {
            return _objectSet.First(where);
        }

        public void Delete(T entity)
        {
            _objectSet.DeleteObject(entity);
        }

        public void Add(T entity)
        {
            _objectSet.AddObject(entity);
        }

        public void Attach(T entity)
        {
            _objectSet.Attach(entity);
        }

        public void SaveChanges()
        {
            _objectContext.SaveChanges();
        }
    }

Domain specific repository
In these derived repositories you can add the domain/model specific query operations. Here is how the interface and implementation of a User model repository will look like.

    public interface IUserRepository : IRepository<User>
    {
        //add user specific operations
    }

    public class EFUserRepository : EFRepositoryBase<User>, IUserRepository
    {
        public EFUserRepository(IObjectContext objectContext)
            : base(objectContext)
        {
            //add user specific operations
        }
    }

Monday, November 29, 2010

Microsoft Light Switch

Microsoft has come out with a rapid-application development tool to build applications for the desktop, the web, and the cloud. Microsoft is promoting LightSwitch as the simplest way for developers of all skill levels to develop business applications, but it seems to be targeted more at inexperienced developers.

You can download the beta version and look at some demonstration videos here.

Sunday, November 28, 2010

WCF Data Services

It often becomes difficult (if not painful) to share data beyond its original intent. As systems continue to become more interconnected, the need to reuse information also grows and the value of any given data becomes greater the more it can be shared and accessed by other systems.

The Open Data Protocol, referred to as OData, is a new data-sharing standard that breaks down silos and fosters an interoperative ecosystem for data consumers (clients) and producers (services) that is far more powerful than currently possible. WCF Data Services, is the Microsoft technology to support the Open Data Protocol. Microsoft now also supports OData in SQL Server 2008 R2, Windows Azure Storage, Excel 2010 (through PowerPivot), and SharePoint 2010.


In addition to client libraries that simplify working with OData, the Data Services framework builds on the general WCF capabilities to provide a solution for creating OData services for the web. Data Services enable you to expose data models to the Web in a RESTful way, with rich built-in data access capabilities such as flexible querying, paging, and association traversal.

The Data Services framework facilitates the creation of flexible data services that are naturally integrated with the web. WCF Data Services use URIs to point to pieces of data and use simple, well-known formats to represent that data, such as JSON and ATOM (XML-based feed format). This results in the data service being surfaced as a REST-style resource collection that is addressable with URIs and with which agents can interact using standard HTTP verbs such as GET, POST, PUT or DELETE.

For examples and quick start guides on WCF Data Services, go to this link. Also, read more about OData protocol here.

Thursday, November 25, 2010

Difference between XmlSerializer and DataContractSerializer (WCF)

Lets start with, what is serialization?
It is the process of converting an object instance into a format that can be persisted and formated. The objects can be serialized into all sorts of formats(Xml, binary, json, etc). Serializing to Xml is most often used for its interoperability. Serializing to binary is useful when you want to send the object from one .Net application to another. .Net even supports the interfaces and base classes to build your own serialization format.

Deserialization is basically the reverse of serialization. Its the process of taking some data (Xml, binary, json, etc) and converting it back into an object.

I want to point out, that the differences between XmlSerializer and DataContractSerializer are in context of WCF.
XmlSerializer
Advantages:
  • Opt-out rather than opt-in properties to serialize. This mean you don’t have to specify each and every property to serialize, only those you don’t want to serialize
  • Full control over how a property is serialized including it being a node or an attribute
  • Supports more of the XSD standard
Disadvantages:
  • Can only serialize properties
  • Properties must be public
  • Properties must have a get and a set which can result in some awkward design
  • Supports a narrower set of types
  • Cannot understand the DataContractAttribute and will not serialize it unless there is a SerializableAttribute too
DataContractSerializer
Advantages:
  • Opt-in rather than opt-out properties to serialize. This means, you specify what you want to serialize
  • Because it is opt in model, you can serialize not only properties, but also fields. You can even serialize non-public members. And you don't need a set on a property either (however without a setter you can serialize, but not deserialize)
  • Is faster than XmlSerializer because you don’t have full control over how it is serialized, there is a lot that can be done to optimize the serialization/deserialization process.
  • Can understand the SerializableAttribute and know that it needs to be serialized
  • More options and control over KnownTypes
Disadvantages:
  • No control over how the object is serialized outside of setting the name and the order

For WCF, prefer to use the DataContractSerializer. But if you need full control over how the xml looks, use XmlSerializer.

Friday, November 19, 2010

ASP.NET Page Life Cycle Overview

It is important to understand how ASP.NET page life cycle works, as it provides insight about the series of processing steps it goes through and then you can write code at the appropriate life-cycle stage. Specially when you are developing custom controls, you need to be familiar with the page life cycle in order to correctly initialize controls, populate control properties with view-state data and run behavior code.

I am not going to explain all the stages and events of the page life cycle, as it is well documented on MSDN and other blogs. But I found a really good image which provides you an overview of the page life cycle. The following image shows some of the most important methods of the Page class that you can override in order to add code that executes at specific points in the page life cycle. The image also shows how these methods relate to page events and to control events. The sequence of methods and events in the illustration is from top to bottom, and within each row from left to right.


This above image is relevant to .NET framework 4.0. I am going to print this out and stick it somewhere near my desk. BTW, an easy way of remember the important page life-cycle stages is SILVER.

S – Start
I – Initialize
L – Load
V – Validate
E – Event Handling
R – Render

Thursday, November 18, 2010

Update T4 POCO Template for inheritance

Lately I have been working on an application which uses Entity Framework 4. After playing around with the default code generation, I found the option of using ADO.NET POCO template generator. They are very light compared to the entities generated by the default code generator.

But I wanted to customize the template further to suit my requirements. One of the requirements was that all the entity classes should inherit from a base class. So to edit the template, first you need to install T4 editor extension (download it from here).  This editor provides intelli-sense and syntax-hilighting.

Currently the entities generated from the model inherit from other entities only if that inheritance is defined in the model. For example, Employee inherits from Person. This is how the entity decleration looks in the original template:

partial class <#=code.Escape(entity)#><#=code.StringBefore(" : " ,code.Escape(entity.BaseType))#>

This ensures that the Employee class inherits from Person, or that any derived entity inherits from its base, in the generated code. But we now want to have every entity inherit from the new base class (BaseModel) unless the entities are already deriving from another base entity. In other words, Person should inherit directly from BaseModel, while Employee continues to inherit from Person (and therefore indirectly inherits BaseModel).

First, you’ll need to add the method, BaseTypeName, as shown below. Look for IsReadWriteAccessibleProperty method and add the following method above it.
string BaseTypeName(EntityType entity, CodeGenerationTools code)
{
       return entity.BaseType == null ? "Namespace.BusinessEntities.BaseModel" :
               code.Escape(entity.BaseType);
}

Now you can modify the code shown before, where the entity declaration is made to call the BaseTypeName method. As result, the entity will inherit from either BaseModel or its base type as defined in the model.

partial class <#=code.Escape(entity)#><#=code.StringBefore(" : ", BaseTypeName(entity, code))#>

Ensure the entities can locate the BaseModel class. Once you save the template, the entities should get re-generated again based on our customised template.

Wednesday, November 17, 2010

SQL OVER Clause with aggregate functions

In one of my previous post, we saw the usage of OVER() clause for ranking functions. We can also use the OVER() Clause to simplify aggregate calculations. We can now add aggregate functions to any SELECT (even without a GROUP BY clause) by specifying an OVER() partition for each function. Consider the following table:

StudentID
Quesiton Reference No
Section
Required Score
1
Q-M100
Maths
10
1
Q-M200
Maths
15
1
Q-M300
Maths
20
1
Q-M400
Maths
10
1
Q-P100
Physics
10
1
Q-P200
Physics
30
1
Q-P300
Physics
10
1
Q-C100
Chemistry
50
1
Q-C200
Chemistry
10
1
Q-C300
Chemistry
15

Say, there is a requirement where you want to find the weightage of each question within a section
and also the wieghtage of each section for a student. Normally, you would create sub-queries to retrieve the summary values for calculations, as shown below:

SELECT [StudentID], [Quesiton Reference No], [Section], [Required Score],
((([Required Score]*1.0)/
  (SELECT SUM(A.[Required Score]) FROM Answers A WHERE A.[Section] = Answers.[Section]))*100) 
AS QuestionWeightageInSection,
((((SELECT SUM(A.[Required Score]) FROM Answers A WHERE A.[Section] = Answers.[Section])*1.0)/               (SELECT SUM(A.[Required Score]) FROM Answers A WHERE A.[StudentID] = 1))*100) 
AS SectionWeightage

FROM Answers WHERE Answers.[StudentID] = 1

But now with OVER() Clause this becomes more simple and efficient. This is how the query will look:

SELECT [StudentID], [Quesiton Reference No], [Section], [Required Score],
((([Required Score]*1.0)/(SUM([Required Score]) OVER(PARTITION BY [Section])))*100) 
AS QuestionWeightageInSection
((((SUM([Required Score]) OVER(PARTITION BY [Section]))*1.0)/(SUM([Required Score]) OVER(PARTITION BY [StudentID])))*100) 
AS SectionWeightage

FROM Answers WHERE Answers.[StudentID] = 1

StudentID
Quesiton Reference No
Section
Required Score
Question Weightage In Section
Section Weightage
1
Q-C100
Chemistry
50
66.66666667
41.66666667
1
Q-C200
Chemistry
10
13.33333333
41.66666667
1
Q-C300
Chemistry
15
20
41.66666667
1
Q-M400
Maths
10
18.18181818
30.55555556
1
Q-M100
Maths
10
18.18181818
30.55555556
1
Q-M300
Maths
20
36.36363636
30.55555556
1
Q-M200
Maths
15
27.27272727
30.55555556
1
Q-P100
Physics
10
20
27.77777778
1
Q-P200
Physics
30
60
27.77777778
1
Q-P300
Physics
10
20
27.77777778

The way it works is similar to joining an aggregated copy of a SELECT to itself. In my experience it is 20% or more faster than co-related sub queries. You can always look up the execution plan to see the differences between performance. You can use the OVER() Clause with all the other aggregate functions similarly. Read more about it here.