Во вьюху принято передавать массив или объект?

[lgXenos]

Доброго
Не знаю, как такой запрос сформулировать в поиск, но гугл ничего не ответил толком.


Ситуация такая, что сначала перекидывали массив стандартных AR: результат после ->all()

Потом пришел верстальщик и грит: "Я эти ваши стрелочки как-то не очень понимаю, дай мне обычный массив."
Что сразу побудило проблему: если собирать массив под него - это надо запускать foreach в контроллере, либо костылить модель на возврат то all, то each, то asArray.
Далее возникла специфика, что мы делаем АПИ мобилкам. Т.е. Там как раз foreach в контроллере и выхлоп что вышло.
А чем больше хардкода в контроллере - тем больше он плодится в вебе и АПИ.

В общем как обычно: чем глубже лес - тем больше дрова

Кто может поделится наработанным опытом, когда нужен результат all(), когда его снабдить asArray(), а когда пересобирать массив для передачи дальше вручную?

[zelenin]

Потом пришел верстальщик и грит: "Я эти ваши стрелочки как-то не очень понимаю, дай мне обычный массив."

низкая квалификация верстальщика навязывает вам архитектурные решения

Далее возникла специфика, что мы делаем АПИ мобилкам. Т.е. Там как раз foreach в контроллере и выхлоп что вышло.

эм... я думал просто массив моделей в json и все.. зачем foreach? вы поясняйте свои решения - то, что очевидно вам, не очевидно читающим людям.

А чем больше хардкода в контроллере

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

Кто может поделится наработанным опытом, когда нужен результат all(), когда его снабдить asArray(), а когда пересобирать массив для передачи дальше вручную?

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

[lgXenos]

Вообще вы практически ничего не рассказали, но на основе этого ничего подняли вопрос.

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

низкая квалификация верстальщика навязывает вам архитектурные решения

Все может быть. До этого у нас был Smarty и супер-пупер популярная CMS, о которой никто слыхом не слыхивал и документации не видывал.

эм... я думал просто массив моделей в json и все.. зачем foreach? вы поясняйте свои решения - то, что очевидно вам, не очевидно читающим людям.

Допустим мы делаем АПИ просмотра профиля человека. В оригинальной выборке будет фигурировать как минимум email и хэш пароля.
Нельзя отдавать все поля.
Допустим андроид-разработчик хочет чтоб поле user_name стало называться nickname. Поле в таблице не переименуешь.
Нельзя отдавать как есть.
+ так... отвлекаясь от темы: андроид не имеет нативного json-парсера. это решается костылями и типизацией объектов.

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

Я так понимаю вы
- передаете во вьюху as-is что вернула модель.
- не реализуте проверок в контроллере
и.т.д

asArray() нужен тогда, когда вместо объектов нужны массивы.

Кэп )

Вам нужны массивы?

Возвращаясь к истокам:

в заголовке темы: "какой тип переменных передается из контроллера во вьюху: массив данных или массив моделей объектов?"

[zelenin]

Вообще вы практически ничего не рассказали, но на основе этого ничего подняли вопрос.

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

крупные проекты и yii2 - вещи из разных плоскостей)
вообще вопрос интересный и подходов много, но ни один из подходов не подразумевает передачу массивов вместо объектов.

эм... я думал просто массив моделей в json и все.. зачем foreach? вы поясняйте свои решения - то, что очевидно вам, не очевидно читающим людям.

Допустим мы делаем АПИ просмотра профиля человека. В оригинальной выборке будет фигурировать как минимум email и хэш пароля.
Нельзя отдавать все поля.

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

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

Я так понимаю вы
- передаете во вьюху as-is что вернула модель.
- не реализуте проверок в контроллере
и.т.д

а) я не имею в контролере моделей б) я не осуществляю в контроллере никаких действий. Контроллер нужен для обработки реквеста и респонса. Логики никакой в контроллер закладывать не надо.

asArray() нужен тогда, когда вместо объектов нужны массивы.

Кэп )

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

[lgXenos]

крупные проекты и yii2 - вещи из разных плоскостей)

viewtopic.php?t=5604

в yii2 кстати есть все это из коробки - и rest-компонент

Возможно. Но REST, если я не ошибаюсь, не поддерживает "приватные" АПИ.
Про DTO - пока не в курсе. Принял к сведению.

а) я не имею в контролере моделей

Как это не имею моделей в контроллере? Я говорил, что контроллер собрал реквест и вызвал метод модели. Как в вашем случае кто-то вызовет модель, если ее не вызывает контроллер? Оо

б) я не осуществляю в контроллере никаких действий. Контроллер нужен для обработки реквеста и респонса. Логики никакой в контроллер закладывать не надо.

Я не говорил про логику. Я говорил про проверки. Самое банальное - опущен параметр Х или значение Y больше предела.
Понимаю, что такое можно решить через объект модели, которая как раз описывает входящие параметры и фильтры. Но, блин, если у меня 100 экшенов, что ж мне каждому плодить свою модель-форму? Если они реально разные все...
Альтернатива, конечно, сделать одну модель и 100 сценариев...

[zelenin]

крупные проекты и yii2 - вещи из разных плоскостей)

viewtopic.php?t=5604

угу... там крупных проектов раз-два и обчелся.

в yii2 кстати есть все это из коробки - и rest-компонент

Возможно. Но REST, если я не ошибаюсь, не поддерживает "приватные" АПИ.
Про DTO - пока не в курсе. Принял к сведению.

приватные - с авторизацией? поддерживает вроде.

а) я не имею в контролере моделей

Как это не имею моделей в контроллере? Я говорил, что контроллер собрал реквест и вызвал метод модели. Как в вашем случае кто-то вызовет модель, если ее не вызывает контроллер? Оо

вызовет сервис, в который мы передадим данные из реквеста, а в ответ получим массив дто.

б) я не осуществляю в контроллере никаких действий. Контроллер нужен для обработки реквеста и респонса. Логики никакой в контроллер закладывать не надо.

Я не говорил про логику. Я говорил про проверки. Самое банальное - опущен параметр Х или значение Y больше предела.
Понимаю, что такое можно решить через объект модели, которая как раз описывает входящие параметры и фильтры. Но, блин, если у меня 100 экшенов, что ж мне каждому плодить свою модель-форму? Если они реально разные все...
Альтернатива, конечно, сделать одну модель и 100 сценариев...

ну как не говорили? я спрашивал про foreach в контроллере, а вы ответили про подготовку в foreach моделей для api.
а валидация входных параметров: ну первичную можно и в контролллере сделать, а с какой-то логикой лучше все-таки в модель выделить.

[andreyrud]

ИМХО 2 подхода:
1) Во вью передается всегда чистый PHP массив. Без моделей и вообще без упоминаний про Yii. Тогда нет проблем с квалификацией верстальщиков. Т.е. генерируется некий промежуточный слой (или апи). Получаем развязность моделей, логики и представления.
2) Передаются модели и часть логики, необходимая для конкретного вью. Быстрее, но требует знания Yii и получаем сильно связанное вью.

[zelenin]

ИМХО 2 подхода:
1) Во вью передается всегда чистый PHP массив. Без моделей и вообще без упоминаний про Yii. Тогда нет проблем с квалификацией верстальщиков. Т.е. генерируется некий промежуточный слой (или апи). Получаем развязность моделей, логики и представления.
2) Передаются модели и часть логики, необходимая для конкретного вью. Быстрее, но требует знания Yii и получаем сильно связанное вью.

чем вам не угодил предложенный мной вариант? зачем все это дурно пахнущее?