I thought I'd force myself to word a few on NHibernate this evening. NHibernate is a set of tools for mapping objects to persistent storage. It is implementation of an Object Relational Mapper (ORM) and a .NET port of the popular Hibernate ORM for Java platform (Java, ColdFusion, ....).

It is a data mapper styled ORM as opposed to it's other competing and actively used mapping pattern called Active Record. Martin Folwer describes the Data Mapper pattern as "A layer of Mappers (473) that moves data between objects and a database while keeping them independent of each other and the mapper itself." Like arguments exist for use one design pattern over another, a few sides exist each pitching arguments on the best way to map an object (OOP paradigm is mainly where ORMs apply) to a persistent re-readable storage. I am writing about NHibernate, so that tells what side I am on.

I am careful not to use the phrase ORMs map objects to databases only, hence the use of storage. Others might add ORMs can map from objects of 1 structure in memory to another structure in memory for examle DataMapper for .NET, but I still refer to that as storage.

Read more on ORMs for more theory. NHibernate is a port on Hibernate that brings the advanced mapping and powerful capabilities to .NET. I am going to outline some of the features it has brought with it to the advantage me and my team's advantage. Some of these features I briefly describe are what we use in our day-to-day development.

HQL (Hibernate Query Language), is an object query language similar to SQL but exposes (not the best word) the store as a virtual object database and provides query constructs to help developers maintain that thought. HQL is translated to SQL using a parser, lexer and compiler in the case that a database is being queried (which today is the most used back end case). Because HQL is a well defined language, its commands can be traslated to query other backends like MongoDB, CouchDB as done in Doctrine a php port of Hibernate. HQL understands complex data types in queries and can also
return complex datatypes from query results while keeping the object orientedy relational constructs bolted on top. From an application design point of view, it stops the abstraction from seeping through I am talking about the flatness of relational structures.

HQL allow queries to return complex types (lists, maps, ) as results or nested properties of result "objects".

Complex projections are also another powerful concept HQL allow for developers. Instead of querying for a set of records and return flat schemaless results or try to parse the result into object domain, projections allow query results to be mapped into a complicated objects that closely
represent the domain model you are querying and persisting.

An example:

To return the list of orders for all customers in 1 "query" is impossible. Options include get all customers and loop through the result getting each order, or perform some sql jutsus like concat the orders in the query and de-concat into an array.

In for ex. python:

	select c.id, c.name, cast(group_concat(o.quantity) as char)
	from customer c
	join `order` o ON c.Id = o.customerID
	group by c.id
	;

	list=[]
	for customer_orders in result:
		customer_order = collections.namedtuple("CustomerOrders", ["customer", "orders"])
		customer_order._make(result[0], result[1].split(','))
		list.append(customer_order)
	

the equivalent in HQL =

	from Customer as customer	

(.)_(.) Yeah.

Polymorphic queries
This may be a silly schema, but variations of this type of schema exist in real world apps. My team use such variations.

	User             Manager         Teller             Auditor
	------           ---------       ----------         -----------  
	firstname        branch_id       station_id         zone_id
	lastname

HQL query: "From User u" returns all users of type Manager, Teller and Auditor
HQL query: "From Manager m" returns users only of type Manager

(This sort of functionality requires a prior mapping where inheritance is setup)

Queries allowing versatile where clauses to reference any nested property within the queried object

	from Customer c where c.orders[0].itemNumber == 3

This post does not completely mention many of the other really cool, useful and time
saving features of NHibernate we use like:

- Object proxying (quasi AOP)
- Lazy loading
- Criteria queries
- LINQ integration
- Schema Generation
- ....

Tacked upon
- Loquacious
- FluentNHibernate

Thanks.

Seun your humility kills me .I just want to be like you but something tells me it may take me 60 years to achieve it.

if you believe then you can.

pc guru: if you believe then you can.

Pc guru yep. I believe but his behaviour is something to learn from which may take additional three years to learn to perfection. Despite having one of the the greatest websites in the world, he his still calm headed, has respect for his members, always learning, never acting as if he has knew it all. Nairaland facing critcism and condemnation every second and all the criticism does, is even take nairaland higher. Only God knows how he's doing the whole stuff without getting distracted from mass public opinion. He his among on the list of people i would like to see face to face before i leave this earth

@Peterson1993: Aww, thanks. You're too kind. Let's try to stay on topic, though.

Ksssss. I hear you. I wanted to contribute but i got distracted by that your "thanks". I know nothing about nhibernate. All I have to say is "thanks" as well to kerdaaner.....