我想补充一下Alexandre的回答，让你的控制器保持“薄”被认为是最佳实践。换句话说，只将真正需要的代码放在控制器中（或者如果只有将其放在控制器中才有意义）。
服务就像您可以在应用程序中使用的工具。对象中的服务，帮助您执行某些操作。在一个服务中，您可以拥有许多功能。我认为理解两者区别的最好方法是，控制器用于一个特定的操作，而服务可以用于许多操作。因此，如果您希望在多个控制器中使用部分代码，请为其创建一个服务。为了可重用性，在服务中创建只做一件事的函数。这沿着使用这些功能更加容易。

“最佳实践”取决于您想对服务做什么。如果你构建了一个REST-Api，你可能想在Controller中执行数据库操作。为什么？当你依赖SOLID-Pattern时，你想要减少或消除冗余代码。如果你编写一个真实的的REST API，你就不会有多余的代码，因为每个REST动词都会做不同的查询/事情。因此，在非REST API应用程序中，您将拥有大量冗余代码。你在不同的页面/控制器操作上做同样的事情/服务。因此，最好的做法是在服务中实现所有业务逻辑，使其只在一个地方出现一次。如果你有很多单独的查询，把它们放到存储库中。如果您有适合实体类的业务逻辑，请将它们放在那里。因此，在我看来，你可以在API中选择厚控制器/无服务设计，在经典的symfony前端/后端应用程序中选择薄控制器/厚服务设计。但还有一件事设计应用程序没有完全错误的方法。但是如果你和其他人一起工作，或者想运行一个月以上的应用程序（没有维护它的麻烦），你应该选择一个通用的设计模式。

Controller必须实现application逻辑，例如检查是否是post请求或是否提交表单等...不要直接在控制器内部使用DQL或任何SQL Request！
EDIT在示例中，我在控制器中使用find方法，因为它是一个Repository方法，但我在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());
}

字符串
希望这对你有帮助