在Symfony中（而不是仅在控制器中）使用服务的最佳实践是什么？

Question

好吧，我正在学习Symfony（3.3），并且对Service Container不太困惑。 在第一个教程中，讲授者将在用户，文章控制器中显示注册，登录，添加帖子，编辑，删除方法。 然后在其他教程中，他们展示了相同的方法，但是将Service Container（User和Article服务）与User and Article interfaces一起User and Article interfaces 。 所以.. 在服务而不是控制器中实现的最佳实践是什么。

Answer 1

我想补充一下亚历山大的回答，这是使控制器保持“瘦身”的最佳实践。 换句话说，仅将确实必须存在的代码放入控制器中（或者仅在将其放入控制器中才有意义）。

服务就像您可以在应用程序中使用的工具。 对象中的一项服务，可以帮助您执行某些操作。 在一项服务中，您可以具有许多功能。 我认为理解差异的最好方法是，控制器用于一个特定的动作，服务可以用于许多动作。 因此，如果您要在多个控制器中使用某些代码部分，请为其创建服务。 并且为了可重用性，请在服务中创建仅做一件事的功能。 这使得在使用这些功能的过程中更加容易。

Answer 2

“最佳实践”取决于您要对服务执行的操作。 如果您构建REST-Api，则可能要在Controller中执行数据库操作。 为什么？ 当您依靠SOLID-Pattern时，您希望减少或消除冗余代码。 如果您编写一个真正的REST Api，则您不会有多余的代码，因为每个REST-Verb都会执行不同的查询/操作。 因此，在非REST-Api应用程序中，您将有很多冗余代码。 您在不同的页面/控制器操作上执行相同的操作/服务。 因此，最好的办法是在服务中实施所有业务逻辑，以使其一次只能在一个地方进行一次。 如果您有很多单个查询，请将其放入存储库中。 如果您有适合实体类的业务逻辑，请将它们放在那里。 因此，我认为您可以在API中选择厚控制器/无服务设计，而在经典symfony前端/后端应用程序中选择薄控制器/加厚服务设计。 但是还有一件事：设计应用程序没有完全错误的方法。 但是，如果您与其他人一起工作，或者想要运行一个月以上的应用程序（无需维护它），则应该选择一种通用的设计模式。

Answer 3

控制器必须实现应用程序逻辑，例如检查它是否为发布请求或是否提交表单等。 切勿直接在控制器内部使用DQL或任何SQL Request！

编辑在该示例中，我在控制器内部使用了find方法，因为它是存储库方法，但是我在slugify （我的服务方法）内部解析了结果

服务包含诸如格式化电话号码，解析一些数据等业务逻辑。当然，您可以在服务内部注入存储库并在其中调用您的方法。

一个例子：

//This is a fictive example
public function indexAction(Request $request) {
     //Application logic
     if(!$request->get('id')) {
         //redirect somewhere by example
     }
     $article  = $this->getDoctrine()
       ->getRepository(Article::class)
       ->find($request->get('id'));
     //Business Logic
     $slug = $this->get('my.acme.service')->slugify($article->getTitle());
}

希望这可以帮助