If you need to develop flexible, highly-extendable PHP applications that can be interfaced easily with different client layers, you will want to consider a service layer. As a fundamental pillar of Domain Driven Design (DDD), a service is an enterprise-level pattern that will let you encapsulate application logic behind a single interface -- which can be consumed by distinct clients (yes, including your carefully-crafted action controllers!) while keeping code duplication to a minimum. There's little sense to highlighting the benefits of a service layer without providing proof. To partially address this issue, in the introductory part of this series I started building a sample application. It will use the functionality offered by a service to manipulate some user entities. Admittedly, in its current state the application looks somewhat skeletal. I only managed to create its domain model, which is pretty simplistic. In this second installment, however, I’m going to turn it into a slightly more functional structure. And how will I do that? Well, we need to build an additional layer that permits you to bridge the domain model with the underlying storage mechanism (not yet implemented). Not surprisingly, this new layer will be made up of some easily customizable data mappers. With that said, are you ready to continue this educational journey of building a service in PHP? Then jump in and start reading! Recap time: a brief look at the application’s domain model Just in case you missed the preceding part of this series, where I developed the sample domain model, below I included its source classes. The first class is an abstract parent, responsible for modeling the common structure and behavior of generic entities. Here it is: (MyApplication/Entity/AbstractEntity.php) <?php namespace MyApplicationEntity; abstract class AbstractEntity /** /** /**
(MyApplication/Entity/EntityException.php) <?php namespace MyApplicationEntity; class EntityException extends Exception{} While at first glance the implementation of the above “AbstractEntity” class seems intimidating, this is a mistaken impression, trust me. In fact, the class simply uses some PHP magic methods to get and fetch the values assigned to the fields of an entity. This process can be performed either via the corresponding mutators/getters (if they exist) or by using the protected $_values array. Got it? Great. And now that you understand the logic of the previous class, it’s time to look at the next one. This is a derivative of the abstract parent, tasked with modeling plain user objects. Check it out: (MyApplication/Entity/User.php) <?php namespace MyApplicationEntity; class User extends AbstractEntity There you have it. With minor effort, I managed to set up a basic, yet functional domain model, composed of only a few simple user entities. So, what’s the next step? Well, considering that the model must be persisted in some form, it’s necessary to build a new layer that acts like a mediator with the persistence mechanism. Usually, this layer is implemented through some mapping classes, and I’ll be using this approach. So, in the following section I’m going to create a couple of data mappers. They will be responsible for performing CRUD operations with the user entities present in the domain model. To see how these mappers will be developed, click on the link below and keep reading.
blog comments powered by Disqus |
|
|
|
|
|
|
|