DO NOT MERGE. This PR is part of a request for comments regarding the service layer.

This PR is a demonstration of how com_contact might be refactored to use the service layer implemented in https://github.com/chrisdavenport/service. This contains a dependency on PHP 5.5 and so cannot be merged, even if it was considered ready, which it isn't.

Request for Comments: Service Layer

One of the issues we're often faced with as developers is that our components, including the core components, do not have a clearly defined API. For example, if I want to retrieve some article data from the com_content component I could try instantiating one of com_content's controller or model classes, but this is often inconvenient as they often exhibit unwanted side-effects that are difficult to overcome. Sometimes developers will even resort to reading or writing data directly in the database tables of another component. This is all very far from ideal, especially as the core component classes and database schema are not subject to the backwards-compatibility promise inherent in our development strategy. In effect, if I attempt to use these classes or tables directly my code could break at any time.

Furthermore, there is increasing pressure to support "channels" that are different from the traditional web channel. For example, it is common nowadays to need access to data from a command line (CLI) program. Most component controllers are written on the assumption that they are being called from a web environment and odd behaviour can result from calling them directly from a CLI program. By carefully separating channel-specific code, which belongs in channel-specific controllers, from other code which is moved into the service layer, it becomes possible to use components across multiple channels reliably.

The introduction of a Service Layer directly addresses these problems by supporting the definition of a component-level API that can be used across a variety of channels. The intention is that the core components can eventually be refactored to use the service layer and the API thus defined can be brought into the scope of the backwards-compatibility promise. Third-party extensions, or even other core extensions, can then confidently make use of the API without fear that future updates will break code unexpectedly.

Although it's early days, this is also intended to be part of the migration strategy for moving extension code to Joomla 4.

Note that the service layer is optional and enhances the regular MVC structure without necessarily changing any existing code in models and views. In most cases the principal impact will be on controllers and generally results in much simpler, slimmer controllers by shifting most of the logic into command, query and event handlers. More detailed documentation on what it does and how to install and use it can be found here: https://github.com/chrisdavenport/service. This development is also significant in that it begins to introduce some tactical concepts from Domain-Driven Design into Joomla.

The current version of the service layer is written as a standalone package and requires Composer to install it. Note that at the present time there is a dependency on the League Tactician command bus which has a PHP 5.5 minimum requirement. This will be dealt with (somehow) later.

What I need...

Feedback. Testing. Improvements. Unit tests moved to PHPUnit/CodeCeption.

Also, I'm not really happy with the use of the DI container to deliver the command and query bus implementations. One of the reasons for using a bus is to make it easy to extend the functionality of the bus by supplying your own decorators (middleware), either globally or at the component level. However, the current implementation doesn't make this easy. I'm sure there's a better way.

All comments welcome.