Where is the line between DAL and ORM?

Question

The terms are often thrown around interchangeably, and there's clearly considerable overlap, but just as often it seems implied that people see something strongly implied by saying that a system is an ORM that isn't implied by it being a DAL. What is that? What, if any, are the key points that differentiate these types of system?

For example, let's say I have some code that implements Database, Table, Column and Row classes, populating them by automatic analysis of an existing database, allowing simplified interaction and so on. It understands, enforces, and takes advantage of structural relationships between database entities, such as foreign keys. All the entity models can be subclassed to load table-specific functionality onto them.

To what extent is this a DAL? To what extent is it an ORM? Why?

Answer 1

I think an ORM is capable of mapping any set of objects to a relational database; whereas a DAL is specific to your application, and probably couldn't naturally be extended to support other objects.

Not only that, but a ORM specifically is concerned with mapping classes to/from the database entities, while a DAL may simply be a way for you to access the data in a database, without any mapping.

Answer 2

ORM = Object-Relational Mapping

In an ORM, classes/objects in the application are mapped to database tables and operations for persistence, sometimes automagically.

DAL = Data-Access Layer

In a DAL, database operations are hidden behind a code facade.

An ORM is a kind of DAL, but not all DALs are ORMs.

Answer 3

ORM didn't exist when I started programming. When the first ORMs came out, they were external tools used to create the DAL. Now days, DAL and ORM have intermingled. That's why a lot of developers use the terms interchangeably.

The most well known example of an ORM that functions as a DAL is NHibernate. Other examples are Subsonic and CSLA.NET. These are all .NET tools. IIRC, ORM tools started in the Java world. Other technologies stacks then copied what Java has done.

Answer 4

Any object orientated DAL connecting to any storage system that is not saving objects implements an ORM. ORM is generally understood to mean something like Hibernate, but the important thing is the handling of impedance mismatches.

[Expanded]

At a data level, an impedance mismatches occur when you are mapping data of one type (relational) into data of another (OO).

For instance, how many times have you seen a line like below in your DAL?

db.AddInParameter(dbCommand, "Name", DbType.String, name);

Or the other side

customerId = Convert.ToInt64(dr["CustomerID"].ToString());

Many issues come up when mapping your primitive data types.

At a object level, your DAL should be returning the structures you intend to use. Be it some sort of business object or just a bunch of raw data. Both your own DAL and the ORM need to handle this.

At a design level, the objects you construct are reflective of your stored data. So a structural difference can occur. These are also handled for you within ORM solutions, but you would be forced to do the same within a DAL. For example, within your OO code it would be nice to implement proper inheritance, but that does not covert easily into something relational.

I just wanted to point out that ORM is a term coined to push products that automate a lot of what you would already have to do within your DAL. The ORM solutions will make life easier and provide a large number of quality/performance benefits. But that doesn't change the fact that one of the major components of your DAL is creating your own ORM.