企业架构之页面控制器

在前端控制器博客中说到前端控制器比较复杂，不适用于相对的小项目，那如何以最佳方式为适度复杂的WEB应用程序构建控制器，从而既能避免代码重复，又能实现重用性和灵活性？

一、概念

Page Controller很简单，就是接受来自页面请求的输入，调用请求对模型执行操作以及确定应用于结果页面的正确视图。分隔高度逻辑和所有视图相关代码。

二、为什么要用页面控制器?

其实这个问题已经说了，就是开头说的，为了简单快速地构建控制器。控制逻辑与一个或多个视图相关联。

三、实现页面控制器

页面控制器最简单实现就是将控制逻辑放在视图中。

假设现在有个friendList的请求，其具体代码实现如下：

<?php
//加载friend模型
require_one("friend.php");
try{
    //获取friendList
    $friendList = friend::findAll();
}catch{Exception $e}{
    include('error.php');
    exit(0);
}

<html>
<head>
<title>friendList</title>
</head>
<body>
<h1>friendList</h1>
<?php foreach($friendList as $friend):?>
<?=$friend->getName();?><br/>
<?php endforeach;?>
</body>
</html>
?>

这种简单的写法没有将控制器与视图分离，这样会大量的代码重复，在实际开发中，还是强烈建议将它们分离的。如果我们将上面的控制器代码独自写到另一个文件中，这样相当于每个网页或操作创建独立控制器，也可能导致大量代码重复。因此可以创建一个abstract PageController类以合并验证参数等公用函数，每个独立页面控制器都可以继承此公用功能。还可以定义一组帮助器类，控制器也可以调用这些类来执行公用功能。

四、比较

页面控制器相比前端控制器最大的优点就是简单，极易理解，只要有一点WEB开发经验就会使用。当然缺点也很明显，页面控制器要为每个网页（或操作）创建独立控制器，特别是当同一个视图被多次并以不同方式使用时，例如有时我们的添加和编辑是使用同一个视图，这时就会被条件判断语句和状态检查语句弄糊涂，倒置代码的可读性大大降低。

值得注意的是，一个项目早期使用页面控制器，将来转而使用前端控制器也是可以的，特别在使用PageController是类的时候更是如此。

五、小结

不同的项目应该根据实际项目的大小，复杂度来决定使用哪种架构，当然也要为项目的未来考虑，不写“一次性”代码。小型快速开发的项目推荐使用页面控制器，大型复杂的项目比较适合前端控制器。

企业架构之页面控制器

相关推荐