php - Zend Framework 2、Doctrine 2 以及业务逻辑适合的位置

Question

考虑到我希望能够将用户保存到数据库中，我的添加操作如下:

    public function addAction()
    {

    $form = new UserForm();
    $form->get('submit')->setValue('Add');

    $request = $this->getRequest();

    if ($request->isPost()) {

        $userFilter = new UserFilter();
        $form->setInputFilter( $userFilter->getInputFilter() );
        $form->setData( $request->getPost() );

        if ($form->isValid())

            $user = new User();
            $user->setEmail($form->getInputFilter()->getValue('email')  );
            $user->setNome( $form->getInputFilter()->getValue('name') );


            $em = $this->getServiceLocator()->get('Doctrine\ORM\EntityManager');
            $em->persist($user);
            $em->flush();


            return $this->redirect()->toRoute('user');

        }
    }

    return array('form' => $form);
    }

将用户保存到数据库非常容易，但是如果我需要添加一些复杂的业务逻辑，让我想检查电子邮件是否是唯一的，并且我还想访问一些网络服务来检查是否是最终的答案生命、宇宙和一切的问题真的是 42，如果是真的，我想将用户保存到数据库中，如果不是，我想向用户显示一条消息。

可以添加操作，但据我所知，这不是一个很好的做法，我可以将此业务逻辑放在实体用户中，但这会增加 zf2 和学说与实体之间的耦合，这也是坏的。在网上搜索解决方案，答案似乎是将业务逻辑放在服务层中。

考虑到服务层解决方案，可以创建一个类 UserBusinessLogic 并创建一个方法保存，该方法将执行业务逻辑并在一切正常时保存用户。

这听起来对吗？是否有关于该主题的文档？也许是一个代码示例，展示了如何使用 doctrine 2 和 zf2 以及服务来处理业务逻辑。

我想底线是:在使用 zf2 和 doctrine 2 时，将业务逻辑放在哪里的最佳实践是什么？

假设服务解决方案是最佳选择。如果我有实体用户、组以及这两者之间的关系，我将创建一个名为“访问”的服务，该服务将从 Controller 接收数据以将用户保存为一个组，链接这两个并执行任何其他任务，例如发送邮件以重置用户密码。这听起来对吗？

Answer 1

你的想法是正确的。为了进一步分离 Doctrine 2，您可以创建另一个层，它遵循 Zend\Db 中的一个接口(interface)，但使用 Doctrine 来完成数据库交互。

此外，为了进行验证，您可以为使用 Doctrine 检查数据库的表单创建自定义输入过滤器。

这个想法是，只要方法名称保持不变，就可以通过更改服务来替换服务背后的任何内容。这样你以后就可以用 Propel 替换 Doctrine，例如，你不必重构你的 Controller 和 View ，只需重构服务类。