php - 在 Controller 中进行事务管理是不好的做法吗？

Question

我正在使用 Yii 框架开发一个 PHP/MySQL 应用程序。

我遇到过以下情况:

在我的 VideoController 中，我有一个创建新视频的 actionCreate 和设置视频隐私的 actionPrivacy。问题是在 actionCreate 期间，Video 模型的 setPrivacy 方法被调用，该方法当前有一个事务。我希望视频的创建也可以在事务中进行，这会导致错误，因为事务已经处于事件状态。

在 this answer 的评论中, 比尔·卡尔文写道

So there's no need to make Domain Model classes or DAO classes manage transactions -- just do it at the Controller level

在 this answer :

Since you're using PHP, the scope of your transactions is at most a single request. So you should just use container-managed transactions, not service-layer transa. That is, start the transaction at the start of handling the request, and commit (or rollback) as you finish handling the request.

如果我在 Controller 中管理事务，我会得到一堆看起来像这样的代码:

public function actionCreate() {
  $trans = Yii::app()->getDb()->beginTransaction();
  ...action code...
  $trans->commit();
}

这会导致在我需要为操作进行事务处理的很多地方出现重复代码。

或者我可以将它重构为父 Controller 类的 beforeAction() 和 afterAction() 方法，然后它们会自动创建事务对于正在执行的每个操作。

这种方法会有问题吗？ PHP 应用程序的事务管理的良好做法是什么？

Answer 1

我说事务不属于模型层的原因基本上是这样的:

模型可以调用其他模型中的方法。

如果模型尝试启动事务，但不知道其调用者是否已经启动事务，则模型必须有条件地启动事务，如代码示例所示@Bubba's answer .模型的方法必须接受一个标志，以便调用者可以告诉它是否允许开始自己的事务。否则模型必须能够查询其调用者的“事务中”状态。

public function setPrivacy($privacy, $caller){
    if (! $caller->isInTransaction() ) $this->beginTransaction();

    $this->privacy = $privacy;
    // ...action code..

    if (! $caller->isInTransaction() ) $this->commit();
}

如果调用者不是对象怎么办？在 PHP 中，它可以是静态方法，也可以是简单的非面向对象代码。这会变得非常困惑，并导致模型中出现大量重复代码。

这也是 Control Coupling 的一个例子，这被认为是不好的，因为调用者必须了解被调用对象的内部工作原理。例如，您的模型的 一些 方法可能具有 $transactional 参数，但其他方法可能没有该参数。调用者应该如何知道参数何时重要？

// I need to override method's attempt to commit
$video->setPrivacy($privacy, false);  

// But I have no idea if this method might attempt to commit
$video->setFormat($format); 

我看到的另一个解决方案(甚至在 Propel 等一些框架中实现)是在 DBAL 时使 beginTransaction() 和 commit() 无操作知道它已经在交易中。但是，如果您的模型尝试提交并发现它并没有真正提交，这可能会导致异常。或者尝试回滚并忽略该请求。我以前写过关于这些异常的文章。

我建议的折衷方案是模型不了解交易。模型不知道它对 setPrivacy() 的请求是否应该立即提交，或者它是更大图景的一部分，是涉及多个模型的更复杂的一系列更改，应该只有在所有这些更改都成功后才会提交。 这就是交易的重点。

因此，如果模型不知道他们是否可以或应该开始并提交自己的事务，那么谁知道呢？ GRASP 包括一个 Controller pattern这是一个用例的非 UI 类，它被分配了创建和控制所有部分以完成该用例的责任。 Controller 了解事务，因为在此可以访问有关完整用例是否复杂的所有信息，并且需要在模型中、在一个事务中(或者可能在多个事务中)进行多次更改。

我之前写过的例子，就是在MVC Controller的beforeAction()方法中启动一个事务，并在afterAction()方法中提交, 是一个简化。 Controller 应该可以自由地启动和提交逻辑上需要的尽可能多的事务以完成当前操作。或者有时 Controller 可以避免显式事务控制，并允许模型自动提交每个更改。

但关键是关于哪些交易是必要的信息是模型不知道的——他们必须被告知(以 $transactional 参数的形式)或者从他们的调用者，无论如何它都必须将问题一直委托(delegate)给 Controller 的操作。

您也可以创建 Service Layer每个类都知道如何执行如此复杂的用例，以及是否将所有更改包含在单个事务中。这样可以避免大量重复的代码。但是 PHP 应用程序包含不同的服务层并不常见。 Controller 的 Action 通常与服务层重合。