Thursday, March 26, 2009

NCommon, a promising patterns framework

Since a few days ago I'm trying to apply some DDD patterns to one of my current projects.

In particular I'm specially interested on the Repository Pattern so popular this days. Which, for those of you which didnt know it, a repository pattern is an abstraction pattern which: "Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects." (From Martin Fowler web site).

I think this project will seriously benefit from using this patterns as well as a few related patterns, like the Specification Pattern, which it also helps implementing. This in fact will allow us to achieve a better separation of concerns, as well as adhering to persistance ignorance principles.. which beliveme, is "a really good thing".

But, as you might think, selecting a pattern is just a portion of the work, as we also needed to find a way to implement this patern and refactor our current project's code which, by the way, is based on .Net, Linq2Sql, and SqlServer, on what relates to data access layer.

As usual I started by searching related blog posts, sample implementations, etc. in order to have a better picture about how to implement this pattern. As this is a hot topic this days, you may guess that I found a few resources available. After a few hours reading, processing, and also discarding, many of this resources, I finally found a project on codeplex called NCommon which was nearly an 75% of "what I was looking for" (tm).

NCommon is, as it's author describes it is: "a library that contains implementations of commonly used design patterns when developing applications".

In fact, it covers things like:
  • UnitOfWork Pattern
  • Repository Pattern (with underlaying support for Linq2Sql, EF and NHibernate)
  • Specification Pattern
  • Business and Validation Rules (based on it's Specification Pattern implementation)
  • Per Application/Session/Request storage capabilities
After looking at the code, reading a few blog articles from it's author, analicing it's strenght and design, and also, considering added benefits relating to the fact that some time later we will switch our ORM technology to something "bigger" like NHibernate or, maybe, EF. This library seemed the best approach to help us implement our goals.

But, as usually, nothing is perfect, and while NCommon covers a high percent of what we needed in terms of framework, I faced a few bugs and a few shortcommings using this library.
As thus, in this and on a few following posts I will try to document my findings, as well as the additions, modifications, etc. I did to NCommon to make it a bit more feature rich.

Just in case you were wondering, this are some of the things I'm currently working on adding/fixing to NCommon:
  • Using interfaces instead of concrete objects at the repository level. (And at the same time, with linq).
  • Being able to use (¿inherit?) ambient transactions on UnitOfWork scopes.
  • Find a solution to the "Paging problem" on the repository level.
  • Fix a few NCommon shortcommings like: IRepository<>.Attach method not working on Linq2Sql repositories. Or, not being able to combine ISpecification<> objects.
If you are interested on any of this topics, keep watching, as I will be writing shortly about each of them..

No comments:

Post a Comment