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

Question

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

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

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

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

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

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

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

编辑：

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

Answer 1

代码之间总是存在折衷，因为它是高度解构主义者，代码令人困惑，因为完全需要做X的所有内容都是随机分散在一个文件中。

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

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

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

答案 1 :(得分：3)

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

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

Controller承诺向View提供某些数据，并依赖该模型来履行其承诺。该视图不关心控制器如何 。

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框架，您可以只将视图交给他们，并说“在这部分工作。”

答案 2 :(得分：1)

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

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

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

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

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

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

答案 3 :(得分：0)

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

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

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

答案 4 :(得分：0)

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

http://framework.zend.com

这篇文章也许有用：

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

答案 5 :(得分：0)

您可以尝试使用代码Igniter。它非常容易学习，并且不会严格采用MVC，同时为您的代码提供良好的结构。

答案 6 :(得分：0)

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

答案 7 :(得分：0)

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

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

主要问题不在于框架代码存在多样性，而是编码员显然不了解如何抽象API。 IMO，这是MVC框架的最大问题。我必须使用的几乎所有代码都使用“模型”作为放置函数的地方。这是一个梦魇来维护。

为了使这个可维护，IME你需要做一些事情：

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

  我不喜欢使用术语“模型”，因为这是有争议的。无论调用该层不应该关心数据的存储方式，都不应该担心像数据库处理这样的事情：那就是所有数据访问层的工作。

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

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

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

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

Answer 2

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

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

Controller承诺向View提供某些数据，并依赖该模型来履行其承诺。该视图不关心控制器如何 。

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

您可以尝试使用代码Igniter。它非常容易学习，并且不会严格采用MVC，同时为您的代码提供良好的结构。

Answer 7

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

Answer 8

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

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

主要问题不在于框架代码存在多样性，而是编码员显然不了解如何抽象API。 IMO，这是MVC框架的最大问题。我必须使用的几乎所有代码都使用“模型”作为放置函数的地方。这是一个梦魇来维护。

为了使这个可维护，IME你需要做一些事情：

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

  我不喜欢使用术语“模型”，因为这是有争议的。无论调用该层不应该关心数据的存储方式，都不应该担心像数据库处理这样的事情：那就是所有数据访问层的工作。

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

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

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

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