Thoughts on ORM and Data Abstraction

[Jesse Burns]

I've mentioned that I'd like to separate how we access data from how data is stored in this topic: https://groups.google.com/forum/?hl=en#!topic/alliancecms/IY7bbRaE01M

Here are some of my thoughts on the matter.

To make this post a little shorter I've provided the following references. If you're not familiar with the topic it's recommended that you take a minute to get up to speed.

References:

The Clean Architecture: http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
ORM (Object-relational Mapping): http://en.wikipedia.org/wiki/Object-relational_mapping
DAO (Data access object): http://en.wikipedia.org/wiki/Data_access_object

The Goal:

I'd like to be able to offer an interface that will allow us to describe our data in some kind of config file. Then we can use an object to manipulate data in a fashion similar to this:

$data->set(['name', 'John'); // This will store the data in which ever engine we use in the back end (sql, xml, csv, flat file, etc...)

$data->get('name'); // This will retrieve the data

$data->getRelated('John', 'address'); // This will get the address related to 'John'

This is a very generic example, and the final product will probably not be anything close this. But the main point is that we're trying to be careful about keeping the public interface completely independent of storage method used. The above examples should work for RDBM's and csv files. This way we can add and switch storage engines as we go.

There might be need for lower level control of how we pull and relate data, so there will have to be some low level way to describe data relationships.

The Clean Architecture article talks about the inner rings being unaware of the outer rings. The inner ring here is the interface for manipulating data, the outer ring is the storage engine.

I would like to be able to create some type of abstract dataAdapter class or interface that is used to create adapters for individual storage engine. The 'brains' of this tool will reference the adapter, do all of the processing, and then return the proper data to the public interface.

This is not a simple thing to do, but just think of the benefits once this is in place.

Right now the most important thing to do is discuss how this could work. I think we should first figure out what the public interface is going to look like, then work our way down to the internals.

As to implementing this, once we have a public interface, we can just wrap that around the existing database layer. If we do a proper job of designing the public interface then we can work on switching out the back end one piece at a time until the system is complete.

We do have the option of adopting Doctrine or Propel, but even if we do that the best thing would be to create the public interface that I've been talking about and using Doctrine or Propel as the back end. This will allow us to move away from an existing tool if needed in the future. Remember, AllianceCMS is going to be around for a long time, and there will be many changes to the PHP dev landscape and every 3rd party tool around today, and those that will be created tomorrow.

Just think, in 10 years from now there might be a technology that is so superior to RDBM's that continuing to support MySQL wouldn't even be a consideration. Do we want to have to completely redesign the coupled data interaction layer we have in place at the time, or do we just want create an adapter for our data abstraction tool?

To make development and maintenance for AllianceCMS more pleasant in AllianceCMS v5.0, we need to make forward looking decisions now.

[Jesse Burns]

It seems that the proper term for this tool/method would be 'Persistence Layer'.

Here's an interesting article that contains code examples. We might be able to learn something from this:

http://net.tutsplus.com/tutorials/php/evolving-toward-a-persistence-layer/

Here are some articles that will help us get up to speed and make informed decisions:

http://en.wikipedia.org/wiki/Data_access_layer
http://www.sitepoint.com/building-a-domain-model/
http://martinfowler.com/eaaCatalog/domainModel.html

[Jesse Burns]

Here's another good resource:

http://codeutopia.net/blog/2009/01/05/decoupling-models-from-the-database-data-access-object-pattern-in-php/

[Jesse Burns]

And another one:

http://www.oracle.com/technetwork/java/dataaccessobject-138824.html

[Jesse Burns]

And they just keep coming :-)

http://russellscottwalker.blogspot.co.uk/2013/10/active-record-vs-data-mapper.html