There are two series (commercial) over at Tekpub aimed at NHibernate and Entity Framework 4, it might be worth checking out.
Robert Blixt, Sep 10, 2010
So, I decided to take a closer look at this and briefly what I discovered is that I don't like the Wiki implementation because it leaves concrete dependencies inside the factory itself, where as the GO4 design keeps the factory loosely coupled and follows the Open/Closed Principle, which states that the code should be open for extension, but closed for modification. The factory itself shouldn't need to be modified every time a new concrete class is added. So I think we agree if I'm understanding you correctly. Someone should probably suggest an update to the Wiki.
Jul 29, 2010
Sorry, but NHibernate is not part of our Design Pattern Framework. To maximize the learning experience we've tried to keep things as simple (and yet complete) as possible, which is why there is a minimum of external 3rd-party dependencies (Moq being the only exception).
I am not an NHibernate expert, but for what it is worth, I read an article today where it was stated that with the latest release of Entity Framework 4 it is ready to take on NHibernate:
Again sorry. If the inclusion of NHibernate was critical to you, remember that we offer a 60-day money back guarantee.
Dan McMillan, Sep 10, 2010
Thanks. Apart from checking if there are variations, I wanted to know if both forms are correct or not. The stark difference between the 2 designs, i.e. not requiring to instantiate the Concrete Factory class, made me believe that these are 2 different designs altogether. Also, I couldn't think of an example where I'd need to explicitly create an object of Concrete Class rather than use its static method which return the product class object. Wouldn't it be an efficient design of the two?
Jul 29, 2010