24

在阅读了很多帖子和 Stack Overflow 资源后,我仍然对著名的问题“业务逻辑放在哪里?”有些问题。阅读StackOverflow QuestionA Blog Post,我相信我已经很好地理解了代码分离的问题。

假设我有一个 Web 表单,您可以在其中添加将添加到数据库的用户。此示例涉及以下概念:

  • 形式
  • 控制器
  • 实体
  • 服务
  • 存储库

如果我没有错过什么,您必须创建一个具有一些属性、getter、setter 等的实体,以使其持久保存到数据库中。如果您想获取或编写该实体,您将使用entityManagerand,对于“非规范”查询entityRepository(这是您可以适合您的“查询语言”查询的地方)。

现在您必须为所有业务逻辑定义一个服务(即一个带有“惰性”实例的 PHP 类);这是放置“重”代码的地方。一旦您将服务记录到您的应用程序中,您几乎可以在任何地方使用它,这涉及代码重用等。

当您渲染和发布表单时,您将它与您的实体绑定(当然还有约束),并使用上面定义的所有概念将所有内容放在一起。

所以,“老我”会这样写控制器的动作:

public function indexAction(Request $request)
    {
        $modified = False;
        if($request->getMethod() == 'POST'){ // submit, so have to modify data
            $em = $this->getDoctrine()->getEntityManager();
            $parameters = $request->request->get('User'); //form retriving
            $id = $parameters['id'];
            $user = $em->getRepository('SestanteUserBundle:User')->find($id);
            $form = $this->createForm(new UserType(), $user);
            $form->bindRequest($request);
            $em->flush();
            $modified = True;
        }

        $users = $this->getDoctrine()->getEntityManager()->getRepository('SestanteUserBundle:User')->findAll();
        return $this->render('SestanteUserBundle:Default:index.html.twig',array('users'=>$users));
    }

“New-me”以这种方式重构了代码:

   public function indexAction(Request $request)
    {
        $um = $this->get('user_manager');
        $modified = False;
        if($request->getMethod() == 'POST'){ // submit, so have to modify data
            $user = $um->getUserById($request,False);
            $form = $this->createForm(new UserType(), $user);
            $form->bindRequest($request);
            $um->flushAll();
            $modified = True; 
        }
        $users = $um->showAllUser();
        return $this->render('SestanteUserBundle:Default:index.html.twig',array('users'=>$users));
    }

哪里$um是自定义服务,其中存储了从 #1 代码段到 #2 代码段您看不到的所有代码。

所以,这是我的问题:

  1. 我是否最终了解了 symfony2 和 {M}VC 的本质?
  2. 重构好不好?如果没有,有什么更好的方法?

Post Scriptum:我知道我可以使用 FOSUserBundle 进行用户存储和身份验证,但这是一个自学如何使用 Symfony 的基本示例。此外,为了工作,我的服务被注入了 ORM.Doctrine.* (只是为谁读过这个问题而感到困惑)

4

4 回答 4

4

关于将业务逻辑放在何处有两种主要方法:SOA 架构和领域驱动架构。如果您的业务对象(实体)乏善可陈,我的意思是,如果它们没有业务逻辑,只有 getter 和 setter,那么您会更喜欢 SOA。但是,如果您在业务对象中构建业务逻辑,那么您会更喜欢另一个。Adam Bien 讨论了这些方法:

使用 Java EE 6 进行领域驱动设计:http ://www.javaworld.com/javaworld/jw-05-2009/jw-05-domain-driven-design.html

使用 Java EE 6 的精益服务架构:http ://www.javaworld.com/javaworld/jw-04-2009/jw-04-lean-soa-with-javaee6.html

它是 Java,但您可以理解。

于 2012-07-17T13:27:26.187 回答
0

重构好不好?如果没有,有什么更好的方法?

最佳框架实践之一是使用参数转换器直接从用户请求调用实体

Symfony 文档中的示例:

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\ParamConverter;

/**
 * @Route("/blog/{id}")
 * @ParamConverter("post", class="SensioBlogBundle:Post")
 */
public function showAction(Post $post)
{

}

有关参数转换器的更多信息

http://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/converters.html

于 2016-05-15T19:37:28.337 回答
0

Robert C. Martin(清洁代码的人)在他的新书清洁架构中说,你应该把你的业务逻辑独立于你的框架,因为框架会随着时间而改变。

所以你可以把你的业务逻辑放在一个单独的文件夹中,比如 App/Core 或 App/Manager 并避免这里的 symfony 类的继承:

<?php

namespace App\Core;


class UserManager extends BaseManager implements ManagerInterface
{

}
于 2018-06-11T07:45:43.953 回答
-1

我意识到这是一个老问题,但由于我有类似的问题,我想分享我的经验,希望它可能对某人有所帮助。我的建议是引入命令总线并开始使用命令模式。工作流程几乎是这样的:

  1. 控制器接收请求并将其转换为命令(可能会使用表单来执行此操作,并且您可能需要一些 DTO 将数据从一层干净地移动到另一层)
  2. 控制器将该命令发送到命令总线
  3. 命令总线查找处理程序并处理命令
  4. 然后控制器可以根据它的需要生成响应。

基于您的示例的一些代码:

public function indexAction(Request $request)
{
    $command = new CreateUser();
    $form = $this->createForm(new CreateUserFormType(), $command);
    $form->submit($request);
    if ($form->isValid()) {
        $this->get('command_bus')->handle();
    }
    return $this->render(
        'SestanteUserBundle:Default:index.html.twig', 
        ['users' => $this->get('user_manager')->showAllUser()]
    );
}

然后您的命令处理程序(实际上是服务层的一部分)将负责创建用户。这有几个优点:

  • 您的控制器不太可能变得臃肿,因为它们几乎没有逻辑
  • 您的业​​务逻辑与应用程序 (HTTP) 逻辑分离
  • 您的代码变得更具可测试性
  • 您可以重用相同的命令处理程序,但数据来自不同的端口(例如 CLI)

还有一些缺点:

  • 应用此模式所需的类数量更多,并且通常与应用程序公开的功能数量成线性关系
  • 有更多的移动部件,而且更难推理,因此团队的学习曲线可能会更陡峭。

几个值得注意的命令总线:

https://github.com/thephpleague/tactician https://github.com/SimpleBus/MessageBus

于 2016-05-15T19:03:27.720 回答