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

Ответ 1

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

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

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

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

что ваша "структура", тогда вы пишете слой "presentation":

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

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

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

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

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

Ответ 2

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

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

Ответ 3

Если вы когда-либо находите смешение HTML и кода, просто STOP. Ты в порядке... Ты делаешь это неправильно! http://dennisjudd.com/albums/cute_cats/wrong_mike.jpg

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

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

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