Geoff Wozniak has written up a post on the "Curried lambda" site sharing his opinion on ORMs (object relational mappers) for working with databases and how, after using them in his own development work, that they're a good side benefit but shouldn't replace knowing SQL.

I've come to the conclusion that, for me, ORMs are more detriment than benefit. In short, they can be used to nicely augment working with SQL in a program, but they should not replace it.

[...] Neward, in his well known essay, lays out many cogent reasons why ORMs turn into quagmires. In my experience, I've had to deal directly with a fair number of them: entity identity issues, dual-schema problem, data retrieval mechanism concern, and the partial-object problem. I want to talk briefly about my experiences with these issues and add one of my own.

He breaks the rest of the article up into several sections, for each sharing some of his own experiences with the feature and how it could be resolved using other query methods:

• Partial objects, attribute creep, and foreign keys
• Data retrieval
• Dual schema dangers
• Identities
• Transactions

He ends the post with a look forward, thinking about where he'll end up, mentioning stored procedures, queries as APIs and how "easy" isn't always best when it comes to ORMs.

Bernhard Schussek has posted a tutorial on his Webmozart.io site talking about the use of value objects in Symfony forms. By nature value objects don't allow the use of "setters" to assign/change values but he shows how to use a custom data mapper to work around the problem.

Many times, Symfony developers wonder how to make a form work with value objects. For example, think of a Money object with two fields $amount and $currency. [...] Can you write a form type for this class without adding the methods setAmount() and setCurrency()? In this post, I will show you how.

He starts with a bit of an overview on what value objects are and how the concept of immutability comes into play. He shows examples of potential issues if setters are allowed to change data and what should be done when a value change is actually needed. He then gets into the heart of the matter, integrating the forms handling with simple value objects. He goes through building a simple form and the use of the empty_data option to create a new value object with the form values. This works fine but breaks down if you need to update an object. Instead he creates a custom data mapper that sets up two methods, mapDataToForms and mapFormsToData, that allow for both interactions to work correctly.

David Adams has published a recent post that wonders if ORM abstraction is a "pipe dream" when it comes to abstraction. ORM stands for "object relational mapper" and is commonly used as a layer between the application and a dta source to work with the data as objects, not directly with it. He instead investigates replacing the ORM layer with multiple instances of repository pattern-structured code to abstract thing even more.

I was recently introduced to the repository pattern, a type of abstraction and organizational technique. The idea being, create a repository for each of your models to retrieve and persist to and from. A supposed benefit of the repository pattern is the ability to abstract your ORM and create different implementations for Eloquent, Doctrine, Propel, etc. This abstraction intrigued me. I set off to put this idea into practice and see what it took. Here are my findings.

He looks into how Doctrine handles its entities and tries to mimic some of the logic, including the calls to "save" and "flush". He also looks at how to handle a few other common ORM-ish topics like relationships, validation and observers. Unfortunately, he hit a wall with his solution and wasn't able to figure out a good Repository-based solution.

Rob Allen previously posted about some of his practices around the different types of objects in the model layer of his Zend Framework 2 applications. In this latest post he follows up and shares some example code for the different types.

I previously talked about the terms I use for objects in the model layer and now it's time to put some code on those bones. Note that,as always, all code here is example code and not production-ready.

He includes sample classes related to his "books" examples - a "book" entity (with title, author, id and ISBN), a mapper object to load/save/delete the entity and a service object that provides an interface for the entity to the rest of the application.

In this latest post to his site Rob Allen talks some about application structure and the different kinds of objects he uses in his applications.

I currently use a very simple set of core objects within my model layer: entities, mappers and service objects. [...] I dislike the phrase "service object" as the word "service" means so many things to so many people. I haven't heard a better phrase yet that everyone understands though.

He defines each of the types of objects to help make the separation clearer. Here they are in brief:

• Entities are objects that represent something in my business logic.
• Mappers know how to save and load an entity from the data store.
• Service objects provide the API that the rest of the application uses.

Some of the comments on the post relate his choices to use in Zend Framework v2-based applications, noting that there are some base components you can extend to create these kinds of objects.

On PHPMaster.com today they have a new tutorial focusing on using the Repository (a part of the domain driven design architecture) to enhance your model's current functionality.

Unlike mappers, though, which are part of the infrastructure, a repository characterizes itself as speaking the model’s language, as it’s intimately bound to it. And because of its implicit dependency on the mappers, it preserves the persistence ignorance as well, therefore providing a higher level of data abstraction, much closer to the domain objects.

Included in the tutorial is the full code you'll need to create a simple UserInterface class and a User model that extends it. He also makes a UserCollection class to handle working with multiple User objects and a UserMapper to handle the actual data source fetching. Finally, he implements the Repository on top of this base structure showing how it lays on top of everything via the UserMapperInterface instance. At the end some example code showing it in use is also included - making the PDO connection, creating the UserRepository and fetching by a few different data types (email, name and role).

In this previous post PHPMaster.com introduced you to the concept of "domain models", structures defining how data should be formatted for consistency. In this second part of the series, Alejandro show show to integrate them with a data access layer (DAL) to make them easier to work with.

The phrase may sound like an cheap cliché, I know, but I'm not particularly interested in reinventing the wheel each time I tackle a software problem (unless I need a nicer and faster wheel, of course). In this case, the situation does warrant some additional effort considering we'll be trying to connect a batch of mapping classes to a blog's domain model. Given the magnitude of the endeavor, the idea is to set up from scratch a basic Data Access Layer (DAL) so that domain objects can easily be persisted in a MySQL database, and in turn, retrieved on request through some generic finders.

He includes all the code you'll need to create a (namespaced) database adapter (PDO), the mapping layer to tie the domain models together and using it all in a practical "blog" example with posts, comments and users.

On DevShed today there's a new tutorial showing you how to build a basic ORM layer on top of a MySQL database. It includes all the code you'll need (cut&paste-able, not as a download).

Obviously, with so many ORMs at one's disposal for free, it seems pretty pointless to develop a custom one; are we trying to reinvent the wheel? No, of course not. But if you need to create a simple application that performs a few CRUD operations on some related domain objects and don’t want to climb the learning curve of a third-party library, then implementing a custom ORM might make sense. There's alos the educational aspect of the process (yes, learning one or two things never hurts).

They start you off with the creation of the "data persistence layer" (an interface first) to connect to the database, building a MySQL-specific one on top of it. Next up is the data mapper layer making things like "fetch by ID" and the insert/update/delete possible. Their simple example doesn't include anything about ORM relationships, though - just fetching simple rows.

In a recent post to the ServerGrove.com blog today there's a look at using the MongoDB with symfony to create a simple application with a NoSQL-based backend.

Part of our business is to develop internal applications and support customers, so we dedicate a good amount of time to research, test and learn new technologies. We have been following this whole movement and decided to give MongoDB a try. What has really taken our attention regarding MongoDB is its simplicity, yet how powerful it is. It lowers the barrier to develop DB-driven applications even more.

They start by explaining how to use MongoDB together with PHP and get both the server and client sides up and running. From there they introduce ODM, a object document mapper from Jon Wage (of the Doctrine project) that lets you easily interact with MongoDB instances. A code sample it provided to show how simple the tool is to use and how it can integrate with symfony as an entity.

Michelangelo van Dam has a recent post to his blog about a difficulty he was having with his Zend Framework application and setting up some data models.

I was struggling getting my data models (as described in the Zend Framework Quickstart) to work with relations. My first solution was to create a database view that merged that data using joins to collect this data in a format that I could use in my data models. This was going great until I looked at my database where it contained over 20 views (along with 20 data models, mappers and db table gateways) ! So I said to myself there had to be another way.

His other way came in the form of the Zend_Db_Table_Relationships component and, after a bit of work, it did just what he needed. He shares how you can set them up similarly by walking you through the creation of a sample application ("datamodels") and linking together a series of sample tables with a Db_Table class using relationships, a simple model to abstract data access and a model mapper class to redefine some of the based functions (like "findAll") to pull in data from other tables.