如何使用 Service 模式

如何使用 Service 模式

若将数据库逻辑都写在 Controller 里,会造成 Controller 代码的臃肿难以维护,基于 SOLID 原则,我们应该使用 Service 模式辅助 Controller,将相关的业务逻辑封装在不同的 Service,方便项目的后期维护。

Laravel 框架版本

Laravel 5.4.17

业务逻辑

业务逻辑中,常见的如:

  • 牵涉到外部行为: 如 发送 Email 邮件使用外部API ..

  • 使用 PHP 写的逻辑: 如 根据购买的数量,给予不同的折扣

Service

牵涉到外部的行为

如 发送Email,常常会在 Controller 中直接调用 Mail::queue()

 /**
 * @param \Illuminate\Http\Request $request
 */
public function store(Request $request)
{
    \Mail::queue('email.index', $request->all(), function (Message $message) {
        $message->sender(env('MAIL_USERNAME'));
        $message->subject(env('MAIL_SUBJECT'));
        $message->to(env('MAIL_TO_ADDR'));
    });
}

在中大型的项目中,会有几个问题:

  • 将牵涉到外部行为的逻辑写在 Controller,造成 Controller 代码臃肿难以维护

  • 违反 SOLID 的单一职责原则:外部行为不应该写在 Controller

  • Controller 直接相依于外部行为,使得我们无法对 Controller 做单元测试

比较好的方式是使用 Service,使用的步骤如下:

  • 将外部行为注入到 Service

  • 在 Service 使用外部行为

  • 将 Service 注入到 Controlelr

app\Services\EmailService.php

<?php

namespace App\Services;
use Illuminate\Mail\Message;
use Mail;

/**
 * Class EmailService
 *
 * @package \App\Services
 */
/**
 * Class EmailService
 *
 * @package App\Services
 */
class EmailService
{
    /**
     * @var \Mail
     */
    protected $mailer;

    /**
     * 将相依的 Mailer 注入到 EmailService
     * EmailService constructor.
     *
     * @param $mailer
     */
    public function __construct(Mail $mailer)
    {
        $this->mailer = $mailer;
    }

    /**
     * 发送 Email的逻辑写在 send() 不是使用 Mail Facade,而是使用 $this->mailer
     * @param array $request
     */
    public function send(array $request)
    {
        $this->mailer->queue('email.index',$request,function(Message $message){
            $message->sender(env('MAIL_USERNAME'));
            $message->subject(env('MAIL_SUBJECT'));
            $message->to(env('MAIL_TO_ADDR'));
        });
    }
}

app\Controllers\UserController.php

<?php

namespace App\Http\Controllers;

use App\Services\EmailService;
use Illuminate\Http\Request;

/**
 * Class UserController
 *
 * @package App\Http\Controllers
 */
class UserController extends Controller
{
    /**
     * @var \App\Services\EmailService
     */
    protected $emailService;

    /**
     * @param \Illuminate\Http\Request $request
     */
    public function store(Request $request)
    {
        $this->emailService->send($request->all());
    }
}

从原本相依于 Mail Facade ,改成相依于注入的 EmailService

改用这种写法有几个优点,如下:

  • 将外部行为写在 Service,解决了 Controller 代码臃肿的问题。

  • 符合 SOLID 的单一职责原则: 外部行为写在 Service ,没写在 Controller。

  • 符合 SOLID 的依赖反转原则:Controller 并非直接相依于 Service,而是将 Service 依赖注入进 Controller。

使用 PHP 写的逻辑

如 根据用户购买数量,给予同步的折扣,可能我们会在 Controller 直接写 if () { ... } else { ... } 逻辑。如下app\Controllers\UserController.php

public function index(Request $request)
{
    $number = $request->input('number');
    $price = 500;
    $discount = 1;
    if ($number == 1) {
        $discount = 1;
    } elseif ($number == 2) {
        $discount = 0.9;
    } elseif ($number == 3) {
        $discount = 0.8;
    } else {
        $discount = 0.7;
    }
    $total = $price * $number * $discount;

    return $total;
}

在中大型项目中,会有几个问题:

  • 将 PHP 写的业务逻辑直接写在 Controller ,造成 Controller 的代码臃肿难以维护

  • 违反了 SOLID 的单一职责原则:业务逻辑不应该写在 Controller

  • 违反了 SOLID 的单一职责原则:若未来想要改变折扣的写算法,都需要用到此 Method,也也就是说这个 Method 同时包含了计算折扣于计算加总的职责,因此违反了 SOLID 的单一职责原则

  • 直接写在 Controller 的逻辑无法被其他 Controller 使用

app\Services\OrderService.php

<?php

namespace App\Services;

/**
 * Class OrderService
 *
 * @package App\Services
 */
/**
 * Class OrderService
 *
 * @package App\Services
 */
class OrderService
{
    /**
     * 计算折扣
     *
     * @param $number
     *
     * @return float
     */
    public function getDisCount($number)
    {
        switch ($number) {
            case 1:
                return 1.0;
                break;
            case 2:
                return 0.9;
                break;
            case 3:
                return 0.8;
                break;
            default:
                return 0.7;
        }
    }

    /**
     * 计算最后价格
     *
     * @param $number
     * @param $discount
     *
     * @return int
     */
    public function getTotal($number, $discount)
    {
        return 500 * $number * $discount;
    }
}

在 Controller 中调用代码,如下:

<?php

namespace App\Http\Controllers;

use App\Services\OrderService;
use Illuminate\Http\Request;

/**
 * Class UserController
 *
 * @package App\Http\Controllers
 */
class UserController extends Controller
{
    /**
     * @var \App\Services\EmailService
     */
    protected $orderService;

    /**
     * UserController constructor.
     *
     * @param \App\Services\OrderService $orderService
     */
    public function __construct(OrderService $orderService)
    {
        $this->orderService = $orderService;
    }

    /**
     * @param \Illuminate\Http\Request $request
     *
     * @return int
     */
    public function index(Request $request)
    {
        $number = $request->input('number');
        $discount = $this->orderService->getDisCount($number);
        return $this->orderService->getTotal($number, $discount);
    }
}

将原本的 if () { .. } else { .. } 逻辑改写成使用 OrderService,Controller 变得非常感觉,也达成原来 Controller 接受 Http Request,调用其他 Class 的责任。

改用这种写法的几个优点:

  • 将 PHP 写的业务逻辑写在 Service ,解决了 Controller 代码臃肿的问题

  • 符合 SOLID 的单一职责原则: 业务逻辑写在 Service,没写在 Controller

  • 符合 SOLID 的单一职责原则:计算折扣与计算加总分开在不同的 Method,且归属于 OrderService,而非 Controller

  • 符合 SOLID 的依赖反转原则: Controller 并非直接相依于 Service,而是将 Service 依赖注入进 Controller

  • 其他 Controller 也可以重复使用这段业务逻辑

结束

  • 实际上会有很多 Service ,需要自行依照 SOLID 原则去判断是否该建立 Service

  • Service 使得业务逻辑从 Controller 中解放,不仅更容易维护、更容易拓展、更容易重复使用且更容易测试

本作品采用《CC 协议》,转载必须注明作者和本文链接
houmuxu
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!