NYCPHP Meetup

[Anthony Ferrara]

Hey Justin,

Replies inline;

On Mon, May 7, 2012 at 8:16 AM, Justin Demaris <justin.demaris at gmail.com> wrote:
> Hello PHP Talkers,
>
> How do you guys feel about ORM systems and other database abstraction
> layers?

Personally, I do not like them.  I find that the ORM layers
specifically violate SRP (Single Responsibility Principle) and are
usually not worth while.  Instead, I prefer a light weight Data Mapper
layer ( http://martinfowler.com/eaaCatalog/dataMapper.html ).  I
usually hard-code SQL in the mapper, but you *could* use an ORM there.
 But the key is to keep it completely separated from the business
objects.  That way your data model is free to evolve independently
from your business objects...

> Is there any ORM system out there
> that just does it right? Namely, I'd be looking for things like:
>
> 1) When I instantiate an object by it's ID multiple times, it doesn't bother
> to hit up the database after the first time, but just keeps giving me copies
> of the same object

Well, do you really want this all of the time?  I can see cases where
you do want to re-query the database (especially in sensitive
areas)...

> 2) Lazy load the object values. There are a number of patterns where I've
> seen people instantiate a bunch of objects and then only use a small subset
> of them. It would be nice if the object only loaded the data when we try to
> reference one of its non-ID properties.

Why?  Your business objects should have all the data they need at
creation time.  Otherwise you can wind up in the situation where
objects representing the same state have different states.  Which is
not a good thing...

> 3) Ability to tweak the back end to work with other database systems
> (especially Riak, Mongo and Cassandra)

Unless you're building a project that you want to distribute to
others, I find this a bad feature.  Sure, it's nice to know you can
switch to another storage with a config change.  But practically, how
often do you do that?  And if you do that, you're going to want to
tune your data model specifically towards the strengths of the target
backend.  Otherwise you're constantly stuck with a sub-optimal
solution, and little way out when you need to scale...

> I have had really good luck in the past working with Yii and integrating
> with Redis to use their Active Record structure, but I'm not sure of the
> performance there. Also, I've been hearing a lot about Doctrine 2 lately and
> the necessity of having an extra Data Mapper layer in the middle that
> separates the classes and properties from the fields and tables that store
> the data.

That mapper layer is a good thing...  It allows both to vary
independently of each other.  Which avoids un-needed coupling between
the layers.

As far as Doctrine 2 goes, IMHO it's the best layer out there.  I use
it when I have projects that dictate requirements that it helps fill.
But usually, I just use the database specific layer (MySQLi or
MongoDB).

I hope that helps,

Anthony