MVC...如何以及为什么，还有哪些其他好的选择（PHP）？

发布于 2024-08-07 05:05:35 字数 996 浏览 5 评论 0原文

我见过的关于 MVC 应该是什么以及如何使用的所有示例都使用类作为模型、类作为控制器、HTML 模板作为视图。所有这些都包含一个 index.php 脚本和 url 中运行整个站点的不同请求。

所以它们都是这样的......

MODEL
class User{
    function getUser($userID){
      $sql = mysql_query('SELECT name......');
      // more code.....
      return $array
    }
}

VIEW
<h2><?php echo $user['name']; ?></h2>

CONTROLLER
class Controller{
    $userModel = new User;
    $userInfo = $userModel->getUser($id);

    $template = new Template('usertemplate.tpl');
    $template->setVariables($userInfo);
    $template->display();
}

我理解为什么模型是由简单地获取和保存数据的类组成的（尽管我假设类并不总是必需的并且可以使用函数）。我明白为什么模板主要由 HTML 组成。但我不明白为什么控制器是一个类。我假设控制器是一个程序脚本（例如 userprofile.php，它从模型获取用户数据并将其发送到模板进行显示）。

另外，我想知道为什么我读过的每个教程都涉及 mod 重写，并使用带有 URL 中的请求（如“index.php?user=1”或 index.php?news=3）的单个页面来运行整个地点。拥有像 user_profile.php?id=1 或 news.php?id=3 这样的单独页面有什么问题...

有人可以帮我提供一个快速的“教程”和一路上的解释吗？例如...如何使用 MVC 实现注册表单，什么会去哪里以及为什么？谢谢

你。还有哪些其他类型的设计模式

原文

All the examples I've seen of what and how MVC SHOULD be have used classes as the models, classes as the controller, and HTML templates as the view. And all of them consisted of one index.php script and different requests in the url to run the entire site.

So they've all been something like...

MODEL
class User{
    function getUser($userID){
      $sql = mysql_query('SELECT name......');
      // more code.....
      return $array
    }
}

VIEW
<h2><?php echo $user['name']; ?></h2>

CONTROLLER
class Controller{
    $userModel = new User;
    $userInfo = $userModel->getUser($id);

    $template = new Template('usertemplate.tpl');
    $template->setVariables($userInfo);
    $template->display();
}

I understand why the model is made of classes that simply get and save data (even though I assume classes arent always necessary and functions could be used). I understand why the template consists of mainly HTML. But I dont understand why the controller is a class. I would assume the controller to be a procedural script (like userprofile.php which gets the users data from the model and sends it to the template for displaying).

Also, I was wondering why every tutorial I've read dealt with mod rewriting, and using a single page with requests in the url like "index.php?user=1", or index.php?news=3 to run the entire site. Whats wrong with having separate pages like user_profile.php?id=1, or news.php?id=3...

Can somebody please help me with a quick "tutorial" and an explanation along the way. Like...how would a registration form be implemented using MVC, what would go where and why? thankyou

PS. what other kind of design patterns are there

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

奢欲 2024-08-14 05:05:35

PHP 版本的 MVC 中控制器的一大“胜利”是，您无需为应用程序响应的每个 URL 提供单独的 PHP 页面。

当您为每个 URL 创建一个新的单页面时，您希望您的开发人员（或您自己）引入所需的库并以相同的方式初始化模板/布局引擎。即使您是一名单独的开发人员，打破“标准”做事方式的诱惑通常也会变得太强烈，这意味着每个 URL/PHP 页面最终都会成为自己的迷你应用程序而不是每个 URL/PHP 页面都属于同一应用程序。当你有多个开发人员时，这种情况肯定会发生。

最终结果是页面和组件彼此不能很好地配合并且难以调试（所有内容都挂在全局名称空间中），从而为必须处理该项目的用户和开发人员提供不一致的体验。

MVC 框架还可以更轻松地为您的站点提供友好的 URL。路由系统中通常发生的事情已经足够多了，您不需要求助于大量的查询字符串变量。对于 SEO 和精明的用户来说，可读的 URL 是一个优点。

最后，尽管这对大多数商店来说都是天上掉馅饼，但当您拥有控制器时，控制器上的方法就可以轻松进行单元测试。虽然您可以从技术上将测试工具包装在非 MVC 站点上，但这始终是一件令人头疼的事情，而且永远不会像您希望的那样工作。

回复收藏 0 原文

妄司 2024-08-14 05:05:35

使用带有请求的单个页面
类似“index.php?user=1”的 url，或者
index.php?news=3 运行整个
地点。分开有什么不好
像 user_profile.php?id=1 这样的页面，或者
news.php?id=3...

使用单个入口点使一些事情变得更容易，我想：

不必在 user_profile.php 和 news.php 中复制代码的任何部分
如果您想设置任何类型，则过滤器（例如用于安全性的 PHPIDS 或 ACL），您只需修改一个文件，并且它是针对整个应用程序完成的。

PS。还有什么其他类型的设计模式
有吗

设计模式有很多？您可以在维基百科上的设计模式（计算机科学）文章中找到列表，例如 - 包含每个页面的链接，以了解更多详细信息。

回复收藏 0 原文

久隐师 2024-08-14 05:05:35

为每个操作使用单独的脚本并没有什么问题，事实上，您可以通过这种方式创建 MVC 架构，而无需使用控制器类。我目前正在开发一个支持这两种风格的 MVC 框架。

重要的是要保持不同关注点的分离。数据库逻辑位于模型中，布局逻辑位于模板中，而其他所有内容都位于控制器中。

因此，对于一个非常简单的示例，您可以使用包含以下代码的脚本“register.php”，

$signup_options = SignupOptions::getSignupOptions(); // Load some data      
require("register_form.php");  // Pass it to the view

并且此帖子到 register_process.php

$username = $_REQUEST['username'];
$password = $_REQUEST['password'];
$email    = $_REQUEST['email'];
Users::Register( $username, $password, $email );
header( 'location: register_success.php' );

MVC 并不适合所有应用程序，因此您应该根据每个项目考虑您的架构。对于许多网站来说，只要有一堆独立的脚本就可以了。然而，对于更大、更复杂的应用程序，MVC 已证明自己是一种可靠且可扩展的 Web 应用程序开发方式。

另一种常见的设计模式是“View-Helper”，即直接调用模板，模板调用“Helper”对象，该对象在模板和模型之间执行业务逻辑。概念上类似，但您可以跳过不需要的模板的任何额外代码，同时仍然保持像 MVC 这样的关注点分离。（本质上的区别在于您直接调用模板，而不是调用控制器）。

There's nothing wrong with having separate scripts for each action, and in fact you CAN create a MVC architecture this way, without using a class for the controller. I'm working on an MVC framework at the moment that supports both styles.

The important thing is really to keep separation of different concerns. Database logic goes in your models, Layout logic goes in templates, and everything else in the controller.

So for a really simple example you could have a script "register.php" with the following code

$signup_options = SignupOptions::getSignupOptions(); // Load some data      
require("register_form.php");  // Pass it to the view

And this posts to register_process.php

$username = $_REQUEST['username'];
$password = $_REQUEST['password'];
$email    = $_REQUEST['email'];
Users::Register( $username, $password, $email );
header( 'location: register_success.php' );

MVC is not suitable for all applications, so you should consider your architecture on a per project basis. For many sites, just having a bunch of independent scripts works fine. For larger more complex applications however, MVC has proven itself to be a reliable and scalable way of developing web applications.

Another common design pattern is "View-Helper", which is where you call a template directly, and the template calls a "Helper" object that performs business logic between the template and the models. Similar in concept, but you can skip having any extra code for templates that don't need it, while still maintaining separation of concerns like MVC. (The difference is essentially that you call the template directly, rather than calling a controller).

回复收藏 0 原文