php中的mvc模型应该只是一个PDO包装器吗？

我一直在努力学习MVC模式（没有框架），但是无论我在互联网上读到什么材料，它似乎总是自相矛盾

我的项目现在包含一个表单，可以提交该表单以便向数据库添加元素。另一个页面只列出数据库中的所有元素

因此，据我所知，我的模型应该连接到数据库（或者只是将连接作为一个参数，其他一些我不太清楚的东西），并具有类似“saveItem”（将$_POST变量作为输入并对其进行解析）和“listItems”（只将所有条目返回到页面）的函数

但是，控制器从何而来？现在我解析模型中的数据。但是，如果这应该在控制器中完成，那么模型实际上做了什么？我无意中看到了佩奇。在这里，模型只有“select”之类的方法，其输入只是一个sql查询。但这看起来本质上只是一个PDO包装器。（与页面中关于PDO已经是一种包装器的信息相矛盾，实际上没有必要这么做。）

我想这是有道理的，如果模型只是作为包装器编写的，它实际上与我的网站的细节没有任何关系。（我现在的理解是，mvc的每个部分对于每个项目都非常具体。）

但是，无论是模型还是控制器似乎都是不必要的。任何一个模型都会解析数据，不让控制器做任何事情，反之亦然

---

如果有任何澄清，我将不胜感激。

我将把这个问题看作是一个真正的询问，而不是一个审查互联网上一些SEO垃圾邮件文章的请求。事情是这样的：

您首先需要了解的是，“模型”一词是不明确的。它可以表示整个应用程序的业务逻辑，也可以表示您的意思—与数据库交互的某段代码。为了避免这种模糊性，让我们继续使用前者。这将有助于你与管制员达成和解。然而，我们将“较小的模型”称为存储。实际与数据库交互的代码的覆盖术语

我有一本非常简明的书。这将有助于你从整体上了解MVC

现在更接近你的问题

在这两种意义上，数据库包装器都不能被视为模型。数据库包装器是存储类使用的服务。因此，应用程序中至少可以有3个层：

• 控制器。只是一个将HTTP客户机的请求传递给业务模型的接口
• 服务或助手。通常（或错误）写入控制器的代码。例如，如果您需要注册一个用户，那么在控制器中，您正在从用户服务调用一个方法，前提是数据来自客户端
• 存储类。与数据库交互的实际代码。例如，它可以是一个包含register等方法的用户类。此类将使用PDO（或更高级的包装器，或ORM实例）作为类变量

其中后两者实际上应该封装整个应用程序的业务逻辑

这里最棘手的部分是存储类的实例化。如果连接只能执行一次，那么应该有方法实例化UserStorage对象，为其提供数据库连接。这与依赖项注入容器解决的问题略有不同

用一段代码来说明上述内容

class UserController extends Controller
{
    public function create($request)
    {
        $userService = $this->serviceContainer->get('user_service');
        $userService->create(
            $request->email;
            $request->password;
        );
    }
}
class UserService
{
    public function create($username, $password)
    {
        // here, userStorage instance was already injected 
        // in the UserService in the controller by DI container
        $this->userStorage->create(
            $request->email;
            $request->password;
        );
    }
}
class UserStorage
{
    public function create($username, $password)
    {
        $sql = "INSERT INTO user VALUES (null, ?, ?)";
        // here, db instance was already injected 
        // in the UserStorage in the controller by DI container
        $this->db->prepare($sql)->execute([$username, $password]);
    }
}

这可能被认为是不必要的冗长，所有这些似乎都是重复的，但这是有原因的：

在实际代码中，每个阶段都有其他部分，例如，

• 控制器将验证提交的表单（如表单是否实际提交，密码是否相等等），并调用View来呈现表单
• UserService可以执行额外的验证，比如此类电子邮件是否已经存在

不同的呼叫点

• 可以从许多不同的地方调用UserService：从上面的控制器、命令行实用程序或REST控制器
• 用户存储可以从更多的地方调用。例如，有一个TaskService列出属于用户的任务，它自然会很好地利用UserStorage类。等等

因此，用这种方式分离层是非常有意义的

当然，这只是一个过于简单的草案模型，它没有实现通常在这里的ORM，以及其他许多东西。但是草图越简单，细节就越少，就越容易得到主要思想

我偶然看到这一页。在这里，模型只有“select”之类的方法，其输入只是一个sql查询。但这看起来本质上只是一个PDO包装器

你说得对。事实上，这个示例的结构非常糟糕，不符合MVC设计的任何合理概念。我建议你完全忽略它，找一个更好的例子

• 本例中的

  DB

  类（据称是一个“模型”）是一个数据库助手类。虽然这是一个有用的东西，但它在任何意义上都不是一个MVC模型，而且这个模型也不是特别好写

• Users

  类（据称是“控制器”）不是控制器。它实际上更类似于模型，因为它试图（笨拙地）将业务对象表示为类
  （顺便说一句，扩展数据库帮助器类是一种应该避免的设计“味道”——这意味着每个实例化的对象都将创建自己与数据库的独立连接。）

• list.php

  文件（据称是一个“视图”）也不是什么视图。虽然它提供了一些表示功能，但它也承担了操作员的控制器角色