Deeper integration with qTest Platform: create/submit test cases as well (real time) upload recording session to qTest that can be reviewed/edited/playback later from qTest. User can also be able to submit defect to JIRA using an alternative Native form which they are very familiar with

Beside desktop, there are also other editions: Web and Mobile eXplorer that might fit into the need to capture recording session on Web browsers: Safari, Firefox and Google Chrome (Windows, Mac) and on Mobile devices (iOS, Android)

If you’re looking for an exploratory testing tool, give qTest eXplorer a shot.

Our team has just released qSnap, a free product of QASymphony to capture webpage screenshots running as a browser extension on Chrome, Opera and Safari, an add-on on Firefox or a plugin on Internet Explorer.

To be able to share links to your screenshots, you must first register an account with our free hosting service at https://qsnapnet.com/. After registered successfully, you can start to capture any web page screenshot, annotate then upload it to your account. Each uploaded screenshot has an Url that you can share with your friends or to social networks. You can also manage the captured screenshots by logging into https://qsnapnet.com.

I am happy to announce that the framework has been upgraded to target .NET 4.5, Entity Framework 5 and Visual Studio 2012. This post is also a response to someone asking me when should the framework being upgraded to Entity Framework 5.

Some notes regarding this upgrade:

– The source code is now restructured to two versions: one for .Net Framework 4.0, the other one for .Net Framework 4.5. You can access to the source code at http://ef4prs.googlecode.com/svn/trunk/ef4prs-read-only. However, the download page only shows specific versions for you to choose which version that best fits your need.

– Removed repository implementation against ObjectContext, this means the repository is now interfacing mainly with DbContext (not a Lab version anymore). So, if you prefer to work with DbContext, you can get the framework up and running quickly. On the other hand, if you want to work with ObjectContext, this is also easy by upgrading/migrating code from .NET 4.0 version.

That’s it! Not much changes from this upgrade, but that’s a good sign to me since EF 5 does not break some low level code.

It’s the statement in the video introducing the product we have been building and just released recently, qTrace.

After many years working on outsourcing projects, I am very excited to be involved in building a product which I myself can be proud of. Now I can talk to my mom: “Look, mom, that’s the one we build. It’s qTrace” 🙂

For those who interest in the technology stack we use to build qTrace:

Dependency Injection (DI) design pattern has become more and more popular in software development recent years. There are many open source frameworks that help us apply DI design pattern out there, like Castle Windsor, NInject, StructureMap, Unity,… just named a few. From my point of view, using a framework for DI means using an Inversion of Control (IoC) container to wire up the dependencies between objects and let it manages their life cycles after registering the object graphs with that container.

Almost softwares I built in recent 2-3 years have been applied DI design pattern with a help of an IoC container. For what? you may ask. Well, I think the benefit of applying DI is that it allows me to design loosely coupled objects to ease unit testing. At run time, the IoC container helps wire up all the dependencies between objects for me.

After reading those two articles and agreed with the authors, I realized that I have used the static IoC container in many softwares I built. So I decided to re-factored our code to avoid doing that wrong thing again. The IoC container that I am familiar with is Castle Windsor. I used it from the time I knew what DI is, and I am still using it just because I like the way to register types with IWindsorContainer using fluent interfaces that is very readable.

To demonstrate, here is an ASP.NET MVC application that used the Service Locator to resolve the services on which a controller depends.

The IoC.Container static property will be assigned to an instance of WindsorContainer class in the global MvcApplication (Global.ascx.cs) and it as well will be used to register types at web application start up:

Now I am using an IoC container badly and _without_ dependency injection. So how to apply DI correctly, you ask? The solution is to get rid of static IoC container and remove the dependency to that container from not only the controller(s) but also anywhere on the code, except the code that instantiates the container and registers the object graphs in the global MvcApplication.

We also need to implement a custom controller factory that is responsible for creating an appropriate controller and also injecting the services on which that controller depends. Here is the custom controller factory which inherits from ASP.NET MVC’s DefaultControllerFactory class:

Now I am using DI correctly. But there still is a problem to me: since I want to use dependency injection, I have to list out all the dependencies to services in controller constructor, here I use constructor injection or I may opt to use property injection. Both ways leads me to have a ‘greedy’ controller because there are controller’s action methods being invoked that do not actually use any of dependent services at all!

After a while looking for a way to solve the problem, I found that Castle Windsor has a feature called TypedFactoryFacility that allows us to define an interface as a factory which, once registered with the container, will resolves the types for us on behalf of container. Note that we don’t need to provide any implementation for that typed service factory interface at all.

You might have been aware that MS just released Entity Framework 4 CTP5 some days ago. There have been some comments asking me when the data access layer would be upgraded to that version. Since I had been quite busy these days, the answers for these questions was just a promise that I would do the upgrade when I had time after I finished investigating the new release carefully. However, some readers seem to be anxious waiting for the code updated so they keep asking me for the progress (and I feel good because I know there are some ones who are interested in the framework I built :)).

– We do not need to register entity any more, just add mapping class(es) to the ModelBuilder then we are all set. Well, this is for your information only, since this framework will do this automatically in the XContextBuilder class.

– The most and important thing, I think, is EF now will automatically map entity relationships without explicitly writing the mapping code. For example:

I have an entity Customer that has many Orders. These two classes will be defined as below:

After the post Entity Framework 4 POCO, Repository and Specification Pattern was published for a while, there have been quite a few of positive comments from readers. At first, I thought that this piece of code should have been used as a prototype to demonstrate the implementation of EF POCO, the Repository and Specification pattern. I known it is not the optimized piece of code to everyone and that if there was suggestion for improvement, I would leave to reader as I thought once they understood the design idea, they could extend/change/use the API in anyway they want.

However, there are also some comments concerning about the way the Specification pattern is applied which might cause the BIG performance problem when used that I was not aware of. Even I am using this API in my current work but it’s a shame that I rarely use Specification to query the data but the other methods are enough for me.

For your information, here are the extracted comments from Jon & Buu (many thanks :)) which pointed out the problem:

“Jon: Linq to Entities uses expressions to build the SQL that will be executed on the database server. If you use the specification pattern as designed above, i.e., without expressions, the generated SQL is never impacted. Instead, EF will generate “SELECT * FROM Table,” returning all rows. From there the specification pattern kicks in and filters the data in memory. Your test passed because you got the right result, but not in the right way. it would never work in a real would scenario.”

“Buu: …the cause of the issue as Jon observed is because the method (IsSatisfiedBy) of Specification is fed into the Where method of the query object. That results in LINQ-2-EF loading all records to memory objects and then filter those objects using the passed in method. That’s a huge performance hit.

To fix the issue, you should feed into the Where method an instance of Expression so that the Where overload in IQueryable is invoked (instead of the one in IEnumerable). The Specification already stores an instance of Expression, so the code change should be straightforward. However, since not all expression operations are supported by LINQ-2-EF, you might end up breaking some existing code. Be warned…”

I verified the problem with Entity Framework Profiler and I have to say the problem is there. Here are some tests I made to retrieve a product by name, and also the results from the profiler:

As you can see there is a problem with using specification to retrieve a product in which EF loads all the products from the database, then perform filtering a product against the whole set of products in-memory. If the number of products is huge, it really is an issue since the query is not efficient at all.

This is because the specification pattern is implemented incorrectly. To fix it, I change the specification contract as the following:

Here is the output of the profiler with the new specification implementation:

As you can see EF now generates the expected sql and returns expected result as well, very efficient.

What about the composite specification?

If you already read the previous post, you should have known that the composite specification was being used to chain the specifications. With the new implementation of specification, the composite specification implementation also needs to change. The technique being applied here is to combine the lambda expression (or predicate) of each specification (left and right side of a composite specification) to create a new lambda expression then this new lambda expression is fed to the IQuerable object for querying.

Here is the code of the extension method of lambda expression which is mostly inspired from here:

Updated (25 Aug 2010): There are some concerns from Jon and Buu about the performance hit when implementing the specification pattern follow the way that this post shows. That said, the implementation of this pattern has been updated and you can read it through at Specification Pattern In Entity Framework 4 Revisited

Updated: The post has a small update with the new release of Entity Framework Feature Community Technology Preview 4 (CTP4) in which the ObjectContextBuilder class changed its base class from ContextBuilder<T> to ModelBuilder. The source code has also been upgraded to CTP4 version. Note that to successfully compile the code, you have to install the EF CTP4 version which can be downloaded here.

After a decent period using NHibernate & SharpArchitecture to build .NET application, I eventually have a chance to work with Entity Framework (EF) in recent project. The client wants to leverage MS technologies as much as possible instead of some OSS frameworks to avoid learning curves and maintenance issues that might occurs later on. No matter what the decision is good or bad which some of you might agree or disagree, I am being put in a position to build the application with the team. And just because I have had some experience on building data access mechanism (mostly with ADO.NET and NHibernate), this more or less leads me to work with this data access layer again.

Just like those who are going to work with a new technology, I started digging into EF by reading related books, hunting the web to find good articles and blog posts mentioning about building data access on top of EF. Since I have worked with NHibernate and also use Repository Pattern to build the data access layer, the keywords entered Google should include: “Entity Framework”, “Entity Framework Repository”, “Entity Framework vs. NHibernate”, “Entity Framework POCO and Repository Pattern” blah blah blah. Luckily I found quite a few of good posts (these will be listed as source of references at the end of this post).

With some sources of reference in hand, I started to build the data access layer using EF. But before talking about how I build it, here is a set of design patterns I want to apply: Repository, Unit of Work, and Specification. Since I also want to use POCOs instead of objects auto-generated by Visual Studio so this, once again, leads me to looking for the technique to write mapping stuff, and I found that it is also very easy.

Repository

Repository is defined as “an abstraction that provides us with persistence ignorance and a separation of concerns where the responsibility of persisting domain objects is encapsulated by the Repository that leaving the domain objects to deal entirely with the domain model and domain logic.”

The contract for a repository contains operations to perform CRUD and also for querying entity objects. The general technique is using .NET generic to build the Repository, the code below depicts the contract of repository:

As you can see, the repository use a generic type of TEntity to represent an entity that we want to manipulate. Suppose we have an entity named Customer, when we need to perform operations on Customer entity we will do something like this:

But I find it a bit inconvenient since we have to create multiple repository instances in case we want to work with multiple entities at a time. In other words, if we want to perform operations on n entities, we have to create nearly n repository instances (I am saying ‘nearly’ because if an entity is not an aggregate root, we do not implement a repository for it), like the code below:

With this repository we can now create only one repository every time we need to retrieve or persist an entity, we can even make this repository an instance member to be retrieved across class methods. Here is the new AddOrders method using this new repository:

Of course one also creates the specific repository to widen the contract using inheritence (like CustomerRepository above) or narrow it using adapter if she wants to.

Unit of Work

The EF ObjectContext does this work for us in regarding managing UnitOfWork. It is already able to handle transaction across many operations over many different types. All we have to do is to call SaveChanges method on the ObjectContext instance as described in the above test code.

With the current implementation so far, we now have a handy generic repository to be used for data persistence and transaction handling. But there is a slight issue with this implementation. The problem being, if I had multiple POCO objects, for instance, Repository<Customer> and Repository<Product>, we would not able to run queries across both, as they would be created via different instances of ObjectContext and this leads to losing any level 1 caching.

A common solution is to build a object context factory. Every time we need an object context instance, just delegate this work to this factory class. Here is a possible implementation:

At this time, I again find another inconvenient way to manage the object context. Look at the code above you will easily find that every time we work with another type of object context in another application, we have to rewrite the factory in order for it to return the actual type we need instead of the example NorthwindEntities. Is there a way to make this factory class unchanged so that we can reuse it in every application that works with any concrete instance of object context?

This reminds me about the NHibernate session manager implemented in SharpArchitecture code base. So I decide to write an object context manager which acts like that session manager. Its responsibility is to provide a mechanism to create context on demand, and it also provides a storage mechanism which is context-dependent (http context, wcf, and so on) to store object context.

As you can see, ObjectContextManager delegates the job to create an object context to a so-called ObjectContextBuilder class. The main responsibility of this class is to create an object context using the provided connection string and also to look up and configure the entity mapping classes. This class constructor accepts a connection string name and an array of mapping assemblies, which contain entity definitions and mapping classes, for it to create an object context (these two parameters was provided during application starting up by calling method ObjectContextManager.Init(…)). If you have ever used SharpArchitecture code, you can see it is almost the same as NHibernate’s SessionFactory class.

Updated: ADO.NET team just announced the release of Entity Framework Feature Community Technology Preview 4 (CTP4) which splits ContextBuilder into two components, ModelBuilder and DbModel. The definition of the two new classes are as “ModelBuilder is mutable and exposes the fluent API for defining your model. ModelBuilder creates an immutable DbModel type that can be used to construct an ObjectContext or DbContext. DbModel can also be constructed from a Database First or Model First approach where an edmx file is generated.” Here is the updated ObjectContextBuilder class which replaces the inheritance from ContextBuilder to ModelBuilder class. Note that to make the code compilable, you must install the EF CTP4 version

With this ObjectContextManager in hand, I re-factor the Repository class by removing the dependency to ObjectContext in its constructor, every time it needs a ObjectContext, it will ask the ObjectContextManager to provide.

According to Martin Flowler, the idea of Specification is to separate the statement of how to match a candidate, from the candidate object that it is matched against. As well as its usefulness in selection, it is also valuable for validation and for building to order. You can also follow the Specification white paper by Martin Flowler if you want to indulge yourself deeply into this programming pattern.

In simple terms, it is a small piece of logic which is independent and give an answer to the question “does this match ?”. With Specification, we isolate the logic that do the selection into a reusable business component that can be passed around easily from the entity we are selecting.

Okay, it is enough for introducing specification pattern. Here is the specification contract:

At this point, I think of a technique to chain the specification called composite specification. Why not apply to make the specification flexible and reusable? Here is the code which is mostly inspired from this post: