Romans Malinovskis has a post on his Medium.com site sharing what he calls a "pragmatic approach to reinventing ORM" with his thoughts about a different approach to this commonly used database interface.

It’s been over a year, since I posted my first highly debated post on Reddit: Reinventing the faulty ORM concept. Gathered information helped me design and implement an alternative pattern to ORM with many important advantages and that has reinforced my belief that ORM is faulty.

He's broken the article up into a few sections with details and thoughts for each along the way:

• Why ORM is important?
• Why ORM is broken?
• How Agile Data differ in approach?
• How Agile Data qualify production/enterprise use?
• Notes on architectural decisions in Agile Data (OOP vs Decoupling)

That final section focuses mostly on the decoupling aspect and the Agile Data library (a Data Mapper) that can be used and solves some of the common ORM problems he mentioned in the earlier sections.

Paul Jones has a new post to his site about a library he's worked up to provide "persistence-model data mapper" functionality for you to use in your PHP applications in accessing your database.

Atlas is a data mapper implementation for your persistence model (not your domain model).

As such, Atlas uses the term "record" to indicate that its objects are not domain entities. Note that an Atlas record is a passive record, not an active record; it is disconnected from the database. Use Atlas records indirectly to populate your domain entities, or directly for simple data source interactions.

The library is mostly an experiment on his part to create a tool that allows switching from the Active Record pattern to Data Mapper pattern for accessing your database without much hassle. The README on the library shows some of the basic usage of the tool, including the usual CRUD (create, read, write, execute) functionality.

Jon LeMaitre has written up a series of posts talking about effective separation of concerns using Eloquent, the database access component of the Laravel framework. His goal is to show you how makes use of the library and keep your application both maintainable and readable.

Eloquent (and by extension, Laravel) is often criticized because of its ActiveRecord ORM implementation, and that DataMapper produces a cleaner, more maintainable architecture in the long run. [...] This combination of behaviors crammed into a single object in itself is not the problem (in fact, it’s a wonderful asset), the problem is in how you make use of those behaviors throughout your application. You can be sloppy with them, or you can be tidy with them.

He starts with the "sloppy approach" where different methods of accessing the objects (and their data) are spread all across the application. He counters this with the tidy approach that makes use of "persistence-agnostic 'POPOs'" to hide the logic behind repositories. In the second part of the series he starts in and puts this idea into practice, using a simple "Member" table and model and repository classes to abstract the logic. Finally, in part three he gets into some more extended functionality for the repositories approach: handling collections, relations, eager loading and schema changes.

Russell Walker has a new post today comparing two popular methods for abstracting out database access and working with your data - the Active Record and Data Mapper patterns for data persistence.

These two design patterns are explained in Martin Fowler's book 'Patterns of Enterprise Application Architecture', and represent ways of handling data persistence in object oriented programming.

He gives simple code examples of both - one showing a basic "save" call with Active Record and the other showing the saving of a "Foo" entity using similar logic. Along with these examples, he also includes a few points about the major advantages and disadvantages related to the pattern. He also talks some about "service objects", the go-between that the data mapper pattern uses to combine business logic and the mapper object. He ends the post by making some suggestions about which to use, depending on the need of course.

On the Ibuildings techPortal today there's a new post from Robert Raszczynski about domain modeling and how a good knowledge of it can help your application's architecture.

Architectural and design patterns help software architects to break systems in to smaller, more maintainable sections organised by their functionality and usage. [...] There are three major layers in software architecture: presentation, domain and data source. [...] Now that we know what types of layers we can find in software architecture, let's have a look at how we can organize domain logic and data sources layers.

He looks at three patterns that can help organize your domain logic - a transactional script (one file that does one thing), a table module (logic lives in the tables) and his focus, the domain model. He shows (via a graph) how the domain logic approach can cut through some of the effort it could take to improve on the other two. He gives a two suggestions of how to access the data in your domain layer - a Gateway or a Data Mapper. To reinforce the ideas he's presented, he includes some code snippets of a basic domain model for a Store, Customer and Product and uses them in both Gateway and Data Mapper examples.

DevShed has posted a series of tutorials talking about different sorts of service layers in PHP applications - seven of them to be exact:

If you’re looking for an approachable guide that teaches you how to implement an easily-customizable service layer in PHP, then take a peek at this article series. In a step-by-step fashion, it walks you through the development of a sample web application, which uses a service to perform CRUD operations on a domain model composed of a few user entities.

Service layer types covered in the series are:

• Working with database entities
• Data Mappers
• Database adapters
• Handling Entity Collections
• User Services
• Dependency Injections
• Modeling Domain Objects

In his previous post Vic Cherubini introduced his namespaced DataModler ORM class and showed how to create a basic model to work with user information to the database. In this second part he looks at taking those models and saving their contents to the database.

After you have created your Models, it's time to save them to a datastore. DataModeler requires you to use PDO as the abstraction layer as it makes use of prepared statements and database specific extensions.

He bases it all on PDO object - created and pushed in via dependency injection. The model then uses that object and executes a "save()" containing the data created in the model request. He also talks about "dumb loads", a feature that lets the modeler think it was loaded without having to know anything more than just the object's ID number.

In his latest blog post Federico Cargnelutti talks about data access layers, data access objects, data mappers and how to implement them in a Zend Framework application.

In his example code he creates a few new directories in his basic application layout under the "lib" directory to contain the files for the mapper, data access layer and data objects. He uses s simple "user" table with first and last names and an ID to help identify the row.

The User model, mapper and data access object work together to make a simple "getUser" method as easy as creating a new Project_DataMapper_User object and setting up the entity before doing the fetch with a "get" call.

From Komunitasweb.com today there's new tutorial showing how to use the DataMapper library for the CodeIgniter framework to introduce object relational mapping (ORM) to your application.

If you familiar with CodeIgniter, then you have realized by now that you can’t have relationship manager. Yes, CodeIgniter doesn’t have built-in ORM. But there are several projects such as IgnitedRecord and DataMapper that will help you manage relationship between your models.

The post walks you through the installation of the tool, creating some sample data to work with and creating a full model, controller and view as an example.