Laravel 5.5 core architecture detailed explanation

This article mainly introduces you to some in-depth understanding of the core architecture of Laravel 5.5. The article introduces it in great detail through pictures, texts and sample codes. Friends in need can refer to it. Let's learn together with the editor.

1. Dependency injection

method passes in the component name, and the framework will automatically instantiate it. You can use it directly in the method

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 nothing magical or substantial about it. Application functions. Various functional modules used by many people, such as Route (routing), Eloquent ORM (database ORM component), Request (request), Response (response), etc., are actually provided by class modules that have nothing to do with the core. The process from registration to instantiation of these classes to finally being used by you is actually the responsibility of Laravel's service container.

The service provider is mainly divided into two parts, register (registration) and boot (boot, initialization)

3. Service provider

A class must be owned by the container To be able to extract, you must first register to this container. Since Laravel calls this container a service container, if we need a service, we must first register and bind the service to the container. Then the thing that provides the service and binds the service to the container is the service provider (Service Provider).

4. Add your own class to the IOC container

4.1. Create a new validate class

4.2. Create a new validateProvider

4.3. Bind the validate class to Provider

<?php
namespace App\Providers;
use Illuminate\Support\ServiceProvider;
class ValidateProvider extends ServiceProvider
{
 /**
 * Bootstrap the application services.
 *
 * @return void
 */
 public function boot()
 {
 //
 }

 /**
 * Register the application services.
 *
 * @return void
 */
 public function register()
 {
 $this->app->bind('valicate',function(){
  return new Validate();
 });
 }
}

4.4. Add Provider to the IOC container

4.5. Use

4.6. Success!

5. Facade

The facade is used to provide a unified interface. For example, no matter which cache you use, redis or memcache, the client You can use cache::get() to get the value. Whether to use redis or memcahe depends on which one you bind to the service provider. The implementation of cache::get() is to inherit the Facade method getFacadeAccessor and return the key value you bind in the container, such as cache. Then the Facade class will use the PHP magic variable __callstatic(), and the callstatic logic will be from the container. Parse the service bound to the cache, which is who the service provider mentioned earlier is bound to

5.1, for example, mail

# in config/app.php ##5.2. This class only returns one mailer

5.3. If its send method is called, if it does not exist, it will enter the callstatic magic method

5.4. This method will get the instance of mailer, that is, app('mailer')

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

6. Contract

Laravel’s 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 required for queue tasks, while the Illuminate\Contracts\Mail\Mailer contract defines the methods required for sending emails. The framework provides corresponding implementations for each contract.

The advantage is that it achieves low coupling and simplicity of the program.

Low coupling

#First, let’s look at some code for high coupling cache implementation. As follows:

<?php
namespace App\Orders;
class Repository
{
 /**
 * 缓存实例。
 */
 protected $cache;
 /**
 * 创建一个仓库实例。
 *
 * @param \SomePackage\Cache\Memcached $cache
 * @return void
 */
 public function __construct(\SomePackage\Cache\Memcached $cache)
 {
 $this->cache = $cache;
 }

 /**
 * 按照 Id 检索订单
 *
 * @param int $id
 * @return Order
 */
 public function find($id)
 {
 if ($this->cache->has($id)) {
  //
 }
 }
}

In this class, the program is highly coupled with the given cache. Because we rely on a specific caching class from an extension package. Once the API of this extension is changed, our code must change accordingly.

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

Compared with the above approach, we can use a simple interface that has nothing to do with the extension package to improve our code:

<?php
namespace App\Orders;
use Illuminate\Contracts\Cache\Repository as Cache;
class Repository
{
 /**
 * 缓存实例。
 */
 protected $cache;

 /**
 * 创建一个仓库实例。
 *
 * @param Cache $cache
 * @return void
 */
 public function __construct(Cache $cache)
 {
 $this->cache = $cache;
 }
}

现在，更改之后的代码没有与任何扩展包甚至是 Laravel 耦合。而契约扩展包不包含任何实现和依赖项，你可以轻松地写任何给定契约的替代实现，来实现不修改任何关于缓存消耗的代码就可以替换缓存实现。

相关推荐：

Laravel 5.5实现前后台登陆

如何实现Laravel 5.5可响应接口

Laravel 5.5中为响应请求提供的可响应接口详解_php实例

The above is the detailed content of Laravel 5.5 core architecture detailed explanation. For more information, please follow other related articles on the PHP Chinese website!