在symfony中使用服务而不是控制器的最佳实践是什么,而不仅仅是在那里?

控制器 必须执行 应用 逻辑上,比如检查它是一个POST请求,还是一个表单被提交等等。 从未 直接在控制器内使用DQL或任何SQL请求!

编辑 在这个例子中,我在控制器内部使用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());
}

希望这有帮助

我想补充一点,亚历山大的回答是,最好的做法是保持你的控制器“瘦”。换言之,只需将代码放在控制器中真正必须存在的地方(或者如果将代码放在控制器中是有意义的话)。

服务就像您可以在应用程序中使用的工具。对象中帮助您完成某些操作的服务。在一个服务中,您可以有许多功能。我认为理解区别的最好方法是控制器用于一个特定的操作,服务可以用于许多操作。因此,如果您有一些代码要在多个控制器中使用,请为它创建一个服务。为了重用,在您的服务中创建只做 一 事情。这使得在使用这些函数的过程中更加容易。

“最佳实践”取决于您希望如何使用服务。如果您构建一个RESTAPI,您可能需要在控制器中执行数据库操作。为什么?当您依赖实体模式时,您希望减少或消除冗余代码。如果您编写了一个真正的RESTAPI代码,那么就没有多余的代码,因为每个REST动词将执行不同的查询/操作。 因此,在非RESTAPI应用程序中,您将拥有大量冗余代码。您在不同的页面/控制器操作上执行相同的操作/服务。所以最好的事情是在服务中实现所有的业务逻辑,以便在一个地方只有一次。如果您有很多单独的查询,请将它们放在存储库中。如果您有适合实体类的业务逻辑,请将它们放在那里。因此,在我看来,您可以选择API中的厚控制器/无服务设计,以及经典symfony前端/后端应用程序中的薄控制器/厚服务设计。 但还有一件事:设计应用程序没有完全错误的方法。但是,如果您与其他人合作,或者希望运行应用程序超过一个月(而不需要维护它),那么您应该选择一个通用的设计模式。