Laravel 5.5 Core Architecture detailed

This article mainly introduces the Laravel 5.5 core architecture of some in-depth understanding, the text through the graphic and sample code introduced in very detailed, the need for friends can reference, the following with the small series to learn together.

1. Dependency Injection

method to pass in the component name, the framework is automatically instantiated, and the method can be used directly

For example, the most commonly used Requert object

2. Service container

In fact, the core of Laravel is an IoC container, the core of Laravel itself is very lightweight, and there is no magic very substantial application function. The various functional modules used by many people such as route (routing), eloquent ORM (Database ORM component), request (requests), and response (response), etc., are actually provided by the core-independent class modules, which are from registration to instantiation, In the end, you are in charge of the Laravel service container.

Service providers are divided into two main sections, register (registration) and boot (boot, initialize)

3. Service Provider

A class must be registered to this container before it can be extracted by the container. Since Laravel calls this container a service container, then we need a service to register, bind the service to the container, then provide the service and bind the service to the container, that is, the service provider (services Provider).

4. Add your own class to the IOC container

4.1. New Validate Class

4.2. New Validateprovider

4.3, binding validate class to Provider

<?phpnamespace app\providers;use Illuminate\support\serviceprovider;class Validateprovider extends serviceprovider{/** * Bootstrap the application services. * @return void */Public Function boot () {//}/** * Registe R the application services.  * * @return void */Public Function Register () {$this->app->bind (' Valicate ', function () {  return new Validate (); }); }}

4.4. Add provider to IOC container

4.5. Use

4.6, Success!

5. Façade (facade)

Facade is used to provide a unified interface, such as whether you use the Cache,redis or memcache, the client can use the Cache::get () method to obtain value, as for the specific use of Redis or Memcahe, see you in Sevice Provider which is bound in the inside. Cache::get () is implemented by inheriting the facade method Getfacadeaccessor, returning the key value you have bound in the container, such as cache, and then the facade class will use the PHP Magic Variable __callstatic (), The callstatic logic will parse the service that the cache is bound to from the container, which is the one that was previously mentioned by the service provider.

5.1. For example, mail in config/app.php

5.2. This class returns only one mailer

5.3, if call its Send method, does not exist will enter into the magic method of Callstatic

5.4, this method will get mailer instance, namely the app (' Mailer ')

5.5. This instance can call the Send method of the mailer class

6. Contract

The Laravel contract is a set of interfaces that define the core services provided by the framework. For example, the Illuminate\contracts\queue\queue contract defines the methods that are required for a queue task, and the Illuminate\contracts\mail\mailer contract defines the methods that are required to send e-mail. The framework provides a corresponding implementation for each contract.

The advantage is the low coupling and simplicity of the program.

Low Coupling #

First, let's look at some of the code for high-coupling cache implementations. As follows:

<?phpnamespace app\orders;class repository{/** * Cache instance. */protected $cache; /** * Create a warehouse instance.  * * @param \somepackage\cache\memcached $cache * @return void */Public function __construct (\somepackage\cache\memcached $cache) {$this->cache = $cache;}/** * Retrieve ORDER BY Id * * @param int $id * @return Order */Public Function find ($id) { if ($this->cache->has ($id)) {  //}}}

In this class, the program is highly coupled with a given cache implementation. Because we rely on a particular cache class for an extension package. Once the API for this expansion pack has been changed, our code must be changed.

Similarly, if we want to replace the underlying cache technology (Memcached) with another cache technology (Redis), then we have to modify this repository class again. The repository class should not know too much about who provided the data or how it was provided, and so on.

Instead of doing this, we can improve our code with a simple interface that is independent of the expansion package:

<?phpnamespace app\orders;use illuminate\contracts\cache\repository as Cache;class Repository{/** * Cache instance. */protected $cache; /** * Create a warehouse instance. * * @param cache $cache * @return void */Public function __construct (cache $cache) {$this->cache = $cache;}}

Now, the code after the change is not coupled with any expansion packs or even Laravel. While the contract extension package does not contain any implementations and dependencies, you can easily write an alternative implementation of any given contract to implement a cache implementation without modifying any code about the cache consumption.