Web application data access layers have evolved over time to provide increasing flexibility and maintainability in software architecture. Often, many web applications begin by manually maintaining database connections and SQL query strings. However, as architecture designs grow, more web applications are using ORM models to help increase code reuse and maintainability of ever-growing C# ASP .NET web applications.
The latest version of the Entity Framework EF4 provides several new features, which support implementing a loosely-coupled repository pattern design. Using the Repository Pattern, along with a UnitOfWork pattern, we can greatly enhance the maintainability of our web applications with a solid architecture, greater code reuse, and unit test capability.
In this article, we’ll step through 3 methods of accessing the Entity Framework data access layer in C# ASP .NET. We’ll then detail an implementation of the Repository and UnitOfWork Pattern to get the most out of the design.
The Entity Framework is quite powerful. With a few clicks in Visual Studio, we can instantly create an ORM relational model of our database, ready for querying. One of the most simplest implementation of accessing data with the Entity Framework in a C# ASP .NET web application would be the following:
In the above code, we’ve implemented the basic Entity Framework data context within a using block. The using block will automatically dispose of the context object upon completion. Note, the database connection itself is opened and closed automatically upon calling SaveChanges().
The basic C# ASP .NET Entity Framework sample demonstrates using the ORM objects and persisting to the database. However, a more complicated web application, containing large numbers of business rules for saving and relating entities, could get quite complex using the above design. For example, what if the Dragon object could only accept weapons of type “Breath”? A new block of code would need to be inserted to perform the check. Similarly, a new block of code may need to be added to the Weapon as well. To abstract the more complicated business logic that may need to be added, we can utilize the Repository Pattern.
The C# ASP .NET Repository Pattern is a layer created to manage the persistence of data to and from the Entity Framework ORM. While the repository pattern is often extended to include business logic (unrelated to persistence), it is often a cleaner approach to keep the repository pattern strictly for data persistence. A separate business manager class or repository wrapper can be created to manage business logic. In either case, as your repository business logic spans across the various domain objects, you’ll find yourself requiring the Entity Framework data context in each method, in order to save data.
One way of resolving the issue of using multiple repositories for a single work transaction may be to open and close individual Entity Framework context objects, within using blocks, throughout the code. However, for more data expensive C# ASP .NET web applications, executing queries over many database connections would be less than optimal.
In the above code, you can see how two separate queries will be executed against the database, each one requiring a database connection. For better performance, the queries could be combined into a single database query and transaction. However, to continue using the repository pattern and it’s separation of code concerns, we’ll need a way of sharing the context between them. This is where the UnitOfWork pattern comes in.
The UnitOfWork pattern is a design for grouping a set of tasks into a single group of transactional work. The UnitOfWork pattern is the solution to sharing the Entity Framework data context across multiple managers and repositories. The UnitOfWork pattern allows us to execute a single database transaction (implicitly as part of the Entity Framework), which spans across multiple blocks of code, methods, classes, and repositories.
There are two primary ways to implement the Repository and UnitOfWork patterns. One method allows individual “using” blocks, similar to the above code, but sharing the context between them. For example:
public static class DragonRepositoryManager
Notice in the above code, we’ve shared the Entity Framework’s data context across the two repositories. Both, the Dragon and Weapon repositories are using the same data context to persist and query in the database. The UnitOfWork pattern, in this case, holds a copy of the data context and passes it to the repositories for usage. The actual database SQL execution is delayed until calling uow.Commit(). We can implement this design using the code shown below.
The design for the basic Repository and UnitOfWork pattern can be implemented with the following code, with original design from Revisiting the Repository and Unit of Work Patterns with Entity Framework EF4.
public interface IUnitOfWork
With the framework setup, we can define the concrete repository implementations as follows:
public class DragonRepository : Repository<Dragon>
While the above design allows us to share the Entity Framework context across repositories and query within individual using blocks, it still doesn’t allow us to share a context across multiple classes or repository managers. For this, we would need to pass the UnitOfWork around between the classes. Rather than passing the UnitOfWork object, we can instead create a static global implementation, per http web request, which may better suit an enterprise architecture.
Another method for managing the Entity Framework Repository and UnitOfWork pattern is by using a global UnitOfWork object. The UnitOfWork object will have a lifetime of a single HTTP web request. Once the web request completes, the Entity Framework context is disposed. This can be considered as having one big using block around the web application code-base. In this design, each repository can query against the Entity Framework ORM, without requiring individual using blocks. Once all necessary business logic has been performed, a final UnitOfWork.Commit() can be called to execute the database queries and persist data.
For example, the global UnitOfWork pattern allows us to utilize code as follows:
Notice in the above code, the main method calls two separate repository business managers, which query two individual repositories. The actual database execution is delayed until the final UnitOfWork.Commit() call is executed. This allows the complete unit of work (creation of a Weapon and a Dragon entity) to occur within the same transactional context. We can easily call multiple repositories across methods and classes, and still utilize the same UnitOfWork database context. The actual context is persisted per HTTP web request, allowing a thread-safe solution. The global Repository and UnitOfWork pattern can be implemented as discussed below, with original design from Entity Framework 4.0 POCO ObjectSet, Repository and UnitOfWork.
We’ll define three generic interfaces to support the repository pattern, unitofwork pattern, and a factory for producing UnitOfWork objects.
public interface IRepository<T> where T : class
By using a generic template interface, we can bind repositories to individual Entity Framework entities and reuse the same interface for all required repositories. In effect, each entity in the database will have its own repository.
The core to the global Repository and UnitOfWork design is the base UnitOfWork class itself. This class will take care of providing a thread-safe unit of work pattern, committing data, and persisting itself for the lifetime of the context. For web applications, the lifetime will be per HTTP request. For desktop applications, the lifetime will be per thread.
public static class UnitOfWork
Notice the above code is using the HttpConext.Current.Items array to store the actual UnitOfWork context. For web applications, a new context will be created for each web request. We can create a concrete implementation of the UnitOfWork interface, specifically for the Entity Framework, as follows:
public class EFUnitOfWork : IUnitOfWork, IDisposable
The above implementation of IUnitOfWork simply wraps the C# ASP .NET Entity Framework. The constructor takes an ObjectContext and implements committing the changes and disposing of the context. The Dispose method will be called automatically by garbage collection. However, to tie up loose ends, this method can be called from the Global.asax event Application_EndRequest().
To help decouple the UnitOfWork implementation details from the layers of the design, we’ll include a factory pattern, as follows:
public class EFUnitOfWorkFactory : IUnitOfWorkFactory
The factory pattern simply calls the delegate method for instantiating a new UnitOfWork context. We’ll provide the setup for this delegate method in the initialization code for the C# ASP .NET web application, similar to the following code:
// Select an Entity Framework model to use with the factory.
With the UnitOfWork implementation complete, we can define a concrete base class for the generic repository pattern. This implementation will be designed for the Entity Framework.
public class EFRepository<T> : IRepository<T> where T : class
The above repository implementation obtains an Entity Framework context from the UnitOfWork class. It also instantiates an ObjectSet collection for the specific entity this repository will handle. The repository class also provides a set of common query methods for accessing the entity data, with support for LINQ queries.
Initializing the repository pattern can be performed within the Global.asax event Application_Start() as follows:
// Setup StructureMap to determine the concrete repository pattern to use.
The Repository and UnitOfWork pattern are now complete for the Entity Framework. While the repositories provide the necessary methods for querying the Entity Framework objects, most C# ASP .NET web applications will require additional business logic for manipulating entities and persisting data. This type of logic can be added within manager classes, which wrap the repositories, and utilize/share the global UnitOfWork object.
Example Using the Repository and UnitOfWork Pattern
protected void Page_Load()
Notice in the above code, we’ve created individual business managers, which wrap the repositories. This allows us to perform specific business functionality along with the processing of Entity Framework repository entities. The managers themselves do not commit to the database, although they certainly could if required. Instead, upon an HTTP request, any business logic executed will queue up SQL calls to finally be executed at the end of the web page event, providing a single transactional event per web request.
We take advantage of the Global.asax EndRequest event to dispose of the UnitOfWork and Entity Framework context. While disposing would occur automatically via garbage collection, and database connections are automatically managed by the Entity Framework context (opening and closing the database connection only upon calling SaveChanges), it’s still good practice to be aware of the physical creation and disposing of the context. An added benefit to the design of the business managers is that they provide an easy access point for unit testing and TDD test driven development.
You can download the example source code for this project here.
The C# ASP .NET Entity Framework is a powerful ORM for managing database entities in an object oriented design. By enhancing .NET web application design and providing a Repository and UnitOfWork architecture, benefits can be achieved in code reuse, maintainability, and support for unit testing. Two primary implementations of the Entity Framework Repository and UnitOfWork pattern provide a design for persisting entities within individual blocks of context or via a global context per web request. The Repository and UnitOfWork pattern provide a solid architecture to help take C# ASP .NET web applications into the future.
This article was written by Kory Becker, founder and chief developer of Primary Objects, a software and web application development company. You can contact Primary Objects regarding your software development needs at http://www.primaryobjects.com