The Entity Framework DbContext (or LINQ-to-SQL DataContext) is a Unit Of Work implementation. That means that the same DbContext should be used for all operations (both reading and writing) within a single web or service request. That means that there are a lot of different places where the DbContext have to be accessed. To avoid having to pass the DbContext around as a parameter, I’ve created a UnitOfWorkScope that makes the DbContext ambient and easily accessible.

A common beginners problem when working with Entity Framework or LINQ-to-SQL is to have too short life times of the DbContext. A problem that I’ve seen many questions about on Stack Overflow is when questions are encapsulated in repositories or helper methods. Inside each method a new DbContext is created for that specific read. Later, when the returned entity has been updated and is to be saved the problem occurs. The entity should be saved using the same DbContext that once read it from the database to allow change tracking to work properly. Clearly, having separate DbContexts is a problem.

The first attempt to solve it is usually to pass the DbContext around. That only solves half the problem though, that of accessing it. The other half of the problem is to decide where to call SaveChanges to persist the changes done. Calling it from every method making changes spoils the entire unit of work concept. Trusting the creator of the context to know when any of a myriad of called functions have made changes seems risky.

I’ve been looking for a better way to handle the DbContext and have come up with an ambient DbContext, using a UnitOfWorkScope which is similar to TransactionScope.

The main features of the UnitOfWorkScope are:

• The first method in the call chain opening a UnitOfWorkScope creates an ambient DbContext.
• Subsequent methods in the call chain utilizes the same DbContext.
• Changes are only saved if all participating scopes called SaveChanges
• Read only mode is available, where data is read using the existing DbContext, but no changes need to be saved. This is useful for GetSomeThing methods that are used both for pure reading and for reading for update.

• Continue Reading →

Design patterns are often presented as standard solutions that can be used to commonly occurring problems. I think that it is equally important to be able to recognize patterns in existing code. Being able to identify a pattern helps understanding the code better. It also helps rising the abstraction level. It can be used to describe the architecture of a system without having to describe each part in detail.

The architecture is Transaction Script based. The transaction scripts are located in the Logic namespace. The same classes are used both as Data Transfer Objects and as Query Objects. A custom Object-Relational Mapper is used for database access.

Without the patterns as a common basis for communication the same description would be considerably longer.

Let’s have a look at some patterns in C# development.

• Continue Reading →