Laravel - 在哪里存储状态（标志）？模型、类或配置文件夹？

Question

我需要在 mt 项目中广泛使用状态。我的users（active、suspended 等）、一个实体（active、pending_activation、inactive）和我的订阅（active、on_grace_period、@987654329）需要它们@, never_subscribed)。

到目前为止，我认为最好的方法是将它们存储在数据库中，但我觉得将它们存储在其他 3 个选项中要容易得多。

我还认为我可以将它们作为常量存储在我的 Eloquent 模型中。例如，我的订阅模型如下所示：

// SubscriptionModel
const SUBSCRIBED_ACTIVE = 1;
const SUBSCRIBED_ON_GRACE_PERIOD = 2;
const NOT_SUBSCRIBED = 3;
const NEVER_SUBSCRIBED = 4;

并检索它们，例如在刀片视图中：

// subscription/index.blade.php
@if($user->subscription->status == /App/SubscriptionModel::SUBSCRIBED_ACTIVE)
    <div>You are subscribed. Thank you</div>
@elseif($user->subscription->status == /App/SubscriptionModel::NEVER_SUBSCRIBED)
    <div>You need to create a subscription before being granted full access!</div>
@elseif(...)
    // and so on

如何做同样的事情，但使用 config 文件夹并添加一个名为 status.php 的文件。在视图中访问它就像：

@if($user->subscription->status == Config::get('status.subscription.SUBSCRIBED_ACTIVE'))
<div>You are subscribed. Thank you</div>
@elseif(...)
// etc

有没有更好的办法？

另外，等式的另一部分如何，即存储在DB 中的状态。我是否应该只为订阅表创建一个 status 列并存储应用程序指定的内容，或者甚至更好地创建一个单独的表 subscription_statuses 并在 subscriptions 表中创建一个 foreign_key subscription_status_id？

Answer 1

我倾向于为状态创建一个特定的模型，它充当一个枚举。所以如果我有一个Event 模型，我可能有一个对应的EventStatus 模型，看起来像这样：

class EventStatus
{
    public const CANCELLED = 'EventCancelled';
    public const POSTPONED = 'EventPostponed';
    public const RESCHEDULED = 'EventRescheduled';
    public const SCHEDULED = 'EventScheduled';
}

然后我可以像这样进行检查：

$event->status === EventStatus::CANCELLED;

而且我通常也会在我的模型中添加方便的方法：

class Event extends Model
{
    public function isCancelled(): bool
    {
        return $this->status === EventStatus::CANCELLED;
    }
}

对于“人类友好”的字符串，我将有一个包含文本字符串的语言文件：

<?php // resources/lang/en/event_status.php

return [
    EventStatus::CANCELLED => 'Cancelled',
    EventStatus::POSTPONED => 'Postponed',
    EventStatus::RESCHEDULED => 'Rescheduled',
    EventStatus::SCHEDULED => 'Scheduled',
];

Answer 2

我不同意其他答案。您的状态信息应存储在数据库中。一个设计良好的数据库应该在没有应用程序的情况下清晰可用。如果您决定使用这个数据库来支持移动应用程序之类的东西，会发生什么？您将从数据库中取出一些信息并仅将其存储在 Laravel 中，这意味着您还必须在移动应用程序中复制该状态列表，并在两者之间进行维护。

此类信息应存储在数据库中。

选项 1

如果您的用户只能拥有一种状态，那么您应该使用具有值 subscribed、subscribed-grace、not-subscribed、never-subscribed 的 enum 字段

这在你看来很简单：

@if($user->subscription->status == 'subscribed'

选项 2

但是，如果您可能有多个状态，那么您几乎可以肯定每个状态都有一个单独的字段，并使用TINYINT 来存储1 或0。

单独的状态表？

我看不出使用单独状态表的充分理由，除非您预计可能会添加更多状态，即使您要添加更多状态，您也可以向 enum 添加新值或添加新字段，具体取决于哪个选项适合。

如果您打算将状态用于数据库中除用户之外的许多其他表，则状态表将是理想的选择。

单独的状态表的唯一其他原因是您决定更改特定状态的含义。这意味着您可以重命名状态表中的状态，但用户仍将通过其主键链接到它。使用前两种方法更改状态的含义会涉及到结构的更改。

这实际上取决于您预期如何使用它们，但没有理由不将它们保存在数据库中。

Answer 3

在我的应用程序中，我与@Martin Bean 类似，只是我没有为状态创建单独的类，而是将其存储在现有的类/模型中。

我将调用user、subscription 和entity 一个实体。

• 实体有一个status，存在于它的模型和数据库中的表中。
• 每个模型都有可能取值为status 的常量，例如ACTIVE、INACTIVE、PENDING 等，每个模型的值可能有所不同。
• 创建处理它的方法，例如getStatusLabel()、listStatus()、isActive()、isX() 等。
• 那些isActive/X() 仅在真正需要时才创建，也许一个模型有 4 个状态，但您只能与一个特定状态进行比较，所以我只会为该状态创建一个 isX()。

示例

class User
{
    const STATUS_ACTIVE    = 1;
    const STATUS_SUSPENDED = 2;
    const STATUS_INACTIVE  = 3;

    /**
     * Return list of status codes and labels

     * @return array
     */
    public static function listStatus()
    {
        return [
            self::STATUS_ACTIVE    => 'Active',
            self::STATUS_SUSPENDED => 'Suspended',
            self::STATUS_INACTIVE  => 'Inactive'
        ]
    }

    /**
     * Returns label of actual status

     * @param string
     */
    public function statusLabel()
    {
        $list = self::listStatus();

        // little validation here just in case someone mess things
        // up and there's a ghost status saved in DB
        return isset($list[$this->status]) 
            ? $list[$this->status] 
            : $this->status;
    }

    /**
     * Some actions will happen only if it's active, so I have 
     * this method for making things easier.
     * Other status doesn't have a specific method because
     * I usually don't compare agains them
     * @return Boolean
     */
    public function isActive()
    {
        return $this->status == self::STATUS_ACTIVE;
    }
}

Answer 4

每种方法都有优点和缺点。了解每一个是很好的。

表格 - 优缺点（AJReading 的方法）：

• 添加和维护表看起来很乏味
• 仅仅拥有另一个表和模型会使我们的代码感觉更加混乱（并不是说这是一个很好的理由不使用只是说它有点真实）
• 当我们的应用程序逻辑依赖于数据库中的某些内容时（数据库中的内容感觉应该是可变的，而当我们将应用程序逻辑基于它们时，它们是必需的）时会变得很尴尬
• 现在我们有了迁移，但在迁移之前，这些曾经是开发人员存在的祸根（它们会使服务器之间的切换变得很麻烦，因为您必须记住添加新状态，否则您的应用程序会崩溃）...您会必须对任何数据库更改执行此操作，但这些仍然是我最经常要做的事
• 有利于数据完整性

使用常量：优点/缺点（Martin Bean 的方法）：

• 避免上述缺点
• 这些很容易在您的代码和基础逻辑中引用
• 您甚至不必创建新模型或表（他在他的示例中这样做了，但您也可以将它们放入事件模型中）
• 它们非常适合仅在幕后使用的值
• 它们减少了查询量
• 他们只是觉得工作量不大。它们似乎更容易重构。
• 缺点：当您对它们进行标记、检索所有它们、获取描述等时，它们会变得有点尴尬。翻译解决方案是一个很好的解决方案，但如果您不在应用程序中使用翻译，那么这会有点尴尬也一样。
• 最终，他们破坏了您正在进行的 ORM 流程。如果您的所有其他模型都扩展了 Eloquent，那么这会有点打破常规。
• 对于如何最好地做到这一点没有真正的一致意见。很多人每次都使用不同的方法。
• 就像 AJReading 所说，如果您需要单独将数据库用于项目的另一个方面，它将无法工作

我使用常量方法，但有时我认为如果我使用表，我的代码可能会更简洁。这是一个艰难的决定。我希望有一个有据可查的解决方案，用于恒定方法至少创建一致性，但我还没有看到一个。无论哪种方式，我认为没有正确或错误的答案。选择一个并使用它！

Answer 5

对于这种性质的决定，问问自己：

“是否会有我的应用程序的实例 这些常量是否有不同的值？"

例如一个测试环境，某种克隆，一些尚未定义但可能的未来版本......

如果该问题的答案是“是”，那么它可能应该进入应用程序配置。

如果这些值不太可能（或愚蠢）发生变化，则它们属于并且应该进入模型。

我建议在这种情况下，没有合理的理由拥有具有不同值的应用程序版本，因此我将其放入模型中。