Matthias Noback has a post to his site today covering the use of Doctrine with domain-driven design as it relates to the definition and creation of the entities in your system.

As I discovered recently, you don't need an edge case to drop Doctrine ORM altogether. But since there are lots of projects using Doctrine ORM, with developers working on them who would like to apply DDD patterns to it, I realized there is probably an audience for a few practical suggestions on storing aggregates (entities and value objects) with Doctrine ORM.

He starts the article off by making a recommendation when building out your domain and entities: don't build with the ORM in mind. Its easy to think that entities and ORM models are the same thing, but he recommends defining them first and then figuring out how to work them in to the model structure. Eventually storing them and their state will have to be considered but that shouldn't influence the design. He illustrates with simple Line and PurchaseOrder entities and how to modify the base classes so they can be managed by Doctrine. He also covers some of the other concerns of making the transition over from entities to models in Doctrine (constraints, custom DBAL types, etc). He finishes the post covering annotations, the "one transaction only" DDD idea and value objects.

In a new post to his site Matthias Noback takes a look at unit testing your code and how it can be "dangerous" if you use mocking/doubles in the wrong way (not effective testing). Instead, he makes the recommendation to mock at architectural boundaries, specifically looking at mocking persistence and time handling.

More and more I've come to realize that I've been mocking less and less. The thing is, creating test doubles is a very dangerous activity.

[...] For example, by creating a test double for the EntityManager, we're assuming that it will work well with any objects we'll pass to it. If you've ever debugged an issue with an EntityManager, you know that this is a bad assumption. Anything may go wrong: a mistake in the mapping, missing configuration for cascading persist/delete behavior, an issue with the database credentials, availability of the database server, network connectivity, a missing or invalid database schema, etc.

He then gets into the concepts behind mocking across the "architecturally significant boundaries" and what kind of functionality this involves. He then gets into the two different examples sharing some of the basic concepts and test examples for evaluating persistence and time handling. He finishes up with a look at some of the potential consequences ("outcomes" is really a better word) of refactoring your tests and code to follow these ideas.

In this post to his site Martin Hujer suggests that you don't use entities directly in your Symfony forms, opting instead for custom functionality to persist form data.

Let's start with stating that using entities for validation in Symfony Forms is widely used and widely recommend approach. Even the official documentation suggests it.

And I don't think it is a good idea! Why? [Three reasons:] an entity should be always valid, change [in the future and] layers separation.

For each of these downfalls he gets into a bit of detail about what the issue is and introduces the alternative: a custom data class. This class is then used to represent the data in the form with some simple assertions. He includes an example of this kind of class with three properties: title, content and public date. He then shows how to build a form using this class and how to handle updates, not just creates, with the same functionality.

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.

On the Paragon Initiative blog there's a post showing you how to implement secure authentication with long term persistence (a secure "remember me" essentially) in a PHP application

A common problem in web development is to implement user authentication and access controls, typically accomplished through sign-up and log-in forms. Though these systems are simple enough in theory, engineering one that lives up to application security standards is a daunting undertaking.

Without a great deal of care and sophistication, authentication systems can be as fragile as a cardboard lemonade stand in a category five hurricane. However, for everything that can go wrong, there is an effective (and often simple) way to achieve a higher level of security and resilience.

He starts with a look at passwords - how to correctly hash them, how salts play into it and some suggestions about password policies. From there he gets into the "remember me" handling, giving two common problems with most systems: insufficient randomness and timing leaks (timing attack issues). He then proposes a different kind of solution, storing some additional information in the database record, a "selector" that's not timing dependent to find the record then use a timing attack safe method to compare the hashes. He ends the post with a brief look at account recovery and some things to watch out for if you plan to implement it.

While design patterns are a wider topic than just PHP, the NetTuts.com site has posted a new tutorial looking at the Repository Pattern and uses PHP and PHPUnit to illustrate how the pattern works. They looks at the structure of the pattern at a high level and provide a more "real world" example too.

The Repository Design Pattern, defined by Eric Evens in his Domain Driven Design book, is one of the most useful and most widely applicable design patterns ever invented. Any application has to work with persistence and with some kind of list of items. These can be users, products, networks, disks, or whatever your application is about. If you have a blog for example, you have to deal with lists of blog posts and lists of comments. The problem that all of these list management logics have in common is how to connect business logic, factories and persistence.

They start with an overview of the pattern and some of the problems that it can help to solve. They also briefly mention the Gateway pattern that will be used in the examples to pull information into the Repository. After covering some of the basic concepts, they get into the code (going the TDD route) showing how to manage comments, like from a blog, inside a repository. It implements a "Comment" class, a persistence mechanism (the Gateway) and a Factory class that takes in the comment data and returns a correctly formatted object. Finally, they make the repository class and show how to add and retrieve comments from its internal data set.

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 NetTuts.com there's a new article posted that introduces you to the concept of a persistence layer in a PHP application:

One of the most confusing design pattern is persistence. The need for an application to persist its internal state and data is so tremendous that there are likely tens – if not hundreds – of different technologies to address this single problem. Unfortunately, no technology is a magic bullet. [...] In this tutorial, I will teach you some best practices to help you determine which approach to take, when working on future applications. I will briefly discuss some high level design concerns and principles, followed by a more detailed view on the Active Record design pattern, combined with a few words about the Table Data Gateway design pattern.

Included in the post is a high-level application design with the business logic is at the core and the persistence technology/layer exists outside of it. They show how to create a simple, working solution for a persistence layer to handle a blog post and its contents. It talks about characterization tests, the table gateway design pattern and the possible move to the active record pattern.

On the Zend Developer Zone there's a new post sharing the latest episode of their ZendCon 2010 sessions series - a talk from Stefan Priebsch about object persistence in PHP.

The object-relational impedance mismatch makes persisting PHP objects in a relational database a daunting task. How about these new schemaless NoSQL databases? We will have a look at the problems involved with persisting PHP objects, and introduce design patterns that help solving these problems. Putting the patterns to good use, we will build a working PHP object persistence solution for MongoDB.

You can download the episode as an mp3 and follow along with the slides for a more complete picture.

On the Zend Developer Zone today, there's a new post about a new project that's been launched - an object persistence layer for PHP, Junction.

The goal is to automate basic query construction, decouple the application from the database, and allow for faster development. With Junction you write a simple data object (the only requirement is that it have getters and setters) and a mapping file, following that you can start interacting with the database.

The project is completely open source (under the MIT license) and is operating under the "release early, release often" mentality. You can grab this most recent download directly from their site.