Вот какой вопрос: пользую фреймворк, неважно какой, есть понятие модель.
В классике, модель это сущности: статья, пользователь.
Другой подход - модель-страница, т.е. класс модели отвечает за работу с данными страниц одного типа: страницы статьей, страницы статьи, страницы пользователя...
В чем разница? При первом подходе более четкая структура, при втором - вроде оптимальнее при работе с БД. Т.е., при первом подходе, чтоб показать страницу с 10 статьями нужно сделать 10 селектов статьей и 10 селектов пользователей и что-то еще. При втором подходе - можно сделать один сложный селект только коротких текстов статьей и пользователей. Однако, предполагаю, что если настроить кеширование работы с БД, то можно, даже, получить более низкую нагрузку!?
Скажите свои мысли, плиз.

С каких дел?

Никто не мешает выбрать всех пользователей и статьи одним-двумя запросами и создать нужное количество объектов.

Это сообщение отредактировал(а) Fortop - 20.8.2013, 02:06

Модель - это не столько один или несколько классов, а язык, с помощью слов которого контроллер и view запрашивают данные. Нужно сначала определить слова и фразы этого языка, а потом планировать реализацию модели.

Вообразим типичную, imho, MVC схему. Контроллер выясняет хотелки пользователя и определяет пару "модель"-"view", которая по, мнению контроллера, подходит. Затем обращается к модели со словами "дай данные с такими-то параметрами". Это - одна фраза языка.  В ответ на эту фразу модель может уточнить тип и параметры view и вернёт "данные" - себя самого. (Случай, когда данные возвращаются в виде массива представляется слишком тривиальным и жестким   )  Удобно делать фразу "дай данные" - конструктором модели, таким образом остальные фразы языка - методы и атрибуты "модели".
На этом этапе совсем не обязательно уже иметь готовые данные запроса. Хотя понять есть данные или нет, чтобы вывести в нужном случае 404 страничку - бывает полезно.

Дальше - фразы "модельного языка" начинает употреблять view. Нужно просто посмотреть на его потребности и тупо переписать их в методы.
Что-то типа "дай мне структуру главного меню", "дай мне структуру breadcrumbs", "дай мне массив данных для вывода". Сама фраза "дай мне массив данных", произнесенная view может содержать уточнения - "дай мне 10 записей, совместно с данными о пользователях". Вот в этот момент и нужно выбрать наиболее подходящий запрос к базе, чтобы он был максимально эффективным. 

Предполагаю, что классы для создания нужного кол-ва объектов, находятся в модели (статья, пользователь...). А где находится класс, который знает про пользователей, статьи и другие сущности, который может одим-двумя запросами (знает как составить и сопоставить эти запросы) собрать всю нужную инфу?


Но, ведь круче попросить, например, статью. А статья, имея поле автор, сама подтянет пользователя-автора.
Т.е. просить не данные, а какой-то объект, выходит. А объект статья, ведь, не обязан знать телефон пользователя?  Телефон должен знать объект пользователь. Но статья содержит в себе пользователя с инкапсулированным в нем телефоном. Как-же обойтись одним запросом?

я кажется понял куда клонит ТС, на AR модели? если да то там определяются связи для получения данных из других моделей, как правило по составному PK

Ok! Объект Статья.
В контроллер приходит строка article=XXX. Контроллер запрашивает объект new Article(array('ID'=>'XXX'));

Шаблон sql запроса - `select %fields% from %tables%[ where %where%][ order %order%]`
В статье по умолчанию имеются такие заполнители для него: 
  

Вьюшка может предварительно "приготовить" объект Article, запросив дополнительные поля. Наприемер информация об авторе
- класс User с базовой таблицей my_user, с полями
  
В поле link написано, что таблицы my_articles  и my_users  связаны по полю a.author_id и u.id, так вот получается комплексный запрос

Итого - одним запросом вытаскиваем все нужные данные.

Но можно, конечно, не выпендриваться и тягать данные запросами как только они понадобятся для вывода данных.

Это сообщение отредактировал(а) ksnk - 22.8.2013, 21:28

Active Record? Не знаю. Какое количество запросов предполагает AR в примере статьи и автора?

ksnk, выходит вытаскиваем. Признаться, не все представил, но как бы да. Вы могли бы собрать этот пример полностью, архивом, чтоб можно было поиграться и все понять, плиз. Еще вопрос о влиянии вью на модель. Зачем?

Если завязываться на какой-то AR, придется тянуть за собой целый фреймворк, так как Active Record никогда не ходит один . В принципе - это не так и плохо... К примеру реализация AR от Yii достаточно прилична. Отчего бы не продать душу Yii?   

 От объяснения на пальцах, как мог бы работать конструктор запросов, до реально работающего кода довольно далеко. Да и задача такая передо мной пока не стоит.


Если вью не влияет на модель, то модель выдает только фиксированные данные - строки таблицы по индексам. То есть все отображаемые вьюшкой данные вытаскиваются большим количеством запросов. В то же время, можно вручную состряпать sql, который все эти данные выведет одним запросом. Чтобы модель могла сама построить такое - на нее нужно уметь влиять, объясняя ей, что количество данных - не более 20 (к примеру) строк, что нужны такие-то поля таких-то таблиц... Для других условий запрос может понадобится другой. Запрос, опять же, можно мастерить каждый раз заново, а можно выбирать наиболее подходящий к заказанным условиям из набора написанных вручную, то есть Active Record, как бы, не всегда и нужен.


Дык.   

Почитайте о Data Mapping
Он отвечает за перевод данных в объектную форму. Соответственно ему и знать как данные в таблицах между собой связаны.
Например
http://www.martinfowler.com/eaaCatalog/dataMapper.html
http://www.martinfowler.com/eaaCatalog/dependentMapping.html
http://www.martinfowler.com/eaaCatalog/activeRecord.html

Добавлено через 3 минуты и 23 секунды

Какое влияние?

То, что вью захотело получить не все данные, а только их часть?
Так гибче.

Но никто не мешает в модели создать соответствующие методы

getDataColumns123()
getDataColumns134()
getDataColumnsVasyaPetjaFedja()

И уже в них задавать список дополнительных полей

Fortop, 


Реально качественный совет. 
Многие, типа топик стартера не до конца осознав что нужно, делают формирование частей запроса (например where, join) в контроллере или чего хуже во вьюхе, руководствуясь тем что можно из вне легко ограничить условия и набор. 
Это потом получается катастрофа, особенно если используется во многих частях программы. 

Да, про Data Mapping вижу надобность прочесть.


  Вам что-то известно о ТС?

Возможно, это ко мне   

georgiy11, Можно чуть поподробнее про катастрофы? А то звучит , imho, неубедительно. Те же Active record строят запросы на лету и в массовом порядке, вроде, не самоубиваются...

ksnk, 


Нет, в одной модели AR это нормально и правильно.
Сложности начинаются когда в дестках контроллеров/сущностях/стратегиях используются формирования where наподобие 'field=value AND ....' .
Так вот, когда происходит рефакторинг таблиц или запросов оптимизация, или же банальные изменения свойств к таблице, например поле удаляется, переименовывается: все вхождения поля придётся по всей системе вычислять и это благо если они явно и статично указаны именем как `field` `email` ... , например.
Ещё сложнее происходит, когда имя поля в составе массива приходит с клиента(js/html), например как имя поля формы(имя свойства json данных), и опять приходится отыскивать баг.
То есть, чем меньше знают контроллеры/сущности/стратегии о названиях полей, которые непременно будут фигурировать в составлении запроса, тем локализованей поиск ошибок и легче рефакторинг.
Если все поля в пределах модели AR будут формироваться, не важно как динамически не динамически, и если о всех названиях полей будет знать только модель AR, как отображение таблицы, тем конечно же проще. 

Это сообщение отредактировал(а) georgiy11 - 23.8.2013, 17:14

georgiy11, Ну, это проблема API Active record, а не подхода. Если все "уточнения" идут через api, то никаких особенных глюков и граблей быть не должно. А строить один запрос из нескольких разных мест - это, конечно, грабли.

Просто предостеречь так сказать ТС (если обидил чем то извиняюсь ), есть соблазн крутить её же полями (модели) из других слоёв.

Это сообщение отредактировал(а) georgiy11 - 23.8.2013, 20:24