MVC, Laravel и толстые контроллеры

Статус
В этой теме нельзя размещать новые ответы.

Minor

Постоялец
Регистрация
16 Авг 2012
Сообщения
260
Реакции
111
Полгода как начал плотно работать с Laravel, до этого вообще с фреймворками серьезно дела не имел, не совсем пойму такую вещь, почему в Laravel бОльшая часть работы с БД вынесена именно в контроллер, например

Код:
<?php

namespace App\Http\Controllers;

use App\Flight;
use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class FlightController extends Controller
{
 /**
 * Создание нового экземпляра рейса.
 *
 * @param Request $request
 * @return Response
 */
     public function store(Request $request)
     {
     // Проверка запроса...

     $flight = new Flight;
     $flight->name = $request->name;
      $flight->save();
      }
}

хотя логичнее в плане MVC сделать например так

Код:
public function store(Request $request)
     {
     // Проверка запроса...
     Flight::createFlight($request->name);
      }

Дело в том, что я до Laravel много работал с Simpla, там вся работа с данными вынесена в модели, а в Laravel почему то в контроллеры, из за чего они получаются довольно толстыми.

Собственно вопрос, а в чем плюсы такого подхода и почему именно такой подход описан в доках?
 
Это просто примеры из документации, ты можешь делать так как тебе удобно. Но таки да, такой код в доках популярного фреймворка научит не самым лучшим практикам начинающих.
Статический метод из твоего примера, тоже плохой подход, если ориентируешься на качество. Такой код будет сложно или невозможно протестировать юнит тестами.
 
Это просто примеры из документации, ты можешь делать так как тебе удобно. Но таки да, такой код в доках популярного фреймворка научит не самым лучшим практикам начинающих.
Статический метод из твоего примера, тоже плохой подход, если ориентируешься на качество. Такой код будет сложно или невозможно протестировать юнит тестами.
А какой подход будет правильным по твоему мнению? Я просто до юнит-тестов еще не дошел :).
 
А какой подход будет правильным по твоему мнению? Я просто до юнит-тестов еще не дошел :).
А правильность подхода определяется твоими целями.
На текущем рабочем проекте, у меня есть смысл обращаться к хранилищам через репозитории, создавать коллекции объектов, в контроллере вызывать сервисы, которые всё это обрабатывают. Дробить логику на минимальные методы и стараться всё покрыть тестами.

А для домашних проектов в целях проверки Proof of concept (PoC) я всю логику в контролер пихаю с голыми SQL без всяких там AR ;)
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху