Почему плохо писать код в шаблонах?

Question

[NubasLol]

Почему плохо писать php код в шаблонах, c хождением в бд и т.д?

Нужны конкретные доводы и желательно примеры.

Comments

[edward_freedom]

так даже чисто логически понятно, что шаблон просто отрисовывает интерфейс, для обращения к бд есть контроллер

[FanatPHP]

edward_freedom,

для обращения к бд есть контроллер

сотри пока никто не видел

[edward_freedom]

FanatPHP, а ты научись писать кратко и без воды, твои сочинения читать пол дня не вариант

[FanatPHP]

edward_freedom, дурачок, я о тебе забочусь. заплюют ведь - утонешь.

[ThunderCat]

edward_freedom, Вас коллеги часто бьют?

[RMate]

edward_freedom, воистину, единственная цель контроллера принять запрос, запихать в сервис и отдать результат по завершению. Для обращения к бд и вовсе используются модели. О.о

[edward_freedom]

RMate, то что модель понятно, а модель где будет вызываться? Правильно, с контроллера или сервиса

[edward_freedom]

ThunderCat, я не работаю на дядю и не раб, я фрилансер и у меня свои проекты есть, которые приносят прибыль

[RMate]

edward_freedom, товарищу автору нифига не понятно, и вы направляете его на ложный путь, пренебрегая конкретикой)

[ThunderCat]

edward_freedom, в таком случае не надо делиться вашими "профитными стратегиями успеха", которые противоречат как здравому смыслу, так и элементарной профессиональной грамотности.

Answer 1

[FanatPHP]

Ну вот сломалась у тебя база данных. Ошибку выдаёт. Что будешь делать? Пол-шаблона то уже вывелось.

Вообще хороший вопрос, в чем-то показательный.
Новички все поголовно мыслят позитивными сценариями, причем линейными. Запросил - получил - вывел.
И только с опытом приходит понимание, что на этапе запросил могут возникнуть проблемы. что на этапе "получил" из бд вылезто то, то что надо было вывести в заголовке страницы. Как этот фарш теперь провернуть назад? Что этап "вывел" тоже не так прост - иногда надо вообще ничего не выводить, а сделать редирект к примеру.

Именно поэтому вывод начинается только после того, как вся логика отработала и все данные получены.

Comments

[NubasLol]

Ну вот laravel взять. Он же сначала в html перегонит blade. Если там будет ошибка, то выдаст исключение.

[DevMan]

NubasLol, при чем тут ларавел и блэйд?

[NubasLol]

DevMan, при том, что не будет так, что половина шаблона загрузилась

[DevMan]

NubasLol, если что-то с данными пошло не так, до шаблона вообще не должно доходить.

[NubasLol]

DevMan, почему?

[DevMan]

NubasLol, потому что данные - логика приложения, а не отображения.
если ты не можешь их получить/обработать, задача шаблонизаторы - максимум, показать страницу ошибки.

[NubasLol]

DevMan, но если и так работает.

[DevMan]

NubasLol, если итак работает и как правильно - разные понятия.

[NubasLol]

DevMan, вот как обьяснить человеку , который так делает, что бы он не делал

[DevMan]

NubasLol, так и объяснить. если человек не понимает простые слова, он отлично поймет административные меры или прощание с ним.

[FanatPHP]

DevMan, никак не объяснять. У меня было ощущение что вопрос задан для чего угодно, но только чтобы узнать ответ. Ну оно и подтвердилось, только и всего :)

[DevMan]

FanatPHP, типа того.

Answer 2

[ThunderCat]

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

Comments

[NubasLol]

Пример: нужно вывести список заказов. Я пишу просто в шаблоне цикл, бегаю по модельками orders и у меня все хорошо. Чем это плохим может закончится?

[Евгений Ромашкан]

Во-вторых - все что относится к формированию данных должно быть отделено от вывода, в идеале вынесено в модель

Только если это отдельная read-модель а не сущности с бизнес логикой.
Во write-моделях в идеале должна быть бизнес-логика.

Ну, если уж мы говорим о "в идеале".

[ThunderCat]

NubasLol, тем что будут бить. Больно. Как минимум за запросы в цикле. Ну и до кучи так как в контроллере вы не определились - что вам нужно во вьюшке и начали фигачить код там "где понадобилось", вместо "где надо".

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

[NubasLol]

ThunderCat, запрос один, я сразу получу коллекцию моделей

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

Как обьяснить человеку, который пишет код в шаблоне, что это плохо? И показать пример почему. А не просто сказать, так плохо, это нарушает структуру проекта. Ведь у него все работает

[ThunderCat]

Евгений Ромашкан, Модель она и есть модель, в нее может входить в том числе и репозиторий и бизнес-логика как отдельные компоненты модели. Как то у вас странно все, сущность оторвана от репозитория и бизнес-логики что ли?

[ThunderCat]

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

[ThunderCat]

Евгений Ромашкан,

Термин "Модель" в данном случае я не использую

...

Только если это отдельная read-модель

та-дааа...

Сущность это класс описывающий бизнес логику, её жизненный цикл не зависит от экземпляров других классов.

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

[Евгений Ромашкан]

ThunderCat,

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

Учитывая количество трактовок слова "модель" в разработке, я понятия не имею что вы имеете ввиду.
Отображение - в представлениях(А ещё лучше писать апишки, чем я и занимаюсь).
Бизнес логика - в сущностях. Сущность не хранилище данных, не представление таблицы из БД, не модель данных. Сущность - объект с поведением.
Выборки данных для отображения - QueryObjects или Гейтвей к хранилищу.

Вот как раз сущность это непонятный термин, а в MVC модель - совокупность классов отвечающая за функционирование отдельно взятой абстракции, включающая в себя данные, бизнес-логику и репозиторий.

в класическом мвц - два и более, в зависимости от архитектуры.

MVC это паттерн про десктопные приложения, и модель там представлена не так.
Ему уже почти пол века, если что. В вебе MVC нет.

А ещё термин "модель" имеет 100500 других трактовок в различных архитектурах помимо MVC.

AR - это один класс,

AR - антипаттерн, а вы его как "в идеале должно быть" представляете.

[ThunderCat]

Евгений Ромашкан,

MVC это паттерн про десктопные приложения, и модель там представлена не так.
Ему уже почти пол века, если что. В вебе MVC нет.

Вах, как много сразу глупостей в двух предложениях. Про пол века единственная адекватная фраза, и та к делу не относится, так тот же солид постарше даже будет, и ниче так, работает.
Модель в "тру мвц", которое у вас в "десктопные приложения" абсолютно такая же. Другое дело что взаимодействие ее с контроллером строится иначе, нежели в десктопе, ибо умирание/сессионность, отсутствие стейта и вот это все в вебе чуть иначе. Модель не поменялась ровно никак. В плане "В вебе MVC нет" - вообще без комментариев. То что он там другой (немного) не значит что его нет. Паттерн тем и хорош что весьма адаптивен, даже в разных по сути средах исполнения.

AR - антипаттерн, а вы его как "в идеале должно быть" представляете.

Ну вот опять, детская принципиальность... Во первых - я не писал что это в идеале должно быть, скорее наоборот - есть AR (как упрощенный вариант все-в-одном) и есть классическая модель с разделением ответственности на классы. И во-вторых - AR тоже нормально использовать, если конечно нимб кулхацкера на глаза не падает и сущностей в проекте 4-5 штук, вполне себе нормальное решение.

[Евгений Ромашкан]

ThunderCat,

В плане "В вебе MVC нет" - вообще без комментариев. То что он там другой (немного) не значит что его нет.

Это значит что его нет, но некоторые программисты не разобравшись называют так свое поделие, не понимая зачем нужны конкретные ограничения. Точно так же как и с REST.

Дело ваше, впрочем.

[ThunderCat]

Евгений Ромашкан, нуда нуда, что эти недопрогеры из зенд могут понимать в программировании...

Answer 3

[Denis]

Все познается на больших проектах,
в качестве примера возьмем методику MVC опенкарта где есть три слоя абстрации:
1) если это запрос то для этого есть модель
2) если это что-то из пхп кода то это контроллер
3) если это хтмл то это шаблон
Парни почистили от мусора код и "выкинули" в свет. Все просто красиво и самое главное бесплатно и без смс.
Но, а теперь взглянем почему же все ненавидят опенкарт. А потому что разработчиками не предусмотрены моменты как можно расширять и кастомизировать код, и все пишут свои кастомайзы там где и предусмотренно, в контроллере и когда владельцы сайта начинают баловаться модулями то оказывается схожие по функционалу модули пытаются внедрить одновременно свой код в одно и то же место одного и тогоже контроллера и начинается чихорда когда одни функции используют данные которые будут получены двумя строками ниже или два разных модуля добавили свои параметры в стандартную функцию.
многие умники догадались что можно весь треш перевести в шаблон где уже все данные получены, и контроллеры и шаблоны начинают разрастаться когда 3000-5000 строк в одном файле это норм и не такое видали, сайт начинает глючить, найти ошибку или добавить свой кастомайз становится просто невыносимым, я еще молчу про ocMod или vqMod (но это уже другая история)
итог 3 версия опенкарта использует twig темплейты, где нельзя так просто "ворваться" со своим php кодом, но и основных проблем не решила.

Answer 4

[Олег Фролов]

Конечно, писать код в шаблонах не очень хорошая идея. Но обращаться к базе, почему нет? Вопрос реализации шаблона и уровня абстракции.
Например, так:

<ul data-wb='{
   "role":"foreach",
   "from":"news",
   "where": {
         "active":"on",
         "author":"admin"
    }
   "limit":"10",
   "sort":"data:d"
}'>
<li>{{datetime}}: {{header}}<br>{{short_text}}</li>
</ul>

Comments

[Denis]

Если говорить конкретно о php то для таких вещей пишут функционал виджет, где выборка происходит в php файле а в шаблоне только нативный для шаблона цикл отображения информации.
далее виджет "регистрируется" в системе и вызывается в нужном шаблоне.
Я понимаю что щас все умные, но с каких делов верстальщик должен знать sql, у него и так голова забита всякими less, sass, npm, js и тд.

Answer 5

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

Все зависит от проекта и сложности бизнеслогики на нём и от уровня разработчиков. Я в бородатые годы экспериментировал с активными шаблонами, они отлично себя показывали на всяких блогах-визитках и городских порталах.
Приятно было под пивко за вечерок с клиентом собрать проект. А сейчас ERP системы, где только система прав доступа требует человекомесяц, интересно, но геморно, тут активные шаблоны не зайдёт, да и шаблонов в глаза не видел лет пять, rest api и т.д.