Using Effort in complex applications

In a previous post some of the basic features of the Effort library has been introduced with very simple code samples. You might have asked: okay, but how should I use this tool in a complex application? This post tries to give an answer to this question.

Applications have to be designed properly in order to make them easily testable. A traditional technique called decoupling is widely used to achieve testability. It means that your system has to be built up from individual pieces (usually referred as components) that can be easily disassembled and reassembled. A previous post demonstrates a technique that makes possible to decouple Entity Framework based data driven applications. Do not continue without reading and understanding it! The solution presented here relies on the architecture described there.

In a complex application more instances of the same type of ObjectContext might be used during the serving of a single request, these ObjectContext instances usually have to work on the same database. The ObjectContextFactory class of the Effort library is only capable of creating individual ObjectContext instances without any relation between them, so each created ObjectContext instance works with a completely unique fake database. If you wanted to create ObjectContext instances that work on the exact same database, you should create a fake EntityConnection object and then pass it to all ObjectContext instances. The Effort library provides the EntityConnectionFactory class that was created for exactly this purpose. Its factory methods accepts an entity connection string as argument and retrieves an EntityConnection object that will communicate with an in-process in-memory fake database.

But how should this factory class be used in the architecture that was presented in the mentioned blog post? There are two kind of possible injection points in that system: slots with IObjectContextFactory or IConnectionProvider interfaces. The latter is just ideal for this scenario, because a single connection provider component is shared among the different data components, so they can use the exact same connection object. Before creating the fake component, lets take a look on the implementation of the original production component.

public class DefaultConnectionProvider : ConnectionProviderBase
    protected override EntityConnection CreateConnection()
        return new EntityConnection("name=ClubEntities");

The ConnectionProviderBase class made the implementation really self evident. This base class can be used to create the new fake connection provider component too. Simply use the mentioned factory class of the Effort library to instantiate the fake EntityConnection instance.

public class FakeConnectionProvider : ConnectionProviderBase
    protected override EntityConnection CreateConnection()
        return Effort.EntityConnectionFactory.CreateTransient("name=ClubEntities");

That’s it! Now just use the FakeConnectionProvider class instead of the DefaultConnectionProvider class (in the same way) and the data operations initiated by the data components will be executed on a single in-memory fake database. In this way automated tests can be created without the dependence on the external database.

As shown, using the Effort library in complex data driven applications could require precise architectural designing. However, in a properly built up system it can be integrated without too much effort.


One Response to Using Effort in complex applications

  1. Pingback: The value of integration tests + tools to make them easier to write | Campus Management Community

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: