The PHP podcast where everyone chimes in.

Originally aired on

February 3rd, 2016

037: An ORM Discussion

Object-relational mapping (ORM) tools are a great way to model relational databases in your codebase. We discuss the benefits that ORM tools can add to our apps, some problems with the ORM model and where the PHP community seems to be heading when it comes to persisting data. We'll also discuss the opposing active record & data mapper paradigms.

with


ORM's and the active record & data mapper paradigms Show Summary


Discussion - The panel talks about...

A variety of stand-alone ORMs are available e.g:

Also a lot of frameworks ship with their own bespoke ORM.

Why should someone who has never used an ORM use one? What's the 'elevator pitch'?

  • An ORM is a way to deal with relational databases in your O-O code
  • You can apply O-O principles to your data model and encapsulate your data logic
  • It represents a step up in complexity, but complexity is relative - a good abstraction removes underlying complexity and provides a simpler interface
  • Leave the "boring" parts to someone else
  • Cleaner code - codebases with a lot of raw SQL are "noisy"
  • ORMs separate our objects and the relationships between them from the details of persistence/how we store them. You can focus on the interface, not the data structure
  • An ORM lets you forget things: The design of your objects is your job and the process of saving/loading them to/from storage is the ORM's job
  • For some type of application, a DBAL like PDO is sufficient or even more appropriate

What do the panel think of the Repository Pattern with ORMs?

  • Shawn's article on the Repository Pattern
  • Sometimes they are the right way to go and sometimes they aren't
  • Using the pattern is helpful when you want to construct objects and think about the persistence separately - it is useful to be able to 'hide' the ORM
  • Sometimes it is more useful not to abstract so much - it depends on the tradeoffs
  • Marco is currently working on an application which doesn't use an ORM at all
  • In small projects, the additional abstraction is often not worth it
  • It is also about personal preference/barriers to entry

How do the panel approach mutability vs immutability with reference to ORMs

  • If mutable objects make things easier, they are fine
  • Immutability may be 'technically' superior, but it is often not 'practically' superior
  • O-O code generally uses mutable objects. An ORM should fit into its environment
  • Using CQRS allows the use of different models/data structures for reading and writing (and hence immutable objects can be used for reading and mutable objects can be used for writing).

The panel discuss their experiences with Event Sourcing

A comparison of how database access patterns scale

  • Direct Database Access: Simplest possible technology - basically zero barrier to entry, but complexity quickly rises with application scale
  • ActiveRecord: Slightly higher introduction cost, complexity still rises with scale, but at a lower rate
  • DataMapper: Setup complexity high, complexity scales just under linearly as application grows
  • Event Sourcing: Starting complexity is really high (but decreasing), but complexity is nearly constant

However, this changes over time.

ORMs and Graph DBs

  • Marco talks about Orient DB ODM - an ORM/(OGM?) for OrientDB
  • In some ways object-oriented code is closer to a graph DB model than a relational DB model:
    • Objects reference other objects with pointers, and this is also what is happening in a graph DB
    • In an SQL database, association between entities is defined by indexes, foreign keys, joins, pivot tables, etc not pointers
  • There is an entire episode on Graph Databases

What performance benefits do ORMs offer?

  • ORMs can provide caching in the case of repeated queries, but this is effectively by coincidence rather than design
  • An ORM is about abstraction not performance
  • Adding a layer of abstraction will usually decrease performance

ActiveRecord vs DataMapper

ActiveRecord:

  • A record class or object represents a row of data
  • It has user-defined methods based on what the object models
  • It also has methods implementing DB functionality (for example, it knows how to save itself)
  • ActiveRecord defines its own conventions and idioms
  • Models and database are tightly coupled

DataMapper:

  • A record class or object only models what it represents in your application
  • It must be passed to a separate service object (repository) which deals with operations like saving
  • This provides separation of concerns
  • DataMapper allows more idiomatic use of the underlying language
  • Often sacrifices developer experience to gain architectural purity

Comparison

  • ActiveRecord is quick with low barriers to implementation, but suffers from some ambiguity between record logic and object logic
  • DataMapper has a much higher barrier to entry, but provides a more robust abstraction
  • In the PHP community, ActiveRecord vs DataMapper often manifests itself as Eloquent vs Doctrine
  • It isn't as big an issue as some people turn it into
  • A lot of it is about personal preference or the right tool for the job

Further Links

Ross Tuck


Shawn McCool


Marco Pivetta


Developer Shout-Out

The Developer Shout-Out recognizes developers in the community for their contributions.

For this episode the panel guests, Ross, Shawn, and Marco nominated Elliot Levin for the Developer Shout-Out segment.

Thank you, Elliot Levin for your work on the Pinq project. A $50 Amazon gift card is on its way to you.

$50 Amazon gift card sponsored by Laracasts

Laracasts

It's like Netflix for developers.

Show Notes Credit

Chris Shaw

Thank you Chris Shaw for authoring the show notes for this episode!

If you'd like to contribute show notes and totally get credit for it, check out the show-notes repo!