7

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

    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 并创建一个方法 save 来执行业务逻辑并在一切正常的情况下保存用户。

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

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

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

4

1 回答 1

1

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

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

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

于 2013-06-09T18:56:33.740 回答