Использовать представления или не использовать представления
Прямо сейчас я, кажется, вовлечен в дискуссию с другим программистом по этому проекту, который считает, что представления не имеют достоинств. Он предлагает систему, в которой PHP выглядит примерно так:
$draw = new Draw;
$nav = $draw->wideHeaderBox().
$draw->left().
$draw->image().
Image::get($image,60,array('id'=>'header_image')).
$draw->imageEnd().
$draw->leftEnd().
$draw->left(10).
'<div id = "header_text">'.
self::defaultSectionText().
'</div>'.
$draw->leftEnd().
и так далее (это кстати в контроллере). Теперь его аргументы в пользу этого на самом деле имеют некоторый смысл, он утверждает, что если есть редизайн, все, что нам нужно сделать, это изменить HTML в одном месте, и он изменится везде автоматически. Однако по какой-то причине этот метод до сих пор меня не устраивает, есть ли заслуги во взглядах на этот метод? Я имею в виду, кроме того, что вам не нужно повторно набирать HTML вручную.
Ответы 5
Аргумент, который он использует, - это аргумент, который вам нужен для представлений имеют. Оба результата меняют его только в одном месте. Однако в его версии вы смешиваете разметку представления с бизнес-кодом.
Я бы посоветовал использовать более шаблонный дизайн. Выполните всю свою бизнес-логику на PHP, настройте все переменные, которые необходимы вашей странице. Затем просто укажите в разметке вашей страницы ссылки на эти переменные (и вообще не работайте с бизнес-логикой).
Вы смотрели на умники? http://smarty.php.net
Я делал что-то подобное в прошлом, и это было пустой тратой времени. Например, вам в основном нужно писать оболочки для всего, что вы уже умеете с HTML, и вы БУДЕТЕ кое-что забыть. Когда вам нужно что-то изменить в макете, вы подумаете: «Блин, я забыл об этом ... теперь мне нужно закодировать другой метод или добавить еще один параметр».
В конечном итоге у вас будет огромная коллекция функций / классов, генерирующих HTML, которые никто не узнает или не вспомнит, как использовать через несколько месяцев. Новые разработчики будут проклинать вас за использование этой системы, поскольку им придется изучить ее, прежде чем что-либо менять. Напротив, больше людей, вероятно, знают HTML, чем ваши абстрактные классы рисования HTML ... и иногда вам просто нужно запачкать руки чистым HTML!
Это выглядит довольно многословно, и, честно говоря, трудно следовать, а некоторые части кода выглядят так, будто это очень много информации о макете.
Мы всегда стараемся максимально отделить логику от вывода. Однако часто бывает, что представление и данные очень тесно связаны с обеими частями, определяя, как должна быть другая (например, на простом сайте электронной коммерции вы можете решить, что хотите начать показывать уровни запасов рядом с каждым продуктом. , что, очевидно, потребует изменения представления, чтобы добавить соответствующий html для этого, и бизнес-логику, чтобы найти значение для акций).
Если мысль о поддержке двух файлов для этого слишком сложна, попробуйте разделить все на часть «Сбор данных» и часть «Отображение», чтобы получить большинство преимуществ без увеличения количества файлов, которыми вам нужно управлять. .
HTML-средства экономии времени полезны, но они полезны только тогда, когда они интуитивно понятны и просты для понимания. Создание экземпляра new Draw звучит не очень естественно. Кроме того, wideHeaderBox и left будут иметь значение только для тех, кто хорошо знаком с системой. А что, если будет редизайн является, как размышляет ваш коллега? Что, если wideHeaderBox станет очень узким? Вы измените разметку (и, предположительно, стили), сгенерированную методом PHP, но оставите очень неточное имя метода для вызова кода?
Если вы, ребята, просто используете имеют, чтобы использовать генерацию HTML, вы должны использовать его вкрапления в файлы просмотра, и вы должны использовать его там, где это действительно необходимо / полезно, например, примерно так:
HTML::link("Wikipedia", "http://en.wikipedia.org");
HTML::bulleted_list(array(
HTML::list_item("Dogs"),
HTML::list_item("Cats"),
HTML::list_item("Armadillos")
));
В приведенном выше примере имена методов действительно имеют смысл для людей, которые не знакомы с вашей системой. Они также будут иметь больше смысла для вас, ребята, когда вы вернетесь к редко посещаемому файлу и задаетесь вопросом, какого черта вы делаете.
Мне всегда намного проще работать напрямую с html. На один уровень абстракции меньше (html -> фактическая веб-страница / функция php -> html -> фактическая веб-страница), с которой нужно работать, тогда вы просто работаете в HTML.
Я действительно думаю, что фраза «просто нужно поменять это в одном месте» в этом случае не сработает. Это потому, что они будут очень много раз, когда вы захотите изменить вывод функции, но только в одном месте. Конечно, вы можете использовать аргументы, но вскоре вы получите некоторые функции, имеющие около дюжины аргументов. Фу.
Имейте в виду, что языки / системы шаблонов часто позволяют включать подшаблоны, что позволяет иметь несколько многократно используемых блоков html.
Суть в том, что если бы я только начинал в вашей компании и видел повсюду такой код, моей первой мыслью было бы: «Черт возьми! Снова нужна новая работа ».