DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • A Data-Driven Approach to Application Modernization
  • How Web3 Is Driving Social and Financial Empowerment
  • Microservices With Apache Camel and Quarkus (Part 2)
  • Application Architecture Design Principles

Trending

  • A Data-Driven Approach to Application Modernization
  • How Web3 Is Driving Social and Financial Empowerment
  • Microservices With Apache Camel and Quarkus (Part 2)
  • Application Architecture Design Principles
  1. DZone
  2. Data Engineering
  3. Databases
  4. The era of Object-Document Mapping

The era of Object-Document Mapping

Giorgio Sironi user avatar by
Giorgio Sironi
·
Jul. 07, 11 · Interview
Like (0)
Save
Tweet
Share
19.63K Views

Join the DZone community and get the full member experience.

Join For Free

The Data Mapper pattern is a mechanism for persistence where the application model and the data source have no dependencies between each other. For example, a group of PHP classes and a relational database may be used together without having the PHP classes extends a base Active Record class, thanks to a Data Mapper like Doctrine 2.

But everytime we talk about the Data Mapper pattern, we assume there is a relational database on the other side of the persistence boundary. We always save objects; we always map them to MySQL or Postgres tables; but it's not mandatory.

In fact, you can store objects also in NoSQL stores, with no more impedance mismatch that the one already existing with relational databases. Doctrine is expanding with two projects which have the goal of replicating the easy object-relational mapping of Doctrine 2 to other stores.

These two projects are the MongoDB and CouchDB Object-Document mappers. Since the basic unit of persistence is the document in both cases, objects (or group of them) are stored as documents. The retrieval process depends on the features of the underlying database: it may consists of simple queries (MongoDB) or just of a unique identifier (CouchDB).

How do an ODM work?

If you use Doctrine 2, you'll find out that many of its concepts translates well to the other mappers. Instead of Entities, we have Documents in our model:

<?php

namespace Documents;

use Doctrine\Common\Collections\ArrayCollection;

/**
 * @Document(indexed=true)
 */
class Article
{

Instead of columns, we have fields:

    /** @Id(type="string") */
    protected $id;
    /** @Field(type="string") */
    protected $title;
    /** @Field(type="string", indexed=true) */
    protected $slug;

And instead of an EntityManager, we have a DocumentManager as the Facade of the Data Mapper (despite the name change, its methods are almost the same):

$user = new User();
$user->id = "myuser-1234";
$user->username = "test";

$this->dm->persist($user);
$this->dm->flush();
$this->dm->clear();

$userNew = $this->dm->find($this->type, $user->id);

There is a lot of reuse between the various projects: Doctrine\Common is a dependency for them all, and you will be able to use the same ArrayCollection with any of the mappers.

Features

There's really all I would need to get started:

  • storage of new documents, update, removal; pretty much what you expect;
  • Unit Of Work pattern for tracking what has been modified and execute a single flush() to save changes;
  • support for collections and both one-to-many or many-to-one associations;
  • support for embedded documents (read Value Objects); both embedding of one or many objects as document fields is possible. This is a striking difference with respect to ORMs: Doctrine 2 does not support Value Objects mapping.
  • cascade of persistence and removal of objects;
  • specification of the mapping metadata via annotations, XML, YAML or PHP (like for Doctrine 2).

Projects status

The concept of Object-Document Mapper, at least in this name, is pretty unique to PHP and Ruby. Mandango is a PHP alternative and Mongoid a Ruby one, for the MongoDB case.

Both projects are in the midst of releasing their first stable version: we are talking about bleeding edge technology here.

The MongoDB mapper has been around for more than an year and is now in beta3. The CouchDB has an alpha release, but I found out that the current version shipped via PEAR is broken: if you want to play with it, checkout it from github and initialize its submodules (the standalone Symfony components and Doctrine\Common):

git clone https://github.com/doctrine/couchdb-odm.git couchdb_odm
cd couchdb_odm
git submodule init
git submodule update

For the MongoDB mapper, the PEAR installation should suffice:

pear install pear.doctrine-project.org/DoctrineMongoDBODM-1.0.0BETA3

Conclusions

I think I'm going to explore more the CouchDB ODM, since it is a departure from the relational model. MongoDB is still similar to traditional databases in the way queries are satisfied: specifying a set of constraints like in SQL WHERE clauses. I'm more interested instead in approached that skip the Mapper for reporting (like Command-Query Responsibility Separation), and maybe CouchDB could be a good fit.

By the way, object-document mapping is an alternative to explore: Data Mappers are all the rage today in PHP (they already were yesterday in other languages.) If we already accept that relational databases aren't always the solution, extending NoSQL with Data Mappers is a natural choice.

Database Relational database

Opinions expressed by DZone contributors are their own.

Trending

  • A Data-Driven Approach to Application Modernization
  • How Web3 Is Driving Social and Financial Empowerment
  • Microservices With Apache Camel and Quarkus (Part 2)
  • Application Architecture Design Principles

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: