第25章 魔豆

“为什么加这么个小功能要花这么长时间？”经理指派你的团队扩展Bug跟踪系统，增加一个展示每个Bug有多少评论数量的功能。你的团队已经为此工作四周了。

在会议室里，你的组员们都羞于回答老板的问题。作为项目经理，你不得不回答：“我们在最开始的时候犯了几个错误，这个需求最初看起来实现很方便，后来我们意识到在程序中还有其他几个界面也需要展示评论数量。”

“设计这些界面要花四个礼拜？”经理问。

“这倒不是，这些界面只是一些HTML，由于我们用的框架是将代码和展示分离的，这些界面的开发很简单。”你继续说，“但每次我们要往界面上增加一点新的条目，必须复制一份同样的代码到这个界面的后端代码中，用以获取数据。这意味着每个后端的类都需要进行一系列新的测试。”

“我们难道没有使用测试框架？”经理问，“增加一些新的测试用例要花多久？”

“编写测试不像编写代码那么容易，”另一个工程师犹豫地说，“我们还要为编写脚本构建测试数据。接着要在每次测试之前重新将数据载入测试数据库中。我们还要测试前端，每个新增的特性都要针对老功能的每一种组合进行测试。”

经理眼睛瞪得大大的，但你的同事继续说着：“我们现在对于前端已经有600个测试用例了，每一个测试都会创建一个新的浏览器模拟器。时间都花在执行这些测试上了。”他耸耸肩，“我们对此无能为力。”

经理深吸了一口气，说：“好吧……你说的我并不全都理解，我只是想要知道为什么加这么一个简单的功能会变得如此复杂。你们所用的面向对象框架难道不支持快速、简单地添加新功能吗？”

好问题！

• 控制器接收用户的输入，定义一些程序需要完成的响应逻辑，再委托合适的模型执行操作，然后将结果返回给视图。
• 模型处理所有其他的事情，它们是程序的核心，包括输入验证、业务逻辑和数据库交互。
• 视图处理在用户界面展示信息。

2 Create, Read, Update Delete，增删改查操作。——译者注

3 参考Patterns of Enterprise Application Architecture中“Active Record”一章。

Magic-Beans/anti/doctrine.php
<?php $bugsTable = Doctrine_Core::getTable('Bugs');
 $bugsTable->find(1234);
 $bug = new Bugs();
 $bug->summary = "Crashes when I save";
 $bug->save();

参考《抽象泄露法则》[Spo02]

Magic-Beans/anti/crud.php
<?php
 class CustomBugs extends BaseBugs {
   public function assignUser(Accounts $a) {
     $this->assigned_to = $a->account_id;
     $this->save();
     mail($a->email, "Assigned bug", "You are now responsible for bug #{$this->bug_id}.");
   }
 }

Magic-Beans/anti/crud.php
$bugsTable = Doctrine_Core::getTable('Bugs');
$bugsTable->find(1234);
$bug->assigned_to = $user->account_id; $bug->save();

4 http://www.martinfowler.com/bliki/AnemicDomainModel.html。

Magic-Beans/anti/anemic.php
<php?
 class AdminController extends Zend_Controller_Action {
	public function assignAction() {
		$bugsTable = Doctrine_Core::getTable("Bugs");
		$bug = $bugsTable->find($_POST["bug_id"]);
		$bug->Products[] = $_POST["product_id"];
		$bug->assigned_to = $_POST["user_assigned_to"];
		$bug->save();
	}
}
class BugController extends Zend_Controller_Action {
	public function enterAction() {
		$bug = new Bugs();
		$bug->summary = $_POST["summary"];
		$bug->description = $_POST["summary"];
		$bug->status = "NEW";
		$accountsTable = Doctrine_Core::getTable("Accounts");
		$auth = Zend_Auth::getInstance();
		if ($auth && $auth->hasIdentity()) {
			$bug->reported_by = $auth->getIdentity();
		}
		$bug->save();
	}
	public function displayAction() {
		$bugsTable = Doctrine_Core::getTable("Bugs");
		$this->view->bug = $bugsTable->find($_GET["bug_id"]);
		$accountsTable = Doctrine_Core::getTable("Accounts");
		$this->view->reportedBy = $accountsTable->find($bug->reported_by);
		$this->view->assignedTo = $accountsTable->find($bug->assigned_to);
		$this->view->verifiedBy = $accountsTable->find($bug->verified_by);
		$productsTable = Doctrine_Core::getTable("Products");
		$this->view->products = $bug->Products;
	}
}
class SearchController extends Zend_Controller_Action {
	public function bugsAction() {
		$q = Doctrine_Query::create() ->from("Bugs b") ->join("b.Products p") ->where("b.status = ?", $_GET["status"]) ->andWhere("MATCH(b.summary, b.description) AGAINST (?)", $_GET["search"]);
		$this->view->searchResults = $q->fetchArray();
	}
}

• 测试模型：由于将模型类等同于活动记录类，你无法将数据访问与模型行为分开测试。要测试这些模型，你就必须连上真实的数据库执行查询。很多人使用数据库固定工具。数据库固定工具将数据载入到测试数据库中，来确保每个测试使用的是同样的标准数据。这样复杂的步骤使得测试模型的过程变得缓慢且容易出错，就和请求真实数据库进行测试一样麻烦。
• 测试视图：测试视图包括将视图呈现成HTML内容并解析其结果，来验证由模型提供的动态HTML条目确实出现在了输出中。即使你所使用的框架简化了测试脚本中的判定过程，框架还是要执行复杂且耗时的代码来呈现及解析HTML中指定的条目。
• 测试控制器：你将发现测试控制器也变得很复杂，因为模型就是导致同样的代码在多个控制器中重复出现的数据访问对象，所有的代码都需要测试。

• “我要怎么传递一个自定义的SQL查询给模型？”这个问题表示了你正在使用一个数据库访问类做为模型类。你不应该将SQL查询语句传递给模型对象——模型类应该囊括了所有它需要的查询。
• “我应该复制复杂的模型查询到我所有的控制器内，还是在一个抽象控制器内实现这些代码？”这两种方案都无法给你带来简单性或者稳定性。你应该将复杂的查询代码写在模型类里面，作为模型类的接口暴露出来。这样，就遵循了“不要重复自己（DRY5）”的原则，并且模型使用起来更简单。

  5 DRY出现在The Pragmatic Programmer[HT00]，由Andy Hunt和Dave Thomas所著。

• “我不得不写更多的数据库固定工具来对模型进行单元测试。”如果你正在使用数据库固定工具，就是说正在测试数据库访问而不是业务逻辑。你应该将对模型的单元测试和数据库分离开。

Magic-Beans/soln/domainmodel.php
<?php
class BugReport {
	protected $bugsTable;
	protected $accountsTable;
	protected $productsTable;
	public function __construct() {
		$this->bugsTable = Doctrine_Core::getTable("Bugs");
		$this->accountsTable = Doctrine_Core::getTable("Accounts");
		$this->productsTable = Doctrine_Core::getTable("Products");
	}
	public function create($summary, $description, $reportedBy) {
		$bug = new Bugs();
		$bug->summary = $summary     $bug->description = $description     $bug->status = "NEW";
		$bug->reported_by = $reportedBy;
		$bug->save();
	}
	public function assignUser($bugId, $assignedTo) {
		$bug = $bugsTable->find($bugId);
		$bug->assigned_to = $assignedTo"];
                $bug->save();
        }
        public function get($bugId) {
                return $bugsTable->find($bugId);
        }
        public function search($status, $searchString) {
                $q = Doctrine_Query::create() ->from("Bugs b") ->join("b.Products p") ->where("b.status = ?", $status) ->andWhere("MATCH(b.summary, b.description) AGAINST (?)", $searchString]);
                return $q->fetchArray();
        }
}
class AdminController extends Zend_Controller_Action {
	public function assignAction() {
		$this->bugReport->assignUser(       $this->_getParam("bug"),       $this->_getParam("user"));
	}
}
class BugController extends Zend_Controller_Action {
	public function enterAction() {
		$auth = Zend_Auth::getInstance();
		if ($auth && $auth->hasIdentity()) {
			$identity = $auth->getIdentity();
		}
		$this->bugReport->create(       $this->_getParam("summary"),       $this->_getParam("description"),       $identity);
	}
	public function displayAction() {
		$this->view->bug = $this->bugReport->get(       $this->_getParam("bug"));
	}
}
class SearchController extends Zend_Controller_Action {
	public function bugsAction() {
		$this->view->searchResults = $this->bugReport->search(       $this->_getParam("status", "OPEN"),       $this->_getParam("search"));
	}
}

• 类交互图（图25-3）变得更加简单且易读了，象征着各个类之间的解耦。
• 通过解耦模型接口和底层的数据库结构，我们减少且简化了控制器的代码。
• 模型类创建对象和一个或者多个表进行交互，控制器不需要知道哪张表被引用了。
• 模型类封装、隐藏了数据库查询，控制器只关心用户的输入，然后通过调用模型的API来执行更高层次的任务。
• 某些情况下，一个查询太复杂而无法简单地使用一个DAO，编写自定义的SQL就变得很必要。SQL安全地包含在模型类里时，直白地使用它看上去不那么可怕。

将模型和表解耦。