Kohana ORM & MVC

Question

хотя я довольно неплох в PHP, я новичок в фреймворках. начал с КИ на прошлой неделе и обнаружил, что смотрю на Кохану на этой неделе. У меня есть несколько вопросов на этот счет:

1. почему ORM против традиционных SQL или активных запросов?
2. если модель должна извлекать данные из БД, то почему в ORM большая часть действий происходит в контроллере (или так кажется), т. Е. ($data=$q->where('category', '=', 'articles')->find_all();}
3. как бы я сделал условный запрос в ORM? (что-то вроде if (isset ($ _ GET ['category'])) ... и т. д.) если условие передается модели? или должен ли контроллер выполнить все условия

К вашему сведению, мои запросы, как правило, содержат многочисленные объединения, и мои ограниченные знания говорят мне, что у меня должен быть контроллер запросов, который передает параметры запросов в модель запросов, которая выполняет запрос и возвращает результаты. Пожалуйста, дайте мне знать, если мое понимание верно большое спасибо

Answer 1

1. ORM - это какая-то оболочка над слоем БД. Итак, вы просто звоните $user->find($id) вместо $db->query('select * from users where id='.$id) или DB::select()->from('users')->where('id', '=', $id)->limit(1)->execute(). Вы объявляете параметры модели (имя таблицы, отношения и т. Д.) И используете только методы модели для работы с ее данными. Вы можете легко изменить структуру БД или механизм БД без изменения большого количества кода контроллера.

2. Согласитесь с Ikke, контроллер должен избегать данных, специфичных для модели, таких как условия запроса. Например, создать метод get_by_category($category).

3. См. № 2. Все нужные аргументы должны быть переданы в метод модели (это можно сделать с помощью цепочки, например $object->set_category($category)->set_time_limit(time())->limit(10)).

Answer 2

1. ORM - это еще один способ получить ваши данные.Идея состоит в том, что существует много общих операций, которые можно автоматизировать.И поскольку отношения между таблицами можно легко преобразовать в объекты, ссылающиеся друг на друга, ORM был создан.

   Вам решать, хотите ли вы использовать прилагаемый модуль ORM.Есть и другие, которые также часто используются (например, веточка, желе и автомоделист).

2. Мое личное мнение состоит в том, чтобы ограничить этот вид операций до минимума.Таким образом, очень простые операции могут быть выполнены, поскольку они едва дают каких-либо преимуществ при размещении их в модели, но лучший способ - это попытаться использовать в моделях как можно больше бизнес-логики.

   Другой момент заключается в том, что именно представление должно получать данные от моделей.Таким образом, когда вы хотите повторно использовать представление, необходимо дублировать очень мало кода.Но для предотвращения слишком большого количества логики в ваших представлениях, рекомендуется использовать так называемые классы представления, которые содержат логику для ваших представлений и являются интерфейсом для ваших представлений, с которыми можно общаться.

3. Существует библиотека проверки, чтобы убедиться, что все данные для вашей модели верны.Ваши модели не должны знать о $ _GET и $ _POST, но данные из этих массивов могут быть переданы вашим моделям.