Alejandro Celaya? has a post to his site sharing some of his experience and advice about how to properly pass data from the outer layers of an app to the "use case" layer. In this situation, the "use case" layer is where most of the processing is happening (versus controllers, views, etc).

Lately, I've been digging a lot in different ways of improving software architecture. Mainly subjects like Clean Architecture, Domain Driven Design, and such.

Those topics cover a lot of advanced and complex practices, but today, I want to talk about a simpler subject. What is the best approach to pass data from outer layers of the application (actions, controllers, async jobs, CLI commands...) to services that are part of the use case layer, by taking advantage of some of the practices promoted by those subjects.

That's a task which is present in any kind of application and is very important to get properly done. You usually need to get data from different origins (a HTTP request, the input of the command line...), filter and validate it, and then use it to perform some kind of task.

He starts off by talking about some of his own previous attempts, starting with a tweet asking where filtering and validation should happen in applications. He then talks about a better approach that makes use of value objects for moving data between service layers. He then walks through a more real-world example (case study) making use of these value objects to handle a user password change.

The Ibuildings blog has posted the latest part of their series looking at some general programming guidelines and principles that can help you in your own development work. In this latest article Matthias Noback talks about the "life and death of objects" in more detail including creating, updating and how they "die".

In the first part of this series we looked at ways to reduce the complexity of function bodies. The second part covered several strategies for reducing complexity even more, by getting rid of null in our code. In this article we'll zoom out a bit and look at how to properly organize the lifecycle of our objects, from creating them to changing them, letting them pass away and bringing them back from the dead.

He starts with a brief list of things that are true about objects (they live in memory, they hide implementation, etc) and some of the issues with poor object handling. He then gets into some of the basics: creating objects (meaningful & different ways), validating the input to constructors and methods and changing them to update properties and related objects. He also suggests preferring immutable objects and talks about value objects to help towards this goal. Finally he talks about the death of objects and some of the ways you can possibly "bring them back to life".

In his new post Mathias Verraes talks about the separation of concerns that, in his opinion, should exist between form, command and model and the validation of each.

Many of the frameworks I’ve worked with, promise to separate responsibilities with MVC. In practice, the end up coupling everything to everything. The forms are coupled to the models, and there’s a grand unified validation layer. This may be convenient at first, but it breaks down for larger systems, and creates headaches when having to support multiple clients. My approach is to clearly separate the validation for the form itself, from the Command validation and the model validation.

He talks about each of the different types in turn, starting with Commands. He suggests that the validation should happen in Value Objects in the Commands, validation rules in Models and some client-side validation (backed up by backend checking, of course) via Javascript or HTML5 fields.

Ross Tuck has submitted a new article he's posted about persisting value objects in the popular PHP database storage and object mapping library, Doctrine. Value objects are immutable objects that " follow value semantics rather than reference semantics".

I’ve been using more and more Value Objects in my applications over the last year, primarily with Doctrine ORM. Value Objects are an extremely powerful technique and I’ve been impressed with how much they can clean up a codebase. One of the main questions I’ve had when starting with Value Objects is how to persist them with Doctrine. This post attempts to create a reference for all the different persistence techniques I’ve seen so far.

You'll need to be familiar with Value Objects and Doctrine before starting (it's not an "intro to Doctrine" article). His example sets up an "IPRange" and an "IPAddress" that are stored in a "Server" instance. He talks about mapping the value object to the database and the getter/setter to do the work. He also touches on DBAL types, working with multiple columns in the entity and the "promised land" of embeddables. He finishes off the post looking at collections of entities and some of the other options to what he's shown (including serialization).

Following up on his previous post talking about going "beyond inheritance" in object-oriented development in PHP, Anthony Ferrara has a new post extends the subject, focusing more on types of classes and how his thoughts would apply.

In the last post Beyond Inheritance, we talked about looking past "types" and reasoning about objects differently. The conclusion was that inheritance wasn't necessary for OOP, and often results in more problems than it solves. Well, let's go beyond that and explore more of what will come from treating objects as containers of behavior. Let's look at what this means for various kinds of classes.

He looks at five different class types and gives a brief summary of the concepts they represent - Representers, Doers, Plumbers, Translators and Makers. He then shifts over to investigating how this all applies to the SOLID development principles. He follows this pattern of thought through and looks at how it breaks things down into decomposable behaviors and, ultimately, functional programming/code structures (including the suggestions that creating ValueObjects is directly related).

On DZone.com Giorgio Sironi has posted a refactoring recommendation around the handling of the data and types in your PHP code. He suggests the move from just a simple variable to a Value Object (noting that it's not really needed in PHP, but can provide a "richer interface" to work with the data).

Statically typed languages sometimes encounter the problem of downcasting: the compiler is only able to guarantee a basic type, and the object contained instead is an instance of a richer subtype. [...] You'll never need to downcast objects: variables can contain handlers to objects or even scalars without compile-time checks. Casting with (ClassName) is not even supported by the language (while casting a non-object with (object) will give you a stdClass.)

He starts by talking about scalar values in PHP and a simple form of downcasting - using the casting notation included in the language. From there he moves into the conversion into Value Objects and some of the updates (like docblocks) that would come with their use. He outlines some steps towards the conversion and provides an example set of scripts showing the conversion process.

Nicolas Bérard-Nault has put together a new post looking at the role that Value Objects play in application development and, more specifically, how they fit in with domain driven design (DDD). He looks to explain the unknown value of Value Objects to developers that might not know how helpful they really can be.

One of the main rules of DDD is that value objects are immutable. This is often not as self-evident as it seems, as many programmers are not even aware of the state they leak and create. Sadly, state is often positively correlated with entropy. Hence, taking steps to contain and to limit state is one of the keys to taming complexity in an application.

He notes that even outside of DDD Value Objects can be quite useful. He gives an example of a "RationalNumber" class with methods for basic things like addition and subtraction. He shows the more traditional mutable version that most developers would start with and uses it in several examples to show its flaws. He finishes up the post with a look at the "more correct" immutable version of the class and a sample call that would result in the correct output of a simple matematical operation.

Bradley Holt has a new post to his blog about a subject he's recently been learning about, Domain-Driven Design, and how immutable value objects could be useful in PHP.

Yesterday I tweeted: Modern object-oriented programming languages need support for immutable Value Objects. #DDD The "DDD" in that tweet stands for Domain-Driven Design. There were several interesting responses to this tweet.

Responses to his tweet included comments from Matthew Weier O'Phinney, Ralph Schindler, Nicolas Berard-Nault and Giorgio Sironi. He notes that, while all of the suggestions are good, they're only half of the issue. They make it immutable when defined but not during execution. Currently PHP lacks this functionality, but something like this could be worked in with the concept of a "final" class.

Following up on their introduction to design patterns, the PHP Freaks have posted tutorials covering three of the more popular patterns - strategy/bridge, value object and singleton.

• Strategy and Bridge - The Strategy and Bridge patterns provide solutions to apply polymorphism in more flexible way than you can accomplish with only inheritance.
• Value Object - The Value Object pattern has, just like the Singleton, to do with referencing and instances. In a way, the Value Object is the opposite of the Singleton: it's goal is to ensure NOT to use the same instance, under certain conditions.
• Singleton and Singleton Registry - The Singleton pattern ensures that you are always dealing with the same, single instance, wherever in your application. The Registry pattern usually utilizes the Singleton pattern (hence "Singleton Registry") to make the same 'globalness' apply to objects who's classes weren’t necessarily designed to

Keep checking back to their tutorials section for more design pattern tutorials.

Knut Urdalen, on seeing some of the recent discussion on why the ActiveRecord pattern sucks and talks about why, when presented with a the need for a database layer, he usually goes back to his own familiar Singleton-based style.

I normally use a simple solution using the Singleton pattern for managing the database connection, the Value Object pattern for all business objects and the Data Mapper pattern to manage the mapping between business objects and the database schema. It's as simple as that – handcrafted and no magic going on.

The post also includes his code for an example of a database connection - the creation of the Singleton interface class, making the Value Objects and customizing one for the type of "Product".