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);
    }

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

可以做添加操作但是我告诉这不是一个很好的做法，我可以把这个业务逻辑放在实体User中，但是这会在实体中添加zf2和doctrine之间的耦合，这也是坏。在网上搜索解决方案，答案似乎是将业务逻辑放在服务层中。

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

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

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

假设服务解决方案是最好的方法。如果我有实体用户，组以及这两者之间的关系，我会创建一个名为“access”的服务，这个服务将是从控制器接收数据以保存用户组，链接那些2并执行任何其他任务的服务。发送邮件以重置用户密码。听起来不错吗？

Answer 1

你有正确的想法。要重新解析Doctrine 2，您可以创建另一个跟随Zend \ Db中的一个接口的层，但使用Doctrine来完成数据库交互。

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

这个想法是，只要方法名称保持不变，就可以通过更改服务来替换服务背后的任何内容。这样，您可以稍后用Propel替换Doctrine，并且您不必重构您的控制器和放大器。观点，只是服务类。

Zend Framework 2，Doctrine 2以及Business逻辑适合的位置

1 个答案: