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

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

一个招聘类通常做的一件事，它的定义handle()方法。很难从比较中排除排队的作业，因为同步运行通常会破坏目的，即在当前请求完成并显示响应后处理缓慢，昂贵或不可靠的操作（例如调用Web API）给用户。

如果期望所有作业都是同步的，则与为您的业务逻辑定义功能没有什么不同。这实际上与调度同步作业的工作非常接近：在调用堆栈的某个地方，它最终运行call_user_func([$job, 'handle'])以在作业对象上调用单个方法。更重要的是，同步作业缺少重试可能由于外部原因（例如网络故障）而失败的作业的机制。

服务，而另一方面，在封装周围的逻辑的简单方法组成，他们可能会做多件事情。在这种情况下，组件可能被认为是您的应用程序的一部分，可以将其替换为其他实现，而无需修改使用该组件的代码。框架中包含的一个完美示例是Filesystem服务（最常通过Storage立面访问的服务）。

考虑是否不是通过将书籍插入数据库来存储书籍，而是通过发布到外部API来存储书籍。你可能有一个BookRepository 服务，不仅有一个store()方法，但也有get()，update()，list()，delete()，或任意数量的其他方法。所有这些请求都共享用于对外部Web服务进行身份验证的逻辑（例如，向请求中添加标头），并且BookRepository类可以封装该可重用逻辑。您可以在预定的工匠命令，Web控制器，API控制器，作业，中间件等内部使用此服务类-无需重复代码。

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