松散耦合的MVC的替代方案？

Question

我作为PHP程序员在网上商店工作。 大多数情况下，我们使用良好的编码实践，但整个网站的结构不多。

我现在已经进入了对我们的一些实践感到厌倦的阶段，并希望以一种有用的方式扩展和简化并生成一些东西，不仅对我而言，还有办公室中的混合程序员Web开发人员。

一位员工给我们留下了一个用PHP编写的MVC网站，我不得不维护它，我得到了它的工作方式，但有我的抱怨，我的主要抱怨是它与每件依赖于另一件的紧密耦合。 我看到了分离问题的优势，但除了我看代码之外，这对任何人来说都会让人感到困惑。

因此，例如，如果我需要向网站添加新页面，我必须添加视图，然后添加模型，然后更新控制器。 制作新页面的特殊方法比这简单，并且不需要程序员。

我的判断是，这是一个更好的方法来构建，而不是维护一个网站。

不过，如果我有一些设计模式，我可以有效地重用代码，而不依赖于网站中的多个位置，那将是很好的。

所以我的问题是，是否有一种用于构建和维护更松散耦合的网站的设计模式？ 我不是在寻找MVC上的细微变化，我需要看一些不同的东西，也许某种类型的插件方法。

编辑：

谢谢你到目前为止的答案！ 一种不同的方式是我希望代码在我的办公室里做得更好。 做IA）推动MVC或B）找到/构建一个替代方案，而不是让半程序员感到困惑。 我们已经使用类来连接数据库连接和表单帮助。 这个问题的关键是探索B.

Answer 1

在代码混乱之间总是存在折衷，因为它是高度解构主义者，并且代码令人困惑，因为完全需要做X的一切都是随机分散在一个文件周围。

后者的问题在于，究竟什么是将事物分解成单片模块的“直观”方式因人而异。 高度分解和分解代码几乎总是更难以解决，但一旦你这样做，维护变得容易做。 我不同意除了作者看到它之外，其他任何人都会感到困惑。 使用像MVC这样的大范围模式，因为随着时间的推移，更容易发现它们并处理围绕它们构建的项目。

使用MVC的另一个好处是，如果您不坚持使用分层，通常不会使应用程序更难以维护。 这是因为现在您有一个预定的位置可以放置实现新功能的任何方面。

就考虑紧耦合而言，如果层之间没有某种连接，则无法实现功能。 松散耦合并不意味着层完全相互无知 - 这意味着层应该不知道其他层是如何实现的。 例如：控制器层不关心您是使用SQL数据库还是只编写二进制文件来在数据访问层保留数据，只是有一个数据访问层可以为它获取和存储模型对象。 它也不关心你是否在视图层使用原始PHP或Smarty，只是它应该为某些预定的名称提供一些对象。 视图层甚至不需要知道有一个控制器层 - 只有它被调用，数据才能在/ something /提供的上述名称下显示。

Answer 2

随着框架模板的发展，我发现MVC模式是构建应用程序最“松散耦合”的方式之一。

想想接口之类的关系，或者应用程序各部分之间的契约。 模型承诺将此数据提供给View和Controller。 没有人关心模型如何做到这一点。 它可以从典型的DBMS（如MySQL），平面文件，外部数据源（如ActiveResource）读取和写入，只要它完成交易的结束即可。

Controller承诺向View提供某些数据，并依赖Model来履行其承诺。 视图不关心Controller是如何做到的。

View假设模型和控制器将遵守其承诺，然后可以在真空中开发。 模型和控制器不关心视图是否生成XML，XHTML，JSON，YAML，明文等。它们正在阻止它们的合同结束。

当然，视图和控制器需要同意存在某些事物。 没有相应的Controller活动的视图可能正常工作，但永远不能使用。 即使Controller没有做任何事情，静态页面中也可能如此：

<?php
class StaticController extends ApplicationController
{

    /**
     * Displays our "about" page.
     */
    public function about ()
    {
        $this->title = 'About Our Organization';
    }
}

然后关联的View可以只包含静态文本。 （是的，我之前已经实现了这样的事情。将静态视图传递给其他人并说“只需写上这个。”）很高兴。）

如果你看看M，V和C之间的关系作为契约或接口，MVC突然看起来非常“松散耦合”。 警惕独立PHP文件的诱惑。 一旦你开始包含并需要六个.inc文件，或者将你的应用程序逻辑与你的显示器（通常是HTML）混合，你可能会更松散地耦合各个页面，但是在这个过程中弄得一团糟的重要方面。

<?php
/**
 * Display a user's profile
 */
require_once 'db.php';

$id = $db->real_escape_string($_GET['id']);
$user_res = $db->query("SELECT name,age FROM users WHERE id = $id;");
$user = $user_res->fetch_assoc();

include 'header.php';
?>
<h1><?php echo $user['name']; ?>'s Profile</h1>

<p><?php echo $user['name']; ?> is <?php echo $user['age']; ?> years old!</p>
<?php
include 'footer.php';
?>

是的，“profile.php”和“index.php”完全不相关，但代价是什么？

编辑：响应您的编辑：推送MVC。 你说你有“半程序员”，而且我不确定哪一半（你是否有前端人员擅长HTML和CSS而不是服务器端？具有一定编程经验的作家？）但是MVC框架，你可以只将视图交给他们，并说“在这部分工作”。

Answer 3

我不得不说我真的没有看到你的MVC问题，因为你已经在使用模板了。 我将其视为当您尝试将结构添加到应用程序时自然演变的模式。

当人们第一次开始开发PHP应用程序时，代码通常是一个大混乱。 表示逻辑与业务逻辑混合，业务逻辑与数据库逻辑混合在一起。 人们通常采取的下一步是开始使用某种模板方法。 这是否涉及专门的模板语言，如smarty，或者只是将表示标记分离到单独的文件中并不重要。

在此之后，我们大多数人发现为数据库访问逻辑使用专用函数或类是个好主意。 这实际上不必比为每个常用查询创建专用函数以及将所有这些函数放在公共包含文件中更先进。

这一切对我来说都很自然，我不相信这是非常有争议的。 但是，在这一点上，你基本上已经在使用MVC方法了。 除此之外的所有东西或多或少是复杂的尝试，以消除重写常用代码的需要。

我知道这可能不是你想听到的，但我认为你应该重新评估MVC。 有无数的实现，如果确实没有这些实现适合您的需求，那么您总是可以编写自己的更基本的实现。

这样看：由于你已经在使用模板语言，你通常需要首先创建一个普通的PHP文件，然后每次创建一个新页面时创建一个模板文件。 MVC不必比这更先进，并且在许多情况下它不是。 甚至可能你真正需要做的就是研究更复杂的方法来处理数据访问并将其添加到当前系统中。

Answer 4

当您需要新页面时，您必须创建新的模型和控制器操作这一事实我不认为意味着您的M，V和C层紧密耦合。 这只是关注点的分离，有助于解耦系统。

也就是说，很有可能搞砸MVC的意图（我已经在这样的应用程序上工作）并使它使组件紧密耦合。 例如，站点可能会将“渲染引擎”直接放在Controller层中。 这显然会增加更多耦合。 相反，将设计一个好的MVC，以便控制器只知道要使用的视图的名称，然后将该名称传递给单独的渲染引擎。

MVC中糟糕设计的另一个例子是视图具有硬编码到其中的URL。 这是路由引擎的工作。 视图应该只知道需要调用的操作以及操作所需的参数。 然后，路由引擎将提供正确的URL。

Answer 5

Zend框架非常松散耦合，非常好。 看看这个：

http://framework.zend.com

这篇文章也许有用：

http://blog.fedecarg.com/2009/02/22/zend-framework-the-cost-of-flexibility-is-complexity/

Answer 6

你可以试试代码点火器。 它非常容易学习，并没有严格采用MVC，同时为您的代码提供了良好的结构。

Answer 7

代码点火器和Kohana（CI后代）都可以，但也松散的MVC。 我喜欢简单的PHP框架 。 它不会妨碍你，它提供了重要的东西，而不强迫你的结构或复杂的约定。

Answer 8

啊......好的老MVC论点。

我必须维护一个多方面的PHP应用程序，其中的一些部分是“MVC”风格，但不是全部。 更糟糕的是，不同的部分有不同的做MVC的方式，所有这些都是本土的。 有些页面只是自己完成。

主要的问题是不存在的框架代码中的多样性，但该编码器显然不知道如何抽象的API。 IMO，这是MVC框架的最大问题。 我必须使用的几乎所有代码都使用“模型”作为放置函数的位置。 维持这是一场噩梦 。

为了使这个可维护，IME你需要一些东西：

• 一个独特且定义明确的数据访问层，其API边界用于检索和存储持久存储，而其他很少。

  我不喜欢使用术语“模型”，因为这是有争议的。 无论调用该层不应该关心数据的存储方式，都不应该担心数据库句柄之类的问题：这是数据访问层的全部工作。

• 一个非常轻的调度员，除了调度之外没有任何魔法。

现在，您可以将其他所有内容放在一个接受请求和参数的地方，可能是从调度程序进行规范化和错误检查，获取所需的数据（通常作为对象），进行需要进行的更改，保存所需的数据，手需要将数据显示到视图中。 代码通过任务单调乏味两百线适用于这一步骤。 您不需要将位分配到另一个从其他地方调用的文件中的函数。 您甚至可以将视图放在此文件的末尾！ 理想主义很乐观，但实用主义需要一种观察，因为这是可维护的 。

（好吧，咆哮......）

PHP缺乏强制执行框架意味着最好的框架可以完成PHP的工作：它们不会受到影响。 我工作过的一些最易维护的代码在顶部有一个require()语句，用数据对象进行所有数据操作（看不到SQL），然后输出由模板函数包围的HTML，表单控件为由一致的函数API完成。