Unit of Work & Repository support for multiple frameworks, part 2
By Rob Jones | March 13, 2011
Quite a while ago I made a post about creating a unit of work and a repository that would allow me to swap between Entity Framework and NHibernate relatively quickly. In the past few weeks (or have they turned into months already?!), I received a few requests for a sample project to show how this can be implemented and used in a real world scenario. I sat down to work on it this weekend and I’m happy to say I managed to finish a working sample project.
Click here to download the sample project.
Keep in mind that I won’t take responsibility for any of this code if you decide to deploy it in a production environment. However, feel free to use this code for your own projects and modify it to suit your own needs. It’s only meant to provide a sample and show a way how to implement repositories that are not dependant on a specific type of framework.
I truly hope my efforts are appreciated and that it can be a learning experience for everyone who requested a sample project on this issue!
Everything you need should be included in the package.
Binaries
- Castle Windsor 2.5.2
Inversion of Control and Dependency Injection container. - NHibernate 3.1.0
ORM framework based on the famous Hibernate for Java.
Documentation
- Read Me (How To).docx
Explains how to get started with the sample project and what needs to be done to switch between Entity Framework and NHibernate
- Technical documentation.docx
It’s not really technical documentation as such. Just a few points to note. I haven’t been able to find the time to sit down and properly document things. I will do so if it proves to be necessary, but I think things are easy enough to understand for the average smart developer!
Source
All projects and source-code can be seen by opening up the MultiRepository solution file.
7 Comments
Pingback: Letting your UnitOfWork & Repositories support multiple frameworks | Storm in a Jar
nhef on March 14, 2011 at 3:21 pm.
Thanks!
I’ll give it a try as soon as possible and try to give you some feedback.
lex on June 1, 2011 at 4:21 am.
Hi,
Thanks for this great sample. One questions, how do you expose the unit of work (commit, rollback) since you state in the comments to only expose the factory.
I added the commit and rollback methods to the irepository interface but that feels wrong.
Rob Jones on June 1, 2011 at 7:41 am.
The Commit() and Rollback() methods definitely belong in the UnitOfWork.
The comment in the code to only expose the factory was more related to Castle Windsor. The idea is never to expose the container itself to the application. However, it’s fine to expose the typed facility factories.
By calling the Factory.Create() method a UnitOfWork is given to you. In a way, you could say that the factory class exposes the UnitOfWork for you.
I hope this helps!
lex on June 6, 2011 at 3:40 am.
Thanks Gronak, I see what you mean. Great Post.
nhef on June 13, 2011 at 6:29 pm.
Thanks a lot again for the sample! It’s been of great help.
I’d like to ask you if you have any idea on how I could load the ConnectionString for Entity Framework dynamically. That is, I need to let the user decide which connection to use and take it as a parameter for my repository.
I know this is possible on NHibernate with NHibernate.Cfg.Configuration (that’s what I’m trying ro replicate in EF) but have no idea on how to solve this for EF.
Thanks!
Rob Jones on June 15, 2011 at 9:10 am.
Good to hear that the sample project has been a help for you.
It’s been a little while since I’ve worked with EF4, or did any work on this project at all actually, but doesn’t the ObjectContext constructor have an overload that passes along the ConnectionString as parameter?