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
- 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
- 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
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