优化PHP应用程序：为什么单独阅读和写入模型很重要

哈喽！今天心血来潮给大家带来了《优化PHP应用程序：为什么单独阅读和写入模型很重要》，想必大家应该对文章都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到，若是你正在学习文章，千万别错过这篇文章~希望能帮助到你！

模型是与数据存储交互的理想工具。它们定义数据的结构，确保与数据存储（通常是数据库）兼容。模型不仅验证输入数据，辅助数据写入，还能用于数据检索。然而，除了简单的CRUD应用之外，将同一个模型用于读写通常并非最佳实践。让我们深入探讨原因。

创建模型

让我们以一个简单的用户模型和存储库接口为例，这里无需详细说明其内部实现。假设我们有一些断言库来验证每个创建的模型的有效性。

class User
{
    public function __construct(
        public string $email,
        public string $name,
        public string $password,
    ) {
        Assert::email($email);
        Assert::notEmpty($name);
        Assert::password($password, strength: 3);
    }
}

interface UserRepository
{
    public function save(User $user): void;
}

典型用例：我们获取新用户的输入数据，验证姓名非空、邮箱有效、密码符合强度要求（级别3）。然后将数据保存到存储库。完成。

$user = new User(
    $request->get('email'),
    $request->get('name'),
    $request->get('password'),
);
$repository->save($user);

问题：模型属性不应用于读取 现在，假设我们要根据数据库中的邮箱读取用户信息，并将其以JSON格式返回给客户端，用于显示用户配置文件。如果我们向存储库添加读取方法，并重用相同的模型，会发生什么？

interface UserRepository
{
    public function save(User $user): void;
    public function get(string $email): User;
}

// 在某个控制器类中
return new Response(
    json_encode(
        $repository->get($request->get('email'))
    ),
);

结果可能如下：

{
  "email": "peter@dailybugle.com",
  "name": "peter parker",
  "password": "$2y$10$oeatphgkw0hqv4qnxtptqoe.bsqdnpwrb./vgqigjmehvir22jnfk"
}

首先，密码（即使是加密的）也不应通过服务器发送。这是一个严重的安全性问题。虽然这是使用写入模型作为读取模型导致的信息泄露最糟糕的情况，但并非唯一的情况。另一个常见问题是向客户端发送不相关的信息。例如，我们可能有一个 active 布尔值，用于启用或禁用用户，这对客户端来说毫无用处，因为如果用户不活跃，请求将返回 404。不相关的数据会导致额外的字节传输，影响性能。虽然单个影响可能很小，但累积起来会造成问题，而解决方法很简单。

解决方案？返回一个包含有限数据列表的响应。这可以解决这些问题。

class User
{
    // ...

    public function read(): array
    {
        return [
            'email' => $this->email,
            'name' => $this->name,
        ];
    }
}

但这只是冰山一角，还有更多问题需要解决。

问题：不必要的验证 谈到性能，我们在模型构造函数中进行了验证。但是，当我们从数据库中获取已存在的数据时，还需要这些验证吗？它们在保存时就应该有效，因此再次运行这些验证是浪费资源。但这不仅仅是浪费，它可能是一个严重的问题。验证规则可能会发生变化，如果我们使用相同的模型进行读写，这可能会影响检索数据的能力。假设一个验证用户邮箱格式的应用添加了一个新的规则，禁止某些域名。验证规则更新了，但现有用户无法更新，因为他们的邮箱仍然有效。

现在，假设我们收到一个包含100个用户的请求，其中一个用户的邮箱域名在黑名单中，会发生什么？整个请求将被视为错误。我们应该向用户返回什么？400 Bad Request 响应，就好像用户输入错误一样？这不是客户端的错，而是服务器的错。在这种情况下，应该返回某种 500 错误。

为了避免这种情况，一些复杂的解决方案涉及反射和无构造函数的实例化。如果我们必须在不需要验证的情况下使用写入模型，我建议将断言移到静态工厂方法中。

class User
{
    public function __construct(
        public string $email,
        public string $name,
        public string $password,
    ) {}

    public static function create(string $email, string $name, string $password): self
    {
        Assert::email($email);
        Assert::notEmpty($name);
        Assert::password($password, strength: 3);

        return new self($email, $name, $password);
    }
}

这样，当创建一个需要验证的新模型时，我们可以使用 User::create()，而从数据库获取数据时则使用构造函数。这解决了一些问题，但还有更多。

问题：向模型添加额外数据 另一种常见情况是客户端需要更多数据用于视图。在我们的例子中，视图可能需要显示用户在系统中创建的评论数量。这不是模型的一部分，但为了避免客户端等待额外的请求，我们可能希望在同一个HTTP响应中包含此数据。即使我们尝试在同一个请求中添加数据，坚持使用同一个模型意味着我们不能使用单个数据库请求来获取整个数据集（尽管在许多情况下，可以使用简单的SQL JOIN来实现）。相反，我们获取写入模型，然后执行另一个数据库请求以获取缺失的数据，然后在将其发送给客户端之前进行组合。

return new Response(
    json_encode(
        array_merge(
            $repository->get($request->get('email')),
            ['comments' => $commentRepository->count($request->get('email'))]
        )
    ),
);

这有效，但这意味着额外的数据库查询，从而影响性能。这也降低了可重用性，因为你不能简单地在其他地方调用存储库，你还需要复制粘贴评论部分。

问题：插入和更新真的相同吗？ 最后一个问题与写入与读取模型本身无关，而是当我们更新模型时，我们是否可以使用创建时使用的相同类？

如果我们使用此模型创建新用户，我们需要姓名、邮箱和密码。对于创建用户来说这是合理的，但在我们的例子中，安全专家要求以特定方式更新密码，这涉及用户请求更改密码，发送包含时间限制令牌的邮件给用户，然后验证该令牌并接受新密码。永远不要以其他方式更新密码。那么，如果我们使用相同的模型来更新用户，该怎么办？我们的代码中将有两个不同的位置来更新用户，一个用于密码，另一个用于其他任何内容。

interface UserRepository
{
    public function save(User $user): void;
    public function update(User $user): void;
}

// 更新姓名
$user = new User(
    $request->get('email'),
    $request->get('name'),
    '密码怎么办？',
);

$repository->update($user);

// 更新密码
$user = new User(
    $request->get('email'),
    '姓名怎么办？',
    $request->get('password'),
);

$repository->update($user);

现在，我们必须处理模型中不应该处理的数据，这将使我们的存储库实现更加复杂。它还会迫使模型创建提供不会使用的数据，使代码难以理解。最后，我们得到一个脆弱的实现，如果使用不当，可能会导致不应该更新的内容被更新，仅仅因为它存在于模型中。如果我们以触发密码更新的方式处理用户名更改，那将是一个严重的问题。

解决方案：针对每种情况使用单独的模型 我们如何解决读取用户时遇到的所有问题？专用模型可以做到。

final class UserRead
{
    public function __construct(
        public string $email,
        public string $name,
        public int $commentCount,
    ) {}
}

我们可以为其创建一个新的存储库。

interface UserReadRepository
{
    public function get(string $email): UserRead;
}

假设使用关系型SQL数据库，此实现将不会选择读取模型中不存在的密码字段，解决了问题1。此读取模型不包含密码，解决了问题2。通过在新的存储库中使用单个查询中的JOIN来获取评论计数，解决了问题3。更进一步，如果我们对用户有更多表示，则应该有不同的读取模型来覆盖每种情况。例如，我们可以使用 UserWithLastCommentsRead。

更新问题呢？你可能猜到了，针对每种更新操作使用单独的模型。

final class UserDataUpdate
{
    public function __construct(
        public string $email,
        public string $name,
    ) {
        Assert::notEmpty($name);
    }
}

final class UserPasswordUpdate
{
    public function __construct(
        public string $email,
        public string $password,
    ) {
        Assert::password($password, strength: 3);
    }
}

interface UserRepository
{
    public function save(User $user): void;
    public function updateData(UserDataUpdate $userDataUpdate): void;
    public function updatePassword(UserPasswordUpdate $userPasswordUpdate): void;
}

现在没有错误或不必要的数据。每个更新都是隔离的，并且更不容易出错。

请注意，在更新模型中，我没有添加邮箱验证。这是有意的，因为它将用于查找用户。如果我们进行了进化的验证，如前所述，我们将无法找到不再有效的邮箱，但仍在数据库中。

结语 这与我们在现实世界中对对象的建模方式没有什么不同。在特定情况下，我们从不考虑现实生活中对象的所有方面。例如，汽车。

如果汽车是由司机建模的，我们可以期望座椅位置和后视镜非常重要，而与此同时，这与机械师进行维护无关。机械师可能更关心发动机上对司机不重要的指标。一个学习交通方式的孩子可能只关心它是一个有四个轮子的陆地交通工具。

如果我们对相同的现实生活对象使用不同的模型，那么我们当然也可以对代码中的模型做同样的事情。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《优化PHP应用程序：为什么单独阅读和写入模型很重要》文章吧，也可关注golang学习网公众号了解相关技术文章。