Object/Relational Mapping (ORMs)

Before answering what is ORM, we will try to find out why ORM was needed ??

The problem: Object Relational Impedance Mismatch

What is Object Relational Impedance Mismatch?

The object-relational impedance mismatch is a set of conceptual and technical difficulties that are often encountered when a relational database management system (RDBMS) is being used by a program written in an object-oriented programming language or style; particularly when objects or class definitions are mapped in a straightforward way to database tables or relational schema. [From Wiki]

There were many problems, few important among them are:

1. Granularity: Sometimes you will have an object model which has more classes than the number of corresponding tables in the database. For e.g.: Address
2. Subtypes (inheritance): Inheritance is a natural paradigm in object-oriented programming languages. However, RDBMSs do not define anything similar on the whole (yes, some databases do have subtype support but it is completely non-standardized)
3. Encapsulation: In an object-oriented framework, the underlying properties of a given object are expected to be unexposed to any interface outside of the one implemented alongside the object. However, object-relational mapping necessarily exposes the underlying content of an object to interaction with an interface that the object implementation cannot specify. Hence, object-relational mapping violates the encapsulation of the object.
4. Data type differences

Thus to solve these in late 80s and 90s, object databases system and persistent programming languages were introduced but they failed. Object database systems failed because they didn’t have strong support for queries, query optimization, and execution, and they didn’t have strong, well-engineered support for transactions. After this, ORMs were introduced and have made lot of progress in solving most of the Impedance mismatch issues.

What is ORM & How Is It Useful??

It is Object/Relational Mapping. While designing or creating an Enterprise application, the need to interact with the Database arises. At this point, ORM helps us, by creating a virtual map between the Database and the class objects. Thus if you have a User table in the database, and you want this to be used in your code. You would create a user entity (user object with properties similar to columns in database) and then use this entity for further purpose. Thus the entity would be an exact replica of the database table/views.

In this case, you can maintain the foreign key via a concept called as relationships. You can have 1 among:

1. One-to-One
2. One-to-Many
3. Many-to-One
4. many-to-many

This can be implemented by using List<XXClass> in the desired entity.

So for e.g.: 1 user can have 2 Addresses.

So in User class, you will have a property: List<Address> which would then map to Address table in your database.

Why Do We Need Mappers ??

From Martin Fowlers book (Patterns of Enterprise Application Architecture):

Objects and relational databases have different mechanisms for structuring data. Many parts of an object, such as collections and inheritance, aren’t present in relational databases. When you build an object model with a lot of business logic, it’s valuable to use these mechanisms to better organize the data and the behavior that goes with it. Doing so leads to variant schemas; that is, the object schema and the relational schema don’t match up.

You still need to transfer data between the two schemas, and this data transfer becomes a complexity in its own right. If the in-memory objects know about the relational database structure, changes in one tend to ripple to the other.

The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper, the in-memory objects needn’t know even that there’s a database present; they need no SQL interface code, and certainly no knowledge of the database schema. (The database schema is always ignorant of the objects that use it.) Since it’s a form of Mapper, Data Mapper itself is even unknown to the domain layer.

Advantages of ORM?

Thus the major advantage of using ORM is Persistence. Once after loading the data, you can make the data to outlive the application process.

Other being:

• Simple and less code: You don't need to keep writing the Create/update statements. You can create an entity for each table or view and then use it.
• Cost: Thus due to reduction in the repetitive work, you can reduce the total cost of the software, both monetary and time.
• Maintenance: This is the part I love the most. ORMs allows you to quite easily maintain. If you are adding a new column, you would not need to go to all the locations where you have written the insert statements and add it. Just add it in the ORM file and that should suffice.
• Caching and Concurrency: Both of these are possible and thus improve the performance.
• Lazy loading capabilities: You load the data as and when it is required. If you have 2 grids in your screen having a parent-child relationship, you can load the child details only on click on parent record, thus recovering on your initial screen opening time and getting only the details needed.
• Transactions: Transactions are maintained.

Most Used ORMs ??

1. NHibernate: This remains my best bet and I personally feel it is the best ORM. This works well with Oracle database.
2. Entity Framework: Microsoft’s answer to NHibernate. Works well with SQL, but still a step behind NHibernate.
3. LINQ to SQL: A light version of ORM. Cannot be termed as an ORM in itself, but can use its features to achieve ORM’s functionality.

Extended list can be found here.