php - Laravel 模式 - 作业与服务的使用

Question

我想知道大多数开发人员如何使用这两个 Laravel 工具。

在 Laravel 中，您可以使用服务或作业处理业务逻辑(我们只讨论不可排队的作业，只讨论那些在同一进程中运行的作业)。

例如，用户想要创建一个实体，比方说一本书，您可以使用服务或调度作业来处理实体创建。

使用作业会是这样的:

class PostBook extends Job
{
    ...
    public function handle(Book $bookEntity)
    {
        // Business logic here.
    }
    ...
}

class BooksController extends Controller
{
    public function store(Request $request)
    {
        ...
        dispatch(new PostBook($request->all()));
        ...
    }
}

使用服务，它会是这样的:

class BookService
{
    public function store(Request $request)
    {
        // Business logic here.
    }
}

class BooksController extends Controller
{
    public function store(Request $request)
    {
        ...
        // I could inject the service instead.
        $bookService = $this->app()->make(App\Services\BookService::class);
        $bookService->store($request);
        ...
    }
}

问题是，您通常如何选择使用一种方式或另一种方式？为什么？

在这件事上肯定有两个“学校”，但我想了解每个学校的优缺点。

Answer 1

“业务逻辑”可以用任何东西处理，所以看起来真正要问的是哪个选项更适合重复相同的业务逻辑而不重复代码。

Job 类通常做一件事，由它的handle() 方法定义。很难从比较中排除排队的作业，因为同步运行它们通常会违背处理缓慢、昂贵或不可靠的操作(例如调用 Web API)的目的。已完成并已向用户显示响应。

如果期望所有作业都是同步的，那么这与为您的业务逻辑定义一个函数 没有太大区别。这实际上非常接近分派(dispatch)同步作业所做的事情:在调用堆栈的某个地方，它最终运行 call_user_func([$job, 'handle']) 以调用作业对象上的单个方法。更重要的是，同步作业缺乏重试作业的机制，这些作业可能由于网络故障等外部原因而失败。

服务，另一方面，是围绕组件封装逻辑的一种简单方法，并且它们可以做不止一件事。在这种情况下，组件可以被认为是您的应用程序的一部分，可以换出不同的实现而无需修改使用它的代码。框架中包含的一个完美示例是 Filesystem 服务(最常通过 Storage facade 访问)。

考虑一下，如果您不是通过将书籍插入数据库来存储书籍，而是通过发布到外部 API 来存储书籍。您可能有一个 BookRepository 服务，它不仅有一个 store() 方法，还有一个 get()、update( )、list()、delete() 或任意数量的其他方法。所有这些请求都共享用于向外部 Web 服务进行身份验证的逻辑(例如向请求添加 header )，并且您的 BookRepository 类可以封装该可重用逻辑。您可以在计划的 artisan 命令、Web Controller 、API Controller 、作业、中间件等内部使用此服务类，而无需重复代码。

使用此示例，您可以创建一个作业 来存储一本新书，这样您就不会在 API 响应缓慢时让用户等待(并且它可以在出现故障时重试)。在内部，您的作业在运行时会调用您的服务 store() 方法。服务完成的工作由作业安排。