Помимо стандартных концепций OO, каковы некоторые другие стратегии, которые позволяют создавать хороший, чистый PHP-код, когда среда не используется?
Помните: MVC, OOP и уровни – это концепции дизайна, а не языковые конструкции, а также структурирование файлов.
Для меня это означает, что, когда вы не используете фреймворк и когда нет разных команд для программирования и проектирования; нет смысла использовать другую систему шаблонов поверх PHP (это язык шаблонов). Кроме того, разделение кода от макета не обязательно означает выполнение его в разных файлах.
Так я использовал для разовых, редко расширяемых веб-приложений PHP:
это ваша «структура», затем вы пишете слой «презентация»:
один PHP-файл для каждой страницы, начинается с некоторого простого кода для извлечения необходимых объектов, а затем с помощью HTML-кода с интерспективным кодом PHP, чтобы «заполнить отверстия». за очень немногими исключениями, самый сложный код должен быть для циклов. Я делаю правило использовать только однострочные, то ?> Должен быть в той же строке, что и открытие <?php
вот и все. Если вы работаете в одиночку, у вас есть все разделение намерений, в которых вы нуждаетесь, без утопления в большом количестве файлов для одного действия пользователя. Каждая страница, которую видит пользователь, управляется одним файлом PHP.
Его даже легко поддерживать, через несколько месяцев, не глядя на код, так как легко протестировать приложение, принимая во внимание имена файлов в поле URL-адреса браузера. Это направляет вас непосредственно на соответствующий код.
(в настоящее время, конечно, я использую Django для почти всего …)
Если вы когда-либо находите смешение HTML и кода, просто остановитесь. Ты, ну … Ты делаешь это неправильно! http://img.ruphp.com/php/logo_huge_domains.gif
Я бы сказал почти так же, как и для любого другого языка:
На самом деле этот вопрос довольно языковой агностик, поскольку он применим к большинству языков, на которых вы решили «бросить свои собственные». Два предложения, которые я хотел бы сделать, были бы следующими:
Во-первых, просто потому, что вы не используете фреймворк, не означает, что вы не можете использовать шаблоны для разделения кода. Шаблон MVC – это минимум, который вы должны учитывать при организации исходного кода – он упрощает и упрощает сбор исходного кода, даже если приложение не полностью следит за процессами маршрутизации, связанными с фреймворками, с кодом, который " «вещи, отделенные от того, что« представляет »вещи, очень полезны.
Во-вторых, только потому, что вы решили не использовать полную фреймворк, это не значит, что вам нужно изобретать колесо. Используйте специально подготовленные библиотеки для решения конкретных проблем. Двумя хорошими примерами были бы кадровая структура (log4php) и решение для визуализации / шаблонирования интерфейса (Smarty).
Держитесь подальше от глобалов как можно лучше 😀
Если вы действительно придерживаетесь концепций OO, таких как разделение проблем, ваш код будет довольно хорошим, но вот несколько советов:
обязательно соблюдайте стандартные методы разделения проблем. Это означает, что вы не должны смешивать свой бизнес и уровень данных с вашим пользовательским интерфейсом.
Даже если вы не используете фреймворк, используйте механизм шаблонов. Используя шаблоны, вы разделите логику и презентацию своего приложения. Затем создавайте, кодируйте и форматируйте логическую часть, как то, что вы будете делать с любым другим языком. Сделать «дизайнеры» дизайн пользовательского интерфейса 🙂
OO не является строго необходимым: можно было писать хороший код в PHP <5 тоже. Хороший процедурный код, хорошо разделенный на файлы и каталоги «логическим расстоянием», должен также держать вас в безопасности. Обратите внимание, однако, как это начинает напоминать OO издалека.
Лучше всего было бы быть последовательным: я видел проект, в котором Smarty использовался на большинстве страниц, кроме одного – самого сложного, идущего фигуры.
Воспользуйтесь встроенными расширениями PHP – например, MySQLi. Поскольку они становятся более объектно-ориентированными, требования к структурам становятся меньше.
Например, я мог бы создать полезный TwitterApp, используя следующие расширения и без реальной структуры, кроме основного класса, чтобы связать экземпляры вместе.
Мне может понадобиться сделать несколько вспомогательных классов для таких вещей, как «Вход», но мои обычные пары классов (DAL и TPL) устарели двумя хорошо обработанными расширениями.
