ORM & NHibernate Concepts

ORM-Object-Relational Mapping

• Object-Relational Mapping (ORM) is the concept of mapping an application's business objects to relational database tables so that data can be accessed and updated entirely through the object model of an application.

Advantages of ORM:

Many popular controls in .NET allow you simply to bind data directly from the database to your controls. This helps allow programmers to quickly set up and create simple applications with .NET. But, what happens when your application starts growing? New business logic is added over time and makes things much more complicated. The database becomes bigger and more complex with each new requirement and it soon starts to take on a life of its own. With each change you make to your application, existing functionality starts to break because the database and front-end are tightly coupled and changing one will affect the other. Soon, you find yourself in a maintenance nightmare with an application that is more band-aid than actual functionality.

Any developer or system architect who has worked with an application after the initial construction phase understands this problem well. One of the best solutions to avoiding a maintenance-nightmare application is a good multi-layered N-tier architecture and adherence to solid object-oriented design principles.

Object-Relational Mapping helps achieve this end by providing a framework for mapping data from a database into application business objects. When you want to access or save data, you simply retrieve the object or save the object representing the needed data. The basic idea is to abstract the database access from the rest of the application by encapsulating the database access within its own layer and representing the data from the database within business objects as opposed to working directly with fields from the database.

How does this help solve the aforementioned maintenance-nightmare application scenario? The biggest benefit comes from the organization of the application into discrete areas of concern, otherwise known as loose coupling. Changing the database only requires a change to the object mapping. Because the rest of the application doesn't communicate with the database and only communicates with the business objects, the rest of the application is unaffected by the change. This organization doesn't only help maintenance scenarios. It is also very useful for keeping the development of large enterprise applications manageable because project teams more easily can split up into areas of concern. One or two people can develop the database model and business object mappings while the remainder of the team concerns itself with working with the business objects and their encapsulated functionality to develop the rest of the application.

Earlier the mapping of business objects to/from (save/load) relational database is done by the devoloper. But if we use ORM tool; this mapping is done through the mapping files and devoloper now can save/load through using buisness objects without knowing the RDBMS schema :).
Example:
Suppose if a new field comes in the table then if we were not using ORM then we have to set the value for that field parameter in the Data Access Layer. So our buisness objects are tightly coupled with the database. But when we use ORM we just set the proprerty of that object & pass the object to save by calling the APIs of ORM you use. Thus no head ache "ll occur @DAL if any thing changes in the DB :)
Benefits of the Business Object
If you are still writing applications that use data-aware GUI components to interface directly with the database, you might want to reconsider. Applications built in this manner are not object oriented. Such two-layer (GUI/Database) applications violate one of the primary principles of object-oriented design: encapsulation.

Encapsulation is what allows a client to interact with an object without knowledge of its implementation details, a primary premise for loose coupling. In applications that use data-aware widgets, the opposite is the case. The client and the database are very tightly coupled. GUI code, business logic, and SQL statements are all interwoven throughout the application source code. As a result, the application can become a maintenance nightmare. Any changes in the database schema will surely cascade into unexpected failures.

What is NHibernate?

NHibernate implements the ORM concepts by providing a framework to map database tables to business objects using a standard XML format for each mapping and the database configuration. NHibernate is database independent, which means that the mappings are the same whether you are using a MS SQL, Oracle, DB2, or MySQL database. NHibernate also provides mapping solutions for a variety of object-oriented concepts such as inheritance, polymorphism, and the .NET collections framework including generic collections.