Steve Gentile recently directed me to Udi Dahan’s recent post his improvement on the Domain Event pattern, and after reading the post, digesting it and thinking about his approach I have decided to include it into NCommon. The Domain Event pattern aims to provide a solution for being able to create fully encapsulated domain models. The term fully encapsulated domain models refer to the approach where the entities in your domain model are not bound or depend on external services for any purpose or operation. A good example for this, although a beaten to death example, is...

Oren’s recent posts on the Repository pattern and ORM have raised a hornets nest and intense discussion on the pattern itself. You can read them @: Repository is the new singleton, Mocking NHiberante and The DAL should go all the way to UI. In this post I’ll give my 2 cents on the points made in Oren’s post. Lets start with the post: Repository is the new singleton. Now I had a very similar discussion with Oren a few weeks back and judging by the comments in that post my reaction was quite similar. I have had some time...

This is part of a continuing series of posts on Fluent NHiberate. Using Fluent NHibernate in Rhinestone – Part I In this part I’ll show how you can map custom user types using Fluent NHibernate. In a previous post I had discussed the need to use custom user types in Rhinestone and had ended with a promise to have a follow up post on the details on implementing the custom user type and provide mappings for using that custom user type in NHibernate....

One of the additions to NCommon I haven’t blogged about yet is an implementation of a fetching strategy in NCommon First a brief background on Lazy / Deferred Loading: Most ORM’s provide a concept called lazy loading of related entities. The concept of lazy loading should be well known but if you’re unfamiliar with it here’s a brief overview. Lazy loading, a.k.a deferred loading, is the concept of loading associated entities from the database at the time of access. Meaning that say you have an Order object that has a list of OrderItem entities that represent...

I’ve been pretty lax on my blog posting for the last three months, primarily because some other things in life had higher priority. In the mean time I’ve received a few comments on when I will resume blogging again. Now that things have normalized a bit hopefully I can get back to blogging more frequently now. For all those who left comments while I was away, thank you for continuing to visit my blog (it feels good to know I have somewhat a following :P) and I’ll try to keep the posts coming. [Edit: There was a minor mistake...

I have created a new project on CodePlex called it NCommon. This CodePlex project hosts the entire source code of all the various frameworks and patterns that I have talked about on this blog. Previously the source was coupled with Rhinestone, the bug reporting app I am working on. While that seamed fine for a while, I started to realize that all the framework level stuff could be bundled up as a separate library that could then be used in multiple applications. Hence the creation of the NCommon project. I intend to put all common framework level stuff...

In the previous post; The Unit of Work Pattern I put down some thoughts on the Unit of Work pattern. In this post I delve into implementing a Unit of Work framework that allows persistence ignorance and provides a base for a unit of work component that I can use in Rhinestone. Note: It would be highly rude of me to not mention that a lot of the ideas around UnitOfWork comes from Aynde’s excellent implementation of the pattern in Rhino.Commons. Even though Aynde’s implementation can be taken as is, I wanted to start with a framework that provided...

This post assumes you are aware of Dependency Injection pattern and what Inversion of Control containers are. If not, I would recommend reading this post: Building a generic IoC wrapper or google Dependency Injection and IoC to get some background information. Okay anyone who follows DDD, patterns or cares about data access knows about the Unit of Work pattern. The concept isn’t hard especially when you’ve had to work with transaction and synchronization issues when dealing with a single logical operation that is composed of multiple database operations. The problem. Consider you have a order dispatch...

IoC containers are great at reducing complex dependencies in an application and the Dependency Injection design pattern has existed for quite some time. Although IoC containers are quite popular in the Java world but it’s taken some time for good IoC containers to emerge for .Net. Even MS has jumped on the bandwagon and is showing some love for IoC by giving us Unity as an IoC container. Today there are many, many IoC containers to choose from. That’s the one thing I really like about the ALT.Net community, varied implementations and depth of choice that allows us to...

[Edit: Fixed the url to the source code.In my previous post, Implementing Repository and Specification patterns using Linq, I implemented a Repository pattern that allows consumers of the repository to use Linq to query the repository. Along with implementing a Repository pattern I also implemented a pattern for defining Specifications that could be used by not only Domain objects but also can be used with the Repository implementation for querying. In response to that post, there were a number of comments regarding how the RepositoryBase could be used to implement a Repository for Linq to SQL and also questions...