Laravel에서 Fat Controller를 방지하기 위한 또 다른 팁

이 문장에 관하여

이것은 며칠 전에 쓴 이 보도의 보충이다.
Laravel에서 Fat Controller를 방지하는 5가지 Tips-Qiita
Fat Controller가 된 주요 원인은 모델 층이 너무 빈약하기 때문이다.원래 모델에 써야 할 처리는 Controller에 쓰여 있는데 결과적으로 가독성이 떨어지기 때문에 하나의 용례에 대한 변경은 다른 용례에 영향을 주고 Controller 사이에서 복제 코드를 대량으로 생산한다.
쓰면서'모델에 써야 할 처리가 컨트롤러에 의해 쓰였다'는 예시를 쓰지 못해 보충했다.

입문

'모델에 써야 할 처리'는

이 글에서'모델에 써야 할 처리'는 다음과 같다.

모델 상태 변경 처리

Model 상태의 조건 브랜치입니다

조회 구축

1. Model 상태 업데이트 처리, 2.모델 상태 기반 조건 분기

1, 2는 해설이다.
가장 간단한 방법은 다음 대상을 생성할 때 하나하나 속성을 설정하는 것이다.속성 줄 수가 증가하기 때문에 그것을 합치면 매우 효과가 있다.

$user = new User();
$user->name = $request->name;
$user->email = $request->email;
// ....
$user->save();

그에 비해 검증 규칙을 적절하게 설정한 토대에서 다음과 같이 정리하는 것이 좋다.

User::create($request->all());

데이터를 변환해야 한다면 FormRequest 방면에서 함수를 만들어서 그것을 하게 하면 된다.
도메인에 더 가까운 예라면, 예를 들어 TODO 응용 프로그램에서 작업을 생성하는 처리에서'작업의 초기 상태가'todo'라는 규칙이 있을 때

$task = Task::create(['status' => 'todo'] + $request->all());

이와 같은 처리는 다음과 같이 모델에서 전용 방법을 만들어 가지게 할 수 있다.

// Controller
$task = Task::createTodo($request->all());

// Model
public static function createTodo(array $attributes) {
    return parent::create([
        'status' => 'todo',
    ] + $attributes);
}

행수 자체는 줄지 않지만 컨트롤러의 코드를 보면'TODO 만들기'캐릭터에 특화된 이름이 있어 식별하기 쉽다.
또한 TODO 응용 프로그램에서도 완료된 작업만 삭제할 수 있는 도메인 규칙이 있는 경우

if ($task->is_complete) {
    $task->delete();
}

이렇게 쓰는 것보다

// Controller
$task->delete();

// Model
public function delete() {
    if ($this->is_complete) {
        parent::delete();
    }
    throw new \DomainException('...');
}

이렇게 하면 줄 수가 적어진다(이것은 부차적인 작용이 있기 때문에 삭제할 수 있는 조건을 더욱 방법화하여 조건이 변화할 때 처리하기 쉽다).조건이 충족되지 않은 상황에서 어떻게 행동하는지는 응용 프로그램의 요구에 달려 있다고 생각하지만 422개의 처리할 수 없는 실체가 필요할 수 있습니다. 컨트롤러로 404Not Found의 절차를 되돌려줍니다.
현재 속성이 하나밖에 없기 때문에 은혜는 매우 얇지만 조건이 복잡해지면 모델에 갇혀 코드의 중복을 방지하기 쉽다(이로 인한 업데이트 누락).
나는 개인적으로 어떤 처리 조건을 만족시키는지 이런 판정은 검증으로 진행할 수 있다고 생각하지만, 집행 가능한 처리와 집행 가능한 조건은 부근이 비교적 좋다고 생각한다위의 예에서 우리는 그것을 모델 측에 두었다. (만약 이것이 컨트롤러의 입력 매개 변수의 상태에 달려 여러 모델의 전체 처리의 실행 여부를 결정한다면 검증 측면에서 실현하는 것이 가장 좋다.)

3. 조회 구축

간단한 WHERE, ORDER BY 조합된 물건은 원형을 유지할 수 있지만 복잡한 조건문이 있는 물건은 모형에 넣는 것이 가장 좋다.예를 쓰기는 어렵지만 예를 들어 하위 임무를 포함한 여러 조건과 일치하는 조회라면 다음과 같이 조회 건축은 계속될 것이다.

$tasks = Task
    ::whereHas('sub_tasks', function ($builder) {
        $builder->where('...')
        // 他にもずらずらと条件がある
        ;
    })
    ->where('...')
    // 他にもずらずらと条件がある
;

이것

// Controller
$tasks = Task::inSomeState()->get();

// Model
public function scopeInSomeState(Builder $builder) {
    return $builder
        ->whereHas('sub_tasks', ...)
        ->where(...)
    ;
}

이렇게 작용역을 하다.
아니면 일반적인 방법으로 불러도 돼요.

// Controller
$tasks = Task::getInSomeState();

// Model
public static function getInSomeState() {
    return static::whereHas(...)->where(...)->get();
}

저는 개인적으로 범위화를 좋아하지만 IDE의 보충과 도약 문제를 피하고 싶은 사람도 있습니다. (PHPDoc에 쓰면 인식되지만 정의원으로 뛰어들 수 있는 것은 아닙니다.)그 일대는 네가 좋아한다.

끝내다

또 다른'모델에 써야 할 처리'가 있다고 생각하지만 어떤 상황에서도 다른 Tips와 마찬가지로'중복이 문제가 되는 원인'이 문제이기 때문에 어디에 써야 할지보다는 의미 있는 처리의 총결에 이름을 지어주고 국부화하는 것이 중요하다.
또 다른'모델에 써야 할 처리'모드가 있다면 댓글란에 알려주세요