If you ever need to implement a pluggable structure that allow your PHP applications to interact easily with different client layers, such as several front-ends or multiple external APIs, then you might want to consider a service layer (http://martinfowler.com/eaaCatalog/serviceLayer.html). A service layer is an enterprise-level pattern that will let you achieve this kind of interaction by encapsulating application logic behind a single interface (AKA a boundary), which can be directly consumed by distinct clients. Of course, highlighting the benefits that a service offers without adding some functional code is pretty pointless. In previous parts of this series I went through the development of a sample application, whose main responsibility is to perform CRUD operations on a few user entities that reside in a domain model completely decoupled from the storage mechanism (in this case, a MySQL database). In its current state, the application is entirety functional. What’s more, with a little bit of effort from us, it’s perfectly feasible to fetch, save and remove user entities from the pertinent database simply by setting up a mapping layer. This layer would move data between the domain model and storage. However, making the mappers work directly with different clients is a rather inflexible approach, whose functionality is limited to that provided by the mappers themselves and nothing else. The big question, then, is this: how can the application be turned into a more flexible and abstract structure? This is exactly where a service layer comes into play. Sitting a service on top of the mappers would make it really simple to execute the aforementioned operations, plus any others needed by a different client layer. In this fifth installment I’ll be building such a service layer, so that you can see how easy it is to use it to manipulate user entities in all sorts of clever ways. Now, jump in and read the next few lines! Handling collections of entities: a quick look at the classes previously created As always, before I show you how to implement a functional user layer, we'll quickly review the topics that were covered in the last tutorial. Below I reintroduced the pair of classes developed in that tutorial, which are tasked with manipulating collections of entities. The first of these classes is an abstract one; it’s nothing but a simple array collection. Take a look at it: (MyApplication/Collection/AbstractCollection.php) <?php namespace MyApplicationCollection; abstract class AbstractCollection implements Iterator, Countable, ArrayAccess /** /**
(MyApplication/Collection/CollectionException.php) <?php namespace MyApplicationCollection; class CollectionException extends Exception{} As I just noted, the previous “AbstractCollection” class is a basic wrapper for a plain PHP array that permits you to iterate, access and count its elements in a simple way, thanks to the implementation of the Iterator, Countable and ArrayAccess SPL interfaces. Nothing really complex to grasp here, right? Now, we'll move on and look at the following subclass. It's a refined implementation of the earlier parent, and is charged with specifically handling collections of user entities: (MyApplication/Collection/UserCollection.php) <?php namespace MyApplicationCollection; class UserCollection extends AbstractCollection To learn the fine details of this process, click on the link below and keep reading.
blog comments powered by Disqus |
|
|
|
|
|
|
|