I see files like Castle.DynamicProxy.dll or Castle.Core.dll or Castle.Model.dll and various others similar in projects that are supposed to be simple, noob's introduction to nHibernate. What does this Castle stuff have to do with nHibernate? Is this unadvised muddying up the waters by the tutorial authors or does nHibernate really require this sort of extra hoops jumping just to get the basics running?
NHibernate uses proxy objects to achieve lazy loading and uses the Castle DynamicProxy module. This is the reason your entity properties need to be virtual. Because NHibernate creates proxy classes that intercept calls to your properties.
Related
Now that I have a good handle on NHibernate 3.2 I now feel ready to use it in anger. What I need now is an ellegant way to inject the mappings I want from an IoC container like castle windsor or the like.
The project that I am working on requires 2 sets of mappings, one to a legacy database that needs to stay put for now and one to the new schema designed to replace the old database at some point in the future. Baring in mind that I am using mapping by code rather than xml mapping.
So at a controller/middle tier level you'd be injecting a repository that implements your ISomethingRepository interface and as a parameter into that repository somehow passing a collection of ClassMapping objects.
Any ideas about the best way to go about this would be appreciated. I'm interested in the general architecture which is why I'm not specifying an IoC container.
Why not have a SessionFactoryFactory which consumes a ConfigurationGenerator.
Due do LinqToSql not being appropriate for Many To Many relationships I am in the process of deciding to move to NHibernate (Fluent NHibernate) unless convinced otherwise...
Project Structure: UI (Mvc2 app with Ninject wiring up all services to controllers, and repositories to services), DomainServiceLayer (all util, helpers, services, domain model etc) and my Repository Layer for persistence. I have a another project call Model which basically exposes the entities, which all projects reference.
Basically I am creating my mappings within the Repository Layer with references to NHIbernate and Fluent NHIibernate, I hope to expose the interfaces to the Domain Service for querying and persisting data. How do I wire up the iSession, where do I wire it up? Any example code, what project should I put it in? Ideally I want to keep this within the Repository Layer... Is it worth learning NHibernate and going through all this?
I recommend looking at the blog posts of Bob. He describes in detail how to use the repository pattern in Ninject using NHibernate. I planned adding an example in the near future to the sample application comming with the MVC exptension as this question comes up again and again.
http://blog.bobcravens.com/2010/06/the-repository-pattern-with-linq-to-fluent-nhibernate-and-mysql/
http://blog.bobcravens.com/2010/07/using-nhibernate-in-asp-net-mvc/
http://blog.bobcravens.com/2010/09/the-repository-pattern-part-2/
Typically I have an NHibernateSessionFactory which is a singleton that has an OpenSession method and I bind ISession typically like this.
Bind<ISession>().ToMethod(context =>
NHibernateSessionFactory.Instance.OpenSession()).InRequestScope();
This method just calls through to ISessionFactory.OpenSession
You can put this into a NinjectModule in your repository layer, which your app can load when it creates the Kernel.
I do the configuration in the Application Layer (i.e. the top layer) as the configuration differs between applications. But it can be useful to break out some of the configuration into classes stored in the Repository Layer.
I open and close the session with an HttpModule.
I have come across fluent API's while studying DSLs.
I have searched a lot on fluent API's...the basic conclusion which I could draw was that fluent a API uses method chaining in order to make the code fluent.
But I cannot understand - in object oriented languages we can always create an object and can call the methods related to it. Then how is a fluent API different? What other features does a fluent API add?
With a fluent interface you write methods that return the object that the method was invoked on (usually self or this) and handle traditional return values as a state change in that object. If you look at say some of the Javascript libraries that use a fluent interface it makes it far easier to deal with lists and nulls as they can be handled the same way you would a single object. The disadvantage of fluent interfaces is that they tend to create monolithic god objects that have a whole heap of responsibilities.
I wouldn't want them to be used everywhere (because of the god object problem) but they are nice from time to time.
Your question is answered in the originating Fluent Interface blog post by Martin Fowler. The point is that the fluency in fluent API comes from the domain of a domain specific language, not only method chaining.
Fluent API is an advanced way of specifying model configuration that covers everything that data annotations can do in addition to some more advanced configuration not possible with data annotations.
And Web API is a programming interface/application type that provides communication or interaction between software applications.
I'm trying to send objects retrieved by NHibernate over WCF, but whenever a have a property of ICollection I get an exception.
When NHibernate gets the data from the database this property is intitialized with an instance of PersistentGenericSet.
Is there a way I can send a PersistentGenericSet over WCF?
-or-
Is there some way making NHibernate initialize these properties with another type?
The PersistentGenericSet is part of NHibernate (used to track changes in collections). It is based on the ISet interface and classes from Iesi.Collections, which was used to fill a gap in the .Net framework as there isn't a Set type. I guess that WCF has a problem serializing this type.
A quick fix is to change your NHibernate mappings to use a Bag instead of a Set. Then you can use a normal IList<T> instead of Set<T> in your classes w.
A better solution is to create a remote facade which sends DTOs to your WCF endpoints. This will allow you to keep the interface of your internal types separate from those exposed as remote services. Jimmy Bogards Automapper is a great tool which will help with the mapping process.
Edit
After re-reading the problem I had a look around the and came across this article which describes a workaround for sending NHibernate collections over WCF. David Brion has written a good follow up article.
I've just finished converting a large amount of legacy code to use NHibernate. The next thing I want to do is introduce an IOC container for hooking up the data access layer repositories and other such things. There are a variety of options out there at the moment - Castle Windsor, StructureMap, NInject, Unity etc; the choice is difficult.
Should I let the fact that NHibernate is already using Castle Windsor influence my decision?
I can imagine some potential benefits - for example lower memory usage. But there may be downsides, such as having to stick with the version of Castle that NHibernate is compiled against, rather than being able to upgrade the IOC container when I choose.
Thoughts?
NHibernate doesn't use any IOC container. It uses the Castle.DyanmicProxy project for creating proxy objects to facilitate lazy-loading (although this can be replaced with LinFu or your own proxy factory if you like).
You can use whichever IOC container you think most suited to you, your team and your requirements.
One point in favour of Castle Windsor is that there is already an NHibernate facility which takes care of session and transaction management for you.
Don't Use Castle IOC with Nhibernate. There are multithreading problems with Sessions of SessionFactory and IOC realization itself. We failed a large project because of this hidden architecture problem. Use Spring IOC or other IOC.
Castle is light, simple, but useless.