Как вы пишете хороший PHP-код без использования фреймворка?

Помимо стандартных концепций OO, каковы некоторые другие стратегии, которые позволяют создавать хороший, чистый PHP-код, когда среда не используется?

Помните: MVC, OOP и уровни – это концепции дизайна, а не языковые конструкции, а также структурирование файлов.

Для меня это означает, что, когда вы не используете фреймворк и когда нет разных команд для программирования и проектирования; нет смысла использовать другую систему шаблонов поверх PHP (это язык шаблонов). Кроме того, разделение кода от макета не обязательно означает выполнение его в разных файлах.

Так я использовал для разовых, редко расширяемых веб-приложений PHP:

  1. напишите файл «общие утилиты», там я помещаю некоторые функции форматирования / дезинфекции, а также несколько функций доступа к БД:
    1. getquery (): с учетом SQL возвращает объект результата
      • getrecord (): с учетом SQL возвращает объект записи (и закрывает запрос)
      • getdatum (): с учетом SQL возвращает одно поле (и закрывает запрос)
      • поместите все конфигурации (доступ к БД, некоторые префиксы URL и т. д.) в файле «config.php»
      • напишите слой модели, либо один файл, либо один для каждого объекта, который вы храните в БД. Там будут все константы SQL, представлены API более высокого уровня, основанные на ваших концептуальных объектах, а не на записях БД.

это ваша «структура», затем вы пишете слой «презентация»:

  1. один PHP-файл для каждой страницы, начинается с некоторого простого кода для извлечения необходимых объектов, а затем с помощью HTML-кода с интерспективным кодом PHP, чтобы «заполнить отверстия». за очень немногими исключениями, самый сложный код должен быть для циклов. Я делаю правило использовать только однострочные, то ?> Должен быть в той же строке, что и открытие <?php

    • каждая форма ввода данных должна указывать на небольшой PHP без какого-либо HTML-кода, который просто получает данные POST, входит в БД и пересылается на вызывающую страницу.

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

Его даже легко поддерживать, через несколько месяцев, не глядя на код, так как легко протестировать приложение, принимая во внимание имена файлов в поле URL-адреса браузера. Это направляет вас непосредственно на соответствующий код.

(в настоящее время, конечно, я использую Django для почти всего …)

Если вы когда-либо находите смешение HTML и кода, просто остановитесь. Ты, ну … Ты делаешь это неправильно! http://img.ruphp.com/php/logo_huge_domains.gif

Я бы сказал почти так же, как и для любого другого языка:

  • Не оптимизировать преждевременно
  • Поддерживайте методы небольшими
  • Практика DRY
  • Практическое программирование на основе данных
  • Используйте разумные ярлыки (например, тернарный оператор)
  • Отформатируйте свой код так, чтобы его могли понять другие
  • Не используйте OO вслепую
  • Всегда проверяйте коды возврата для ошибок
  • Включите самый высокий уровень предупреждения и убедитесь, что ваш код не вызывает никаких предупреждений
  • Будьте очень осторожны, когда дело доходит до ввода вопросов (это касается всех слабо типизированных языков). Оператор '===' – ваш друг.

На самом деле этот вопрос довольно языковой агностик, поскольку он применим к большинству языков, на которых вы решили «бросить свои собственные». Два предложения, которые я хотел бы сделать, были бы следующими:

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

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

Держитесь подальше от глобалов как можно лучше 😀

Если вы действительно придерживаетесь концепций OO, таких как разделение проблем, ваш код будет довольно хорошим, но вот несколько советов:

  • Рамки или нет, используйте MVC.
  • Я не могу подчеркнуть, насколько важно никогда не смешивать вашу логику с вашим HTML. В HTML-файле PHP следует использовать только как язык шаблонов и не более того.
  • Используйте DBAL.
  • Отделите свой дизайн от своего контента. Общим методом для этого является использование CSS в значительной степени и наличие файлов заголовков и нижних колонтитулов, содержащих основную часть макета сайта.
  • Имейте один файл для констант параметров, таких как учетные данные БД, учетные данные FTP и т. Д.

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

Даже если вы не используете фреймворк, используйте механизм шаблонов. Используя шаблоны, вы разделите логику и презентацию своего приложения. Затем создавайте, кодируйте и форматируйте логическую часть, как то, что вы будете делать с любым другим языком. Сделать «дизайнеры» дизайн пользовательского интерфейса 🙂

OO не является строго необходимым: можно было писать хороший код в PHP <5 тоже. Хороший процедурный код, хорошо разделенный на файлы и каталоги «логическим расстоянием», должен также держать вас в безопасности. Обратите внимание, однако, как это начинает напоминать OO издалека.

Лучше всего было бы быть последовательным: я видел проект, в котором Smarty использовался на большинстве страниц, кроме одного – самого сложного, идущего фигуры.

Воспользуйтесь встроенными расширениями PHP – например, MySQLi. Поскольку они становятся более объектно-ориентированными, требования к структурам становятся меньше.

Например, я мог бы создать полезный TwitterApp, используя следующие расширения и без реальной структуры, кроме основного класса, чтобы связать экземпляры вместе.

  • MySQLi для базы данных (PDO, если вам нужен DAL)
  • SimpleXML для чтения RSS / API
  • Smarty для шаблонов

Мне может понадобиться сделать несколько вспомогательных классов для таких вещей, как «Вход», но мои обычные пары классов (DAL и TPL) устарели двумя хорошо обработанными расширениями.