News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Paul Jones:
Action-Domain-Responder and the "Domain Payload" Pattern
October 01, 2014 @ 10:16:11

Paul Jones has a new post with more information about his proposed "Action-Domain-Responder" design pattern (a replacement for the typical MVC) and suggests a new piece, the Domain Payload pattern. This pattern would use a domain payload object to wrap the data and provide the responder with additional handling and context.

In Action-Domain-Responder the Action passes input to the Domain layer, which then returns some data for the Action to pass to the Responder. In simple scenarios, it might be enough for the Responder to inspect the data to determine how it should present that data. In more complex scenarios, though, it would make more sense for the Domain to pass back the data in a way that indicates the status of the data. Instead of the Responder inspecting the Domain results, the Domain should tell us what kind of results they are.

He shows a code example of this Domain Payload object in action, starting with some typical MVC code and refactoring it along the way into an ADR structure. He shifts from a typical model into a more domain-driven approach and describes the wrapping of the data in the payload, context for the contents (even just a class name helps) and how those relate to the actual output. You can find the resulting code in this example over on Paul's GitHub account.

0 comments voice your opinion now!
action domain responder mvc adr payload wrapper context data

Link: http://paul-m-jones.com/archives/6043

Matthias Noback:
Symfony2 Event subsystems
August 25, 2014 @ 10:07:09

In his latest post Mathias Noback takes a look at the Symfony2 event subsystems and the answer to a common problem he's had with it in the past: circular references.

Recently I realized that some of the problems I encountered in the past could have been easily solved by what I'm about to explain in this post. [...] The problem is: having a complicated graph of service definitions and their dependencies, which causes a ServiceCircularReferenceException, saying 'Circular reference detected for service "...", path: "... -> ... -> ...".' Somewhere in the path of services that form the circle you then find the event_dispatcher service.

He shows the wrong way to solve the problem first by injecting a service container into the listener and using services directly from there. In his "entirely different and much better way" he shows a solution that removes dependencies on the main event dispatcher. He shows how to use the event subsystems to avoid this link and gives a more concrete example for domain-related events (with both code and config).

0 comments voice your opinion now!
symfony2 event subsystem listener dispatcher domain

Link: http://php-and-symfony.matthiasnoback.nl/2014/08/symfony2-event-subsystems/

Paul Jones:
Action-Domain-Responder, Content Negotiation, and Routers
July 18, 2014 @ 10:17:57

In his latest post Paul Jones comes back to his proposed application structure, the idea of Action-Domain-Responder, and answers some questions about where content negotiation happens and routing.

While talking about Action-Domain-Responder on the Crafting Code Tour, one of the common questions I got was: "Where does content negotiation happen?" My response was always: "Where does it happen in Model-View-Controller?" That opened up a discussion on how content negotiation is a tricky bit that can go in different places, depending on how you want the concerns separated, and is not a problem specific to ADR.

He goes on and tries to answer the question a bit better, pointing out that "it's a problem for everyone" isn't really good enough to take action on. He works through the different pieces of the ADR pattern, trying to reason out where the right fit is. He suggests a "first filter" on the Controller level, more specifically at the Router level. That's not to say that the Router needs to know about content handling, but it does need to know how to pass that information on.

0 comments voice your opinion now!
action domain responder content negotiation routing

Link: http://paul-m-jones.com/archives/6020

Matthew Weier O'Phinney:
Better Understanding Controllers Through Basic Patterns
June 10, 2014 @ 09:53:21

In his most recent post Matthew Weier O'Phinney shares his own spin on the Action-Domain-Responder pattern (from Paul Jones): how the controllers in the ARD setup could be explained as facades.

Paul M. Jones has started an interesting discussion rethinking the MVC pattern as applied to the web, which he has dubbed Action-Domain-Responder (ADR). If you haven't given it a read yet, click the link and do that; this page will still be sitting here waiting when you return. I agree with a ton of it - heck, I've contributed to it a fair bit via conversations with Paul. But there's been one thing nagging at me for a bit now, and I was finally able to put it into words recently. Controllers - Actions in ADR - can be explained as facades.

Matthew starts off by defining the Facade design pattern with a quote from the infamous "Gang of Four" book: simply put, a simplified interface to a complex system. He provides a basic example of a facade that wraps some common steps for inserting and logging data with this kind of simplified interface. He applies this to the ADR pattern's controllers, pointing out that it handles a few complex steps "behind the scenes" common to marshaling and managing the request.

For me, thinking of Controllers and Actions as Facades has an additional benefit: it describes rather complex architectural patterns in terms of basic design patterns. I find the more I can reduce the complexity of a definition, the more likely I will understand and use it correctly.
0 comments voice your opinion now!
controller designpattern adr action domain responder facade

Link: http://mwop.net/blog/2014-06-09-controllers-as-facades.html

Paul Jones:
Refactoring To Action-Domain-Responder
June 06, 2014 @ 10:06:15

Paul Jones has a new post to his site today with a more in-depth look at his proposed "Action-Domain-Responder" design pattern and how to refactor an application, based on some with with the Aura framework, to use it.

The v1 version of the Aura framework includes a controller to handle web assets. The idea for this controller was that an Aura package might have images, scripts, and stylesheets that need to be publicly available, but in development you don't necessarily want to copy them to a public document root every time you change them. [...] That v1 version is a mess. The Controller handles the response-building entirely, and there is no Model separation at all. Let's try refactoring it to an Action-Domain-Responder architecture and clean it up some for a v2 version.

Associated code it just linked to, but he does summarize the steps needed to make the transition: extract the domain logic, move responses to a separate class and rename the controller to an action. He also shows how making this separation makes testing easier and links to examples of tests for each. He finishes the post with two final notes about the refactor. One points out that this method isn't the only way to handle this architecture shift and that the action returns a responder, not a response object.

0 comments voice your opinion now!
action domain responder designpattern architecture refactor

Link: http://paul-m-jones.com/archives/6006

The PHP.cc:
Urban Legends and Error Handling
June 27, 2013 @ 09:23:16

In this new post to the PHP.cc blog, Stefan Priebsch looks at the relationship between urban legends and error handing in PHP.

Ending up in such a situation [as the tourists in the urban legend] is not the fault of the underpass: the error, made somewhere upstream, merely shows up right when approaching the underpass, and is usually difficult (or at least tedious) to handle. PHP as a programming language, just like any dynamic language, may at first appear to not need overly strict validations of data. Validation of data, however, is directly related to error handling: If data is invalid, this should be an error or an exception (if you write OOP code, which you should be doing). This error needs to be handled somewhere.

He talks about how things like field and value validation can help prevent errors further down the road. He mentions the split between application and domain logic and suggests that it's the role of the app logic to prevent bad data from making it thorough to the domain.

In software development, it is crucial that you handle any errors as soon as they occur. This requires you to actually realize that an error has occurred.
0 comments voice your opinion now!
urban legend error handling domain application logic validation

Link: http://thephp.cc/viewpoints/blog/2013/06/urban-legends-and-error-handling

PHPMaster.com:
Implementing a Unit of Work - Handling Domain Objects through a Transactional Model
May 31, 2012 @ 09:53:03

In this new post to PHPMaster.com, Alejandro Gervasio looks at working with domain objects via a transactional system using the Unit of Work design pattern.

In fact, it's feasible to wrap collections of domain objects inside a fairly flexible business transactional model and just perform several database writes/deletes in one go, therefore avoiding having to break down the process into more atomic and expensive database calls, which always lead to the session-per-operation antipattern. Moreover, this transaction-based mechanism rests on the academic formalities of a design pattern commonly known as Unit of Work (UOW), and its implementation in several popular enterprise-level packages, such as Hibernate, is quite prolific and prosperous.

He shows how to implement the "Unit of Work" design pattern via a "UnitOfWorkInterface" and a "UnitOfWork" class that implements it. The class provides methods for things like entity handling (CRUD operations) and working with the data mapper for the transactions. He also includes the code to implement the data mapper, a layer on top of a PDO-based interface that also provides CRUD operations for the data records. From this, he defines a domain model, "User", and shows how to create a new user, register it with the UnitOfWork instance and do things like update a property, delete the record and pull out the user's information.

0 comments voice your opinion now!
unitofwork designpattern domain model tutorial


PHPMaster.com:
An Intro to Virtual Proxies, Part 2
April 26, 2012 @ 09:24:23

Following up on his previous article, Alejandro Gervasio has a new post to PHPMaster.com with the second part of his series on using virtual proxies in PHP.

Resting on the foundation of Polymorphism (dynamic Polymorphism, not the ad-hoc one often achieved through plain method overriding), Virtual Proxies are a simple yet solid concept which allows you to defer the construction/loading of expensive object graphs without having to modify client code.

He shows how to create a collection of domain objects that use proxies to populate their data. He includes the code for creating a "Post" interface/object as well as a Comment interface/object. These are put into a "CommentCollection" and, when it's accessed, pull the item in the collection out, only populating the data on demand.

0 comments voice your opinion now!
virtual proxies introduction series collection domain object


PHPMaster.com:
Building a Domain Model - Integrating Data Mappers
March 19, 2012 @ 11:27:26

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.

0 comments voice your opinion now!
integrate domain model data mapper tutorial pdo database


PHPMaster.com:
Building a Domain Model - An Introduction to Persistence Agnosticism
February 27, 2012 @ 12:58:00

On PHPMaster.com there's a recent tutorial introducing the concept of a "domain model" and showing how to create them in PHP (manually, not inside of any ORM or database solution).

First off, creating a rich Domain Model, where multiple domain objects with well-defined constraints and rules interact, can be a daunting task. Second, not only is it necessary to define from top to bottom the model itself, but it's also necessary to implement from scratch or reuse a mapping layer in order to move data back and forward between the persistence layer and the model in question.

They include an example of a set of domain models tat relate to one another - a blog setup with posts, comments and users. They show how to create the AbstractEntity to handle a bit of the magic behind the scenes, an example "Post" and "Comment" models and how they can be put to work creating some posts and appending comments. A little bit of markup is included to output the results.

0 comments voice your opinion now!
domain model relation tutorial blog post comment user



Community Events





Don't see your event here?
Let us know!


zendserver api update language introduction install release deployment package list laravel library series framework interview symfony opinion community tips podcast

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework