라라벨 - 상태(플래그)를 저장할 위치?모델, 클래스 또는 구성 폴더?

라라벨 - 상태(플래그)를 저장할 위치?모델, 클래스 또는 구성 폴더?

에서 status 를.나는 그것들이 내 것을 위해 필요합니다.users(active,suspended ), ()active,pending_activation,inactive 및 의 경우(active,on_grace_period,not_subscribed,never_subscribed).

지금까지는 DB에 저장하는 것이 가장 좋은 방법이라고 생각했지만 나머지 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하고 있습니다.foreign_key subscription_status_idsubscriptions블?

저는 열거자 역할을 하는 상태에 대한 특정 모델을 만드는 경향이 있습니다.그래서 만약에 제가.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',
];

애플리케이션에서 @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;
    }
}

나는 다른 대답에 동의하지 않습니다.상태 정보는 데이터베이스에 저장해야 합니다.잘 설계된 데이터베이스는 응용프로그램 없이도 명확하고 사용할 수 있어야 합니다.이 데이터베이스를 사용하여 모바일 애플리케이션 같은 것에도 전원을 공급하기로 결정하면 어떻게 됩니까?데이터베이스에서 일부 정보를 빼내어 Laravel에만 저장하게 됩니다. 즉, 모바일 애플리케이션에서도 해당 상태 목록을 복제하여 둘 사이에 걸쳐 유지 관리해야 합니다.

이런 종류의 정보는 데이터베이스에 저장되어야 합니다.

옵션1

수 인 해야 합니다.enum합니다.subscribed,subscribed-grace,not-subscribed,never-subscribed

이것은 여러분이 보기에 간단합니다.

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

옵션2

개일 각 의 필드가 .TINYINT1아니면0.

별도의 상태표?

많은 할 수 하지 않는 한 에 새 할 수 있습니다.enum적합한 옵션에 따라 새 필드를 추가합니다.

사용자 이외에 데이터베이스의 다른 많은 테이블에 대해 상태를 사용할 계획인 경우 상태 테이블이 이상적입니다.

별도의 상태 테이블이 있는 유일한 이유는 특정 상태의 의미를 변경하기로 결정한 경우뿐입니다.상태 테이블에서 상태 이름을 바꿀 수는 있지만 사용자는 기본 키를 통해 상태 테이블에 연결됩니다.앞의 두 가지 방법으로 상태의 의미를 변경하는 것은 구조의 변경을 수반합니다.

실제로 사용 방법에 따라 결정되지만 데이터베이스에 보관하지 않을 이유는 없습니다.

각각의 방법에는 장점과 단점이 있습니다.각각의 것을 알고 있는 것이 좋습니다.

표 - 장단점(AJReading의 방법):

• 테이블을 추가하고 유지하는 것이 지루하게 느껴집니다.
• 다른 테이블과 모델이 있는 것만으로도 코드가 더 어수선하게 느껴질 수 있습니다(사실이라고 해서 사용하지 않는 것이 좋은 이유라는 말은 아님).
• 데이터베이스의 어떤 것에 의존하는 애플리케이션 로직이 있으면 어색해집니다(데이터베이스의 어떤 것들은 가변적이어야 한다고 느껴지는데, 애플리케이션 로직을 기반으로 할 때는 그것들이 필요합니다).
• 이제는 마이그레이션이 있지만 이전에는 이러한 마이그레이션이 개발자의 존재에 큰 피해를 주곤 했습니다(새로운 상태를 추가해야 하므로 서버 간 전환이 매우 번거로웠습니다. 그렇지 않으면 애플리케이션이 중단될 수도 있기 때문입니다.데이터베이스 변경을 통해 이 작업을 수행해야 했겠지만 그래도 이 작업은 제가 가장 자주 수행해야 하는 작업이었습니다.
• 데이터 무결성에 적합

상수 사용: 장단점(Martin Bean의 방법):

• 위의 단점을 방지합니다.
• 이것들은 당신의 코드와 기본 논리에서 참조하기 쉽습니다.
• 새 모델이나 테이블을 작성할 필요는 없습니다(이 예제에서는 작성하지만 이벤트 모델에 추가할 수도 있습니다).
• 무대 뒤에서만 사용할 수 있는 가치에 적합합니다.
• 질의의 양이 줄어듭니다.
• 그들은 단지 그렇게 많은 일을 하고 싶지 않을 뿐입니다.재분류하기가 더 쉬운 것 같습니다.
• 반대: 라벨을 붙이고, 모두 검색하고, 설명을 얻는 등의 일을 하게 되면 그들은 다소 어색해집니다.번역 솔루션도 좋지만, 앱에서 번역을 사용하지 않으면 이것도 조금 어색합니다.
• 궁극적으로 그들은 당신이 가는 ORM 흐름을 깨뜨리고 있습니다.다른 모든 모델이 Expellent를 확장하면 틀이 조금 깨집니다.
• 어떻게 하면 이것을 가장 잘 할 수 있을지에 대한 실질적인 합의가 없습니다.많은 사람들이 매번 다른 방법을 사용합니다.
• AJReading의 말처럼 프로젝트의 다른 측면에서 데이터베이스를 단독으로 사용해야 하는 경우에는 작동하지 않습니다.

저는 일정한 방법을 사용하지만 가끔 테이블을 사용한다면 제 코드가 더 깨끗하고 간단할 것이라고 생각합니다.곤란합니다.일관성을 확보할 수 있는 일관성 있는 방법에 대해 잘 문서화된 해결책이 있으면 좋겠는데 아직 보지 못했습니다.어느 쪽이든 저는 정답이 없다고 생각합니다.골라주세요.

이런 성격의 결정에 대해서는 다음과 같이 자문해 보십시오.

"이러한 상수가 서로 다른 값을 갖는 것이 합리적인 애플리케이션 사례가 발생할 수 있을까요?"

예를 들어 테스트 환경, 일종의 클론, 일부는 아직 정의되지 않았지만 미래 버전일 가능성이 있습니다.

만약 그 질문에 대한 답이 "예"라면, 아마도 애플리케이션 구성에 들어갈 것입니다.

값이 변경될 가능성이 없는 경우(또는 daft) 값은 모형에 속하며 모형에 들어가야 합니다.

이 경우에는 다른 값을 가진 애플리케이션 버전을 가질 합리적인 이유가 없기 때문에 모델에 넣을 것을 제안합니다.

언급URL : https://stackoverflow.com/questions/32917944/laravel-where-to-store-statuses-flags-model-class-or-config-folder