MVC 作为专业级编程的最佳实践？答案

【问题标题】：MVC as best practice for professional level programming?MVC 作为专业级编程的最佳实践？
【发布时间】：2011-01-01 21:35:18
【问题描述】：

潜伏已久，第一次发帖……

我现在几乎可以称自己为专业级的 PHP 程序员，并且有很多代码可以在各种项目中重复使用。此外，我使用过的许多开源包都使用 MVC 模型，因此我最近对它的工作原理进行了大量研究，以便我可以根据需要更好地编辑它们。

此时，我正在考虑采用一个简单的 MVC 框架（来自教程）并根据我即将进行的编程工作的需要对其进行扩展。

我的问题是，几乎所有应用程序逻辑都与表示层分离的 MVC 模型是否被认为是结构良好的 OOP 网站上的最佳实践，必要时在页面上进行编码，例如设置函数变量。

或者当我想要编码灵活性时会遇到问题，例如

使用 PHPthumb 之类的东西作为我想要不同输出的画廊不同页面的大小和当前在头部设置的参数页面的
带有 x 字段的联系表单和带有 y 字段的反馈表单 - 这将需要 2 个不同的模型，而不是在页面头部设置一些参数的通用表单类
某些页面需要 ob_start() 和 ob_flush() 而其他页面不需要？

请不要告诉我不要构建自己的框架 - 我宁愿知道每一点的工作原理，也不愿使用我一无所知的代码 - 我真的很感兴趣那些已经离开的人的意见这条路线每天都在建站点。与 1 个 index.php 页面和单独的文件相比，这种简单（但结构良好）的 OOP 和网站上的一堆页面的真正优点和缺点是什么。

干杯，小鬼

【问题讨论】：

I'd rather know how each little bit works than use a slab of code I know nothing about -- 当然，你对代码一无所知一开始 但是由于 php 代码是可读的，如果你不想要，那是你的错研究代码。
如果你真的对“走这条路的人”所说的话感兴趣，你不应该以“请不要告诉我构建我自己的框架”开头。因为那是最好的答案。
此外，使用受人尊敬的框架是加深您对实现 MVC 模式的理解的好方法，如果您仍然发现缺少可用的解决方案，这将有助于您构建自己的框架。
我绝对属于“学习一个（或几个）但也要建立自己的”阵营。在您尝试制作八角形之前，没有合理的方法可以理解为什么轮子是圆形的。也就是说，根据需要构建它。不要花时间设计没有任何适用性并最终被浪费的功能。
我写了一篇关于在 PHP 中从头开始创建自己的 MVC 的博文 - chaitya62.github.io/2018/04/29/…希望这会有所帮助

标签： php model-view-controller

【解决方案1】：

我知道你说你不想要这个建议，但不要自己写。在我从事过的每一项工作中，我做的第一件事就是挑选一些现有的代码或框架，通常是商业的，但经过高度修改，然后开始维护它。你很少能选择自己写，这样做是个坏主意。这很难，也很昂贵，而且其他人已经编写了比您可能编写的更好的 MVC PHP 框架。

实际上有几十个mature PHP frameworks，其中大部分已经存在了十多年。选择其中之一。哪个无关紧要 - 它们都由十几个人维护，至少和你一样聪明，他们编写 MVC 框架的时间要长得多，并且花了几个月或几年的时间来完善他们的框架并听取用户输入。

话虽如此，如果你想在自己的时间写自己的东西，作为一种爱好，这样你就不会浪费你老板的钱，那么无论如何。 MVC 有各种各样的解释。一些框架将视图视为基本模板。我个人认为您可以在其中投入尽可能多的原始 PHP，只要它的目的是显示，并且您可以执行通常的智能操作，例如将共享代码提取为函数。一些框架在模型中几乎没有业务逻辑（它属于 IMO），但有非常重的控制器。你能做的最好的事情是尝试其他框架，看看它们是如何工作的，你最喜欢哪个，然后决定你希望看到什么改变。然后，着手进行自己的更改。

您说您几乎准备好将自己视为专业人士了？我必须学习的最难的一课是专业人员不会编写自己的低级库。他们不会重新发明公司降压的轮子。他们使用现成的组件并在今天完成工作，而不是从现在开始一个月。您不想使用一堆不熟悉的代码吗？这是你作为程序员人生中最重要的部分——习惯它。

【讨论】：

“我知道你说你不想要这个建议，但不要自己写。”你所说的一切都是公平的——但我想我的计划不是去建造一些需要 12 个月才能完成的巨型野兽。目前我正在做很多类似的工作——定制 CMS 系统、带有多个画廊和表格的迷你网站，下个月我有一个带有时间管理设施的 CRM。我想开始将我的作品整合成可重复使用的东西，即使它是一块一块的。 “专业人士不会编写自己的低级库。”同意 - 如果存在，我会使用几个 3rd 方类并完成工作:-)
@meagar：关于你的最后一段，如果每个人都和你一样，就不会有任何专业的 PHP 框架，而且有很多！我并不是说他应该在公司上班时间自己动手，但我认为完全不建议这样做。
@AlixAxel 我知道这已经快五年了，但无论如何我都会跟进。重要的是，几乎没有一个现有的“专业” PHP 框架是仅仅为了编写一个专业的 PHP 框架而编写的。这是产生一个没人愿意使用的丑陋框架的好方法。好的框架是从现实世界应用程序中提炼出来的，在这些应用程序中，有人看到了一个真正的问题并想出了一个解决方案。然后他们看到了可重用的部分，或者他们认为他们有一个特别优雅的架构，这构成了他们框架的基础。
这也许是我试图解释为什么您不应该构建自己的框架的真正原因。是的，它们也是一个很好的学习，但是很好现有框架已经证明自己能够在许多规模上托管多种类型的应用程序；它们经过实战考验和强化，坏错误已为您解决。当然，每个人都应该随意尝试自己对框架的想法，但这个问题的主旨正在成为专业人士，而专业人士不解决已经通过编写框架解决了问题。

【解决方案2】：

编写自己的框架对于您自己的启迪和真正理解语言非常有用。

我个人觉得使用第三方框架和编写自己的框架一样耗时。然而，我可以完全控制自己的代码，而不是任何第三方框架都可以声称的。

我还认为许多 MVC 框架非常耗费资源。对于大容量站点，您需要准备好向它们扔硬件以使它们运行良好。对于低容量站点（大多数），第三方 MVC 框架的快速开发是一个巨大的好处。

所以在我看来，如果您有时间，请自己动手并为此感到自豪。只需确保向他人学习，尤其是在安全方面。

【讨论】：

【解决方案3】：

这完全取决于您的项目要求是什么以及您如何设计应用程序对象。 MVC 不会强迫您使用特定的类或视图设计，它只会为您提供一种架构，帮助您将业务逻辑与表示和数据层隔离开来，使您的应用程序更具可扩展性和易于测试。

在 MVC 中，您不必为每个控制器绑定一个视图，您可以为每个控制器使用任意数量的视图，因为每个公开的方法都可以调用视图本身并根据您定义的业务逻辑控制视图的外观和行为。也就是说，您可以有两种方法来返回全尺寸图像和缩略图，而无需创建两个页面。您可以从控制器、标题元数据、脚本、链接、主题、内容等设置视图上的所有内容...

关于模型，这又取决于您的项目要求，但无论如何，如果您有多个具有不同目的的页面并且它们需要修改不同的数据源，那么每个页面都应该有一个模型，并且之后您可以做的是创建一个封装表单功能的类，方法是调用获取字段的模型来创建表单、获取和保存数据。这只是一个想法，您可以通过多种不同的方式来实现它，这就是 OOP 的美妙之处。

归根结底，这不是将结构良好的 OOP 站点与 OOP MVC 站点进行比较的问题，而是对您花费在构建站点架构上的时间和精力的分析，该架构可以成功地隔离关注点同时它仍然具有可读性和可扩展性，同时满足您的项目要求。

如果您想获得有关设计模式的更多想法，可以使用 google MVP 设计模式和/或 MVVM 设计模式。

【讨论】：

【解决方案4】：

我已经编写了自己的框架。创建架构和原始代码不需要时间。如果有人在那里编写自己的框架，那就太好了。但是，如果文档不正确，那么肯定会很痛苦。完全取决于你自己。我也写过我的。准备好框架 QA 花了将近 7 天的时间:)。但主要问题是让您在框架中编写的代码感到满意。你总是想即兴发挥你的框架，并希望它是最好的。废话！废话！如果你想写你自己的，你有足够的信心寄托。去吧。

【讨论】：

【解决方案5】：

任何 MVC（无论是否自行开发）都可以为您提供灵活性和可重复使用的代码。

ob_start() / ob_* 调用没问题，它们进入您的模型并从您的模板中调用，例如：

Hello <?php echo $this->getFormattedName(); ?>

你的模型在哪里

function getFormattedName() {
    ob_start();
    echo '<a href="/profile/' . $this->getName() . '">' . $this->getName() . '</a>';
    $return = ob_end_clean();
    return $return;
}

对于您的表单场景，您可能需要一个抽象表单类来定义字段的生成方式及其验证，然后每个特定表单都将扩展您的抽象。

您可能需要考虑使用 Zend Framework 之类的东西——虽然它本身就是一个 MVC 库，但您可以非常轻松地引入单个组件（例如，您可以为联系和反馈表单引入 Zend_Form 和 Zend_Mail和验证并使用您自己的模型进行其他所有操作）。当您的自制 MVC 框架开始超出其原始设计时，这也将为您提供备用的额外好处。或者，至少，加快你的开发时间，这样你就不会因为突然意识到你需要一个电子邮件模型而耽误了几天。

【讨论】：

这种输出缓冲的使用似乎......过度了。字符串连接有什么问题？
连接没有问题。只是一个例子，因为OP专门询问使用ob_start()等:)
这是完全错误的。你的模型不应该输出 HTML，这就是视图的用途。 MVC 的整点是将您的业务对象与您的显示代码解耦。这也正是 not 使用输出缓冲的方式。因为它在问题中被引用而将其插入鞋内并不会使其更有效。
触摸。从技术上讲，您比我更正确。我认为我的回答与其说是错误的不如说是不正确的；我认为它确实有效地回答了这个问题。我不是要教 OP 如何编码。有时这条线会变得模糊，例如在 Zend_Form 中，Zend_Form_Element 类构建了表单的结构。虽然它不会直接回显 HTML，但它非常接近。