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, 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


DevShed:
Building an ORM in PHP Domain Modeling
November 22, 2011 @ 16:46:10

Continuing on from the first part of their series, DevShed has posted part two of their "Building an ORM in PHP" series. This latest tutorial focuses on domain modeling (and collection handling).

In that first part, I implemented the ORM's data access and mapping layers. And as you'll surely recall, the entire implementation process was pretty straightforward and easy to follow. Of course, in its current state the ORM is still far from a fully-functional structure. We need to add some additional components to it, such as a domain model and the classes responsible for handling collections of entities (remember that the ORM relies heavily on the data mapper pattern to do its business properly).

He stays with his "simple blog" example and shows domain models (based on an abstract entity) for Entries, Comments and Authors. His containers extend the Countable, IteratorAggregate and ArrayAccess interfaces to give them some extra abilities.

0 comments voice your opinion now!
tutorial domain model orm database mapping relational


PHPMaster.com:
Localizing PHP Applications "The Right Way", Part 3
November 14, 2011 @ 08:38:48

PHPMaster.com has posted its third part of its "Localizing PHP Applications 'The Right Way'" series. In this third part you'll learn more about locales and message domain switching.

In Part 2 you gained more insight into using the gettext library by learning the most important functions of the extension. In this part you'll learn how to best use a fallback locale, switch between locales, and override the currently selected message domain.

They show you how to set up the directory structure to handle a fallback locale, a choice to use when the system can't determine which to use. By using a default, you also avoid having the system translate from the default language to...the default language (like "English" to "English"). Included are also the code bits you'll need to switch between locales (just using a different domain) and using the dgettext function to specify a different domain than the selected one.

0 comments voice your opinion now!
localize application gettext domain locale series part3



Community Events





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


series community interview podcast code install refactor introduction unittest configure language opinion list developer testing laravel framework wordpress threedevsandamaybe release

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