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

Question

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

Answer 1

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

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

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

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

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

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

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

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

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

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

Answer 2

Если вам когда-нибудь придется смешивать HTML и код, просто ОСТАНОВИТЕСЬ. Ты в порядке... Вы делаете это неправильно! http://dennisjudd.com/albums/cute_cats/wrong_mike.jpg

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

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

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

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

Answer 9

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

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

Answer 10

Даже если вы не используете фреймворк, используйте шаблонизатор. Используя шаблоны, вы отделите логику и представление вашего приложения. Затем проектируйте, кодируйте и форматируйте логическую часть так же, как вы делали бы это на любом другом языке. Сделайте дизайн "дизайнеров" пользовательским интерфейсом:)