PHP: Разделите бизнес-логику и презентационную логику, стоит ли это?

Возможный дубликат:
Почему я должен использовать систему шаблонов в PHP?

Мне было просто интересно, сколько разработчиков на самом деле это делают?

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

У кого-нибудь есть опыт работы с шаблонами? Каковы ваши чувства к ним? Являются ли полезными большие проекты или просто пустая трата времени?

На стороне примечание: компания, в которой я работаю, не имеет дизайнера, в этом проекте работают только два разработчика, обвиненные в перепроектировании / обновлении. Я также использую немного AJAX, будет ли это иметь проблемы с движком шаблонов?

Эта практика не только делает код более чистым, но также имеет много долгосрочных и краткосрочных преимуществ.

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

Использование систем шаблонов и фреймворков значительно облегчит выполнение задач. Существует правильное правило, которое вы можете выполнить, которое является СУХОЙ (не повторяйте сами). Рамки помогают вам достичь этой цели.

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

Я обнаружил, что Code Igniter довольно прост в использовании, и у них есть некоторые ОЧЕНЬ полезные видеоуроки на их веб-сайте.

Удачи!!

На самом деле бизнес-логика должна быть отделена от представлений. Вы можете использовать php как «язык шаблонов» внутри представлений.

Думаю, вы можете использовать ajax для любого механизма шаблонов.

редактировать

В моем первоначальном ответе был рассмотрен вопрос о том, использовать ли механизм шаблона или нет для генерации вашего html.

Я утверждал, что php достаточно хорош для задач шаблона, если вы отделяете бизнес-логику от логики представления.

Это стоит сделать даже для простых страниц, потому что это позволяет вам:

  • изолируйте код, который является мозгом вашего приложения, от кода, который является лицом , и поэтому вы можете изменить лицо, не вникая в мозг, или вы можете улучшить мозг без торможения внешнего вида
  • изолировать 80% ошибок в 20% вашего кода
  • создавать повторно используемые компоненты: вы можете присвоить другой код презентации тому же бизнес-коду и наоборот;
  • отдельные проблемы запросов функций (бизнес-кода) от проблем запросов на дизайн (код представления), которые также обычно связаны с разными людьми на стороне клиента, а разные люди со стороны подрядчика
  • использовать разных людей для написания бизнес-кода и кода презентации; вы можете заставить дизайнера непосредственно обрабатывать код презентации с минимальным знанием php;

Простым решением, которое имитирует MVC и не использует объекты, может быть:

  • используйте один php-файл контроллера, который получает все запросы через файл .httpdaccess;
  • контроллер решает, какой бизнес и код представления использовать, в зависимости от запроса
  • контроллер затем использует оператор include для включения бизнес-php-файла
  • бизнес-код делает его волшебным, а затем включает в себя файл php презентации

PHP это механизм шаблонов (или, если хотите, препроцессор гипертекста). Когда HTML сильно смешивается с PHP-логикой, становится очень сложно поддерживать, поэтому у вас будут функции, определенные отдельно для создания различных частей и просто создайте страницу из коротких вызовов функций, встроенных в HTML. Сделано так, я не вижу большой разницы между Smarty и raw PHP, кроме выбора разделителей.

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

Код Ignitor, я нашел, был самым легким для изучения структуры для работы с PHP. Я в значительной степени начал свою текущую работу и работал с ней в течение нескольких дней, никогда не слышал об этом, чтобы использовать ее довольно эффективно. Я не вижу в этом другого языка. В принципе, использование структуры заставляет меня организовывать вещи управляемым образом, а добавленная функциональность является обязательной для использования плагинов и т. Д. Для jQuery или для импорта пакетов на Java. Мысль, что это похоже на изучение другого языка, кажется почти глупым.

Итак, короче, организуйте организовывать организацию. Имейте в виду, однако, что существует уровень абстракции, который просто становится абсурдным. Эмпирическое правило состоит в том, что класс (или файл в нашем случае) должен делать что-то очень хорошо. Это не значит, что это класс, который обертывает печать, но берет строку, форматирует ее с помощью сложного алгоритма и затем печатает ее (это всего лишь пример). Каждый класс должен делать что-то конкретное, и вы можете сделать это без каких-либо фреймворков. Что делает MVC отличным, тем не менее, это то, что он позволяет вам организовывать вещи дальше не только на уровне одного класса, но и на уровне «пакетов», являющихся Model, View и Controller (по крайней мере, в случае этих фреймворков; есть другие способы пакетных проектов). Итак, теперь у вас есть отдельные классы, которые хорошо работают, а затем вы группируете их с похожими классами, которые хорошо выполняют другие вещи. Таким образом, все поддерживается очень чисто управляемо.

Последний уровень, о котором нужно подумать, когда у вас есть вещи, организованные в классы, а затем пакеты, – это то, как эти классы получают доступ между пакетами. При использовании MVC доступ обычно будет проходить Model <-> Controller <-> View, тем самым отделяя модель (обычно это материал базы данных и «бизнес-код» в мире PHP), из представления (которое обычно принимает информацию из пользователь и передает его вместе с контроллером, который затем получит дополнительную информацию от модели, если это необходимо, или сделает что-то еще с входной информацией). Обычно контроллер работает как коммутатор между двумя другими пакетами. Опять же, есть другие способы пойти с упаковкой и т. Д., Но это общий путь.

Надеюсь, это поможет.

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

Я пишу в основном mod_perl в эти дни и начал использовать шаблоны (HTML :: Template) на полпути через наш текущий проект. Если бы мне пришлось принять решение снова, я бы использовал шаблоны с самого начала – переписывание позже для использования шаблонов – это утомительно, хотя и полезно, потому что вы получаете более чистый и чистый код. Для чего-то большего, чем 2-3 страницы в php, я бы также использовал некоторый механизм шаблонов.

Одним большим преимуществом шаблонизатора, такого как Smarty, является то, что не-разработчики могут использовать его для встраивания необходимой логики, которая используется в интерфейсе (на самом деле невозможно разделить логику и отображение на всех, кроме простейших сайтов). Однако, если разработчиком является тот, который поддерживает страницы, то использование PHP будет предпочтительным, на мой взгляд.

Если вы выделяете большие логические блоки и поддерживаете согласованный паттен для циклов и для каждого оператора управления потоком (т. Е. Не используйте заявления печати или используете только инструкции печати для однострочных и т. Д.). Тогда это должно быть хорошо.