@komandakycto
php программист

Практичное использование orm. Где? Модель? Контроллер?

У кого какие аргументы есть по поводу использования orm. Конкретно интересует, вопрос вызова методов построителя запросов или AR.
Вызывать в контроллере код вида:
Objects::where('votes', '>', 100)->count();

или выносить такие вещи в модель, создавать при этом некоторое апи, вроде этого:
class Objects extends Illuminate\Database\Eloquent\Model {
    protected $table = 'objects';
    
    public function getObjects() {
        //еще ряд каких-то действий
        //...
        return Objects::where('votes', '>', 100)->count();
    }
}

и вызывать потом
Objects->getObjects();

Пример утрирован для достижения простоты. Не привязываюсь к конкретному фреймворку, суть orm у них одна и та же.
  • Вопрос задан
  • 2779 просмотров
Пригласить эксперта
Ответы на вопрос 5
SilenceOfWinter
@SilenceOfWinter
та еще зажигалка...
В парадигме MVC работа с данными ведется в модели.
Я бы описал MVC это как небольшую фирму в которой есть С - секретарша, которая принимает заказ и передает его M - боссу, он в свою очередь говорит V - художнику что и как нарисовать. Полученный шедевр V передает С, которая отдает его клиенту.

"Студентов и школьников прошу продолжить играть в Dota и не отвлекаться на мой вопрос."
Яркий пример предвзятого отношения от которого стоит избавляться..
Ответ написан
FanatPHP
@FanatPHP
Чебуратор тега РНР
Основная проблема в том, что у популярных РНР фреймворков нет модели вообще.
А моделью называется тот самый ORM.

Соответственно, от использования ОРМ в контроллере отказаться в принципе невозможно. А сама идеология фреймворка склоняет к тому, что моделью выступает контроллер - в котором и пишется вся бизнес-логика.

В случае с Ларавелью мы получаем
  • Модели лежит в папке Controllers, при этом используя
    • ORM из папки Models для манипуляции с данными
  • Визуальное отображение лежит в папке Views
  • Секретарша лежит в routes.php.


Отсюда становится видно, что проблема с квери-билдерами - мелкая и надуманная. И для её решения достаточно применить здравый смысл - если вызов однострочный и читаемый, то дергаем прямо в контроллере. Если посложнее - делаем отдельный метод в "модели".
Ответ написан
Комментировать
AmdY
@AmdY
PHP и прочие вебштучки
В по настоящему сложных проектах лучше не использовать построитель запросов в контроллере, все нужно делать в моделях. При этом даже модель принято разделять на чистую модель и репозиторий который таскает данные.
То таких проектов мало, обычно достаточно вашего второго способа, только нужно отвязываться от имени класса заменив его на static. Есть ещё scope, туда всякие условия засовывать.
Ну и для многих проектов хватит лапши с квери билдером прямо в контроллере, такие веши потом можно зарефакторить по мере необходимости, благо современные IDE это делают на раз-два.

ИМХО, заморачиваться не стоит, делайте как удобнее сейчас, а затем через рефакторинг придёте к нужной для проекта форме.
Ответ написан
Я использую связку - худые (тоникие) контроллеры
По этому в модель
Ответ написан
Комментировать
dmitriylanets
@dmitriylanets
веб-разработчик
я использую для этого отдельные классы, Model и ModelManager, в первом CRUD функции во втором все остальное
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы