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

Question

[Леонид Корсаков]

У кого какие аргументы есть по поводу использования 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 у них одна и та же.

Answer 1

[Антон Шаманов]

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

"Студентов и школьников прошу продолжить играть в Dota и не отвлекаться на мой вопрос."
Яркий пример предвзятого отношения от которого стоит избавляться..

Comments

[Леонид Корсаков]

А если ничего кроме Objects::where('votes', '>', 100)->count(); мне не надо выполнить?
Тогда абстракция выглядит переизбыточно.

[Антон Шаманов]

@komandakycto: Секретарша Светочка ничего в искусстве не понимает, она больше по шоппингу специализируется... и, да, это тоже яркий пример предвзятого отношения.
"Тогда абстракция выглядит переизбыточно."
Какая к черту абстракция если ты работаешь с конкретными данными? Будь проще - не на собеседовании.

[kazmiruk]

@komandakycto: Нет, не будет. Так как если Вам понадобится изменить 100 на что-то другое, то Вам надо будет найти все эти места и исправить. А с "толстыми" моделями такой проблемы нет - поменяли в одном методе и забыли. Ну и как выше написали секретарша не должна разбираться с тем что ей дал босс, так как если Вы решите поменять босса, то придется менять и секретаршу. Она должна просто передать указания куда нужно. Очень хорошая аналогия, мне понравилась :) Хотя я лучше пойду поиграю в Доту, ведь я все еще студент (при том, что старше Вас на неделю с лишним) :)

[Леонид Корсаков]

@SilenceOfWinter: Мысль понятна, не обязательно писать так много лишних букв

[FanatPHP]

Все верно, только босс не разговаривает с художником. Для разговоров у нас секретарша

[Антон Шаманов]

@FanatPHP: это как вариант - внутренний босс художника (т.к. М в V) ))) но классический вариант все таки вот такой https://ru.wikipedia.org/wiki/Model-View-Controlle...

[FanatPHP]

@SilenceOfWinter: в РНР такой реализации не видел.

[Антон Шаманов]

@FanatPHP: это то как я описал: С-M-V

[FanatPHP]

@SilenceOfWinter: Хм. А это ведь именно то что я сам же говорю чуть ниже - если судить по фактически выполняемой работе, а не по названиям, и роутер у нас будет контроллером, а контроллер - моделью, то всё сходится.

[Антон Шаманов]

@FanatPHP: ага, а если еще подрисовать ушки, то получиться милый котик ^_^

Answer 2

[FanatPHP]

Основная проблема в том, что у популярных РНР фреймворков нет модели вообще.
А моделью называется тот самый ORM.

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

В случае с Ларавелью мы получаем

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

Отсюда становится видно, что проблема с квери-билдерами - мелкая и надуманная. И для её решения достаточно применить здравый смысл - если вызов однострочный и читаемый, то дергаем прямо в контроллере. Если посложнее - делаем отдельный метод в "модели".

Answer 3

[Вячеслав Плиско]

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

ИМХО, заморачиваться не стоит, делайте как удобнее сейчас, а затем через рефакторинг придёте к нужной для проекта форме.

Comments

[Антон Шаманов]

Затем ты будешь пытаться понять что у тебя написано и как оно работало, а скорее даже не ты, а кто-то другой. Шаблоны программирования не просто так создавались.

[Вячеслав Плиско]

@SilenceOfWinter: в смысле паттерны, я предложил пару разных паттернов использования ORM, но серебрянной пули нет. Для простого проекта использование квери билдера в контроллере гораздо читабельнее и понятнее нежели репозиторий, который разносит логику по разным местам. Если проект коробочный и ядро нужно расширять в последствии бех изменения кода, то репозиторий с инъекциями рулит.
Если проект чуть посложнее, и в последствии условия выборки могут меняться, то логично не использовать билдер в контроллере, а перенести в одно место вроде scope в модели или в репозиторий.
А где-то нужно и доработать ORM, например добавить поддержку identity map и unit of works, особенно для демонов и консольных скриптов.

Нужно пользоваться головой и паттерн сам вырисуется.

[Антон Шаманов]

@AmdY: надо делать правильно, а не как тебе попроще. такой подход наоборот позволяет писать меньше кода (или по крайней мере столько же), как сказано выше избавляет от геморроя при изменении структуры данных, если использовать единый подход во всех проектах, то потом будет проще в них разбираться.

[Вячеслав Плиско]

@SilenceOfWinter: правильно, это как? Вот так a3ab771892fd198a96736e50.javacodegeeks.netdna-cdn....
Правильность сильно отличается в зависимости от проекта и его стадии.

Answer 4

[Рустамка Воронцов]

Я использую связку - худые (тоникие) контроллеры
По этому в модель

Answer 5

[dmitriy]

я использую для этого отдельные классы, Model и ModelManager, в первом CRUD функции во втором все остальное