thoughts on coding

February 21, 2011

EFv4 with Repository and UnitOfWork pattern, IoC, DI

Filed under: Di Factory, IoC, NCommon, Uncategorized — Tags: — Frantisek @ 9:33 pm

Entity Framework itself implements unit of work pattern in form of the ObjectContext class. That’s fine but it has the following main disadvantages:
a) if you will use it from your business layer then you will be very tightly connected to the concrete DB layer implementation (in this case Entity Framework)
b) it will be much harder or impossible to do TDD.

It’s good practice to wrap the data access logic using Repository pattern. In other words it’s good to use the Repository pattern in order to abstract out/decouple the business layer from the data access layer. Fine, there is one Repository patter definition but many implementers and you can implement it also by your own. The basic idea is the same but many slightly different implementations.

When you work on different projects developed by the different people it’s good to establish enterprise-wide implementation of any common patterns/areas. Additionaly, it would be better if ti would be world-wide known implementation. So that’s NCommon which you can find on

NCommon provides, we could say, abstraction of the common programming areas like Repository, UnitOfWork, Guards, States, etc. In this entry I’ll focus on Repository.

NCommon provides the abstract Repository implementation – independent from any specific/concrete DB access implementation PLUS it contains implementations for Entity Framework, NHibernate, Db4O, etc. All specific implementations are located in its own projects. The advantage is that you can use out of the box implementation of your favorite implementation.

In addition, the base abstract Repository class offers LINQ provider on Class Level, not property level. Honestly, I like it ;o). Here is a sample:

using (var scope = new UnitOfWorkScope())


    var savedCustomer = new EFRepository<Customer>()

        .First(x => x.CustomerID == customer.CustomerID);




In addition the base NCommon Repository classes are tightly connected with UnitOfWork pattern which is also abstracted into NCommon in form of UnitOfWork classes. You can get it also out of the box together with the different DB access specific implementations!

The unit of work implementation IS NOT ONLY 1 CONNECTION specific but spreads over different repositories and over different DB connections (if it’s your case). In other words, you can have i.e. a users repository implemented by NHibernate and connecting to UsersDB and OrdersRepostory implemented via EntiryFramework connecting to OrdersDB and the following example works:

In other words, one connection transaction will be elevated to the distributed transaction transparently and automatically. I like it! It seems to me really robust.

ALL is supported by standard service locators implemented by Microsoft Patterns and Practices team and with the NUnit tests!

I think, NCommon is really cool set of classes which collects the common aspects you will face while development. It’s really worth studying it! Here is a list of the links you can use:

Anyway, cool way how to check the latest library description is to look at the unit tests from GitHub.

Happy common coding !

August 11, 2010


Filed under: ASP.NET MVC, Di Factory, IoC, MVCContrib, NHibernate, StructureMap, Uncategorized — Frantisek @ 1:36 pm

I read MEAP version of the book ASP.NET MVC 2 in Action from Jeffrey Pallermo last month and I’d like to share my point of the view.

The book shows you how to use ASP.NET MVC 2 in Alt.Net (StuctureMap, MvcContrib, Rhino.Mocks, jQuery, NHibernate, NUnit, etc.) way – which I appreciate very much.

The book shows more how was built connected with ASP.NET MVC 2, what is the logic, tips and tricks behind the designed solution. I must say, I like it as Headspring designed it. I just would call this book ASP.NET MVC 2 in Action on CodeCampServer project.

If you want to download and understand the code quite deeply, read this book. The quys around CodeCamperver are really cool ;o)!

If you want to know more about ASP.NET MVC 2 in general than how to use ASP.NET in Alt.NET, way then read this book: Pro ASP.NET MVC 2 Framework, Second Edition (Expert’s Voice in .NET)

March 11, 2010

StructureMap v2.6.1 released!

Filed under: .NET, Di Factory, StructureMap, Uncategorized — Frantisek @ 9:30 pm

There is new version of really usefull library used for DI, IoC – called StructureMap – released. You can find more about that new version on the blog from Jeremy Miller, here

Jeremy explains what was changed there and what’s new but … we miss the up-to-date documentation ….

It’s really cool library, we use it quite much on our projects and it’s really a killer against other similar libraries (I’ll write a post about it later).  I was looking forward to check the new version and use it but here are my comments:

1) API was changed quite massively and there were made obsolete many methods and few were removed. I must say, that the comments used on the Obsolete attribute are not usefull in all situations the old version was able to be used (see example bellow).

2) The release is missing an up-to-date documentation describing how to migrate from old version to the latest version. The migration to the new version is not very straightforward, IMHO. The package (binaries), which you can download from here contains only binaries ;o), no documentation, no tests (which can act as a kind of the document as well), etc.


I think the NUnit tests are very good source of the documentation and explanation how to use the explored library and it should be UP-TO-DATE. So for all who wants to migrate to new version of Structure and dont want to wait for the documention or Jeremy’s blogs I propose the following:

download the full package which includes also NUnit tests 😮 from here (scroll down and take the latest commit, it includes more than 11MBs of data) and spend some time with analyzing code and NUnit tests.

My feedback

I really support the libraries with Fluent approach. Structure map has it but I think, some changes, which should be more fluent in the newer version are less fluent now.

Example: AsSingleton() construct replaced with Singleton(), as following:

I think, more fluent version would be:

I think it’s more fluent. I must say it took me a while to find it out, especially when old construct was completely different with AsSingleton() at the end ;o  I know, my suggestion i’s small change, but I would say, it would bring more fluent voice.

Another, but I think, bigger change was related to situation when we want to add the named instances to the container. It’s connected to the class IInstanceExpression<T> and its OfConcreteType<PLUGGEDTYPE>() method like on the following:

The obsolete attribute advice what to use is nice but useless in the situation when we use AddInstances() construct.

In this case we are not able to avoid using OfConcreteType<T>(). There are 2 possible solutions:

The first is to use the For<T1>().Add<T2>.Named(“name”) like on the following picture:


the old way which was used in 2.5.4 version:

and live with the fact that there will be warnings.

I checked the NUnit tests from StructureMap because I wanted to know how to use this construct correctly and I was disappointed that the there is used the OLD version of the solution (the obsolete methods with the warnings) like the following:


It’s a shame that the release 2.6.1 contains API changes but MANY NUnit tests uses old, Obsolete version of the API. So the documentation is not up-to-date nor the tests.

I think, the team shouldn’t change the API without changing the unit tests to use that new API and thus providing us a solution how to migrate from old  version to the new version.

Anyway, StructureMap is really nice library with many very useful features, going hand in the hand with TDD, Mocking, Plugins, etc. and the biggest advantage is the implementation of Convention over Configuration approach which is unique!

I hope Jeremy will have more free time to blog more about the newest version.

Blog at