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

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

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

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

• Обеспечение безопасности Ваш главный приоритет – если вы пишете уровень доступа к данным, используйте связанные параметры. Если вы пишете класс формы, предостерегайте CSRF и XSS. Поймайте свои исключения и обработайте свои ошибки. Убедитесь, что ваша среда PHP защищена. Не пытайтесь придумать свой собственный алгоритм шифрования. Если вы не концентрируетесь на безопасности, не стоит писать собственные рамки.
• Комментируйте свой код – вам понадобятся комментарии, которые помогут вам вспомнить, как работает ваш код через некоторое время. Я обычно считаю, что комментариев в докблоке более чем достаточно. Помимо этого, прокомментируйте, почему вы что-то сделали, а не то, что вы сделали. Если вам нужно объяснить, что вы, возможно, захотите реорганизовать.
• Отдельные классы и методы ответственности. Большинство ваших классов и методов должны делать одно и только одно. Особенно следите за этим с помощью базы данных. Ваш класс разбиения на страницы не должен полагаться на ваш объект доступа к данным и не должен быть почти любым другим (низкоуровневым) классом.
• Единичный тест. Если каждый из ваших методов выполняет только одну вещь, им будет намного легче протестировать их, и это приведет к лучшему коду. Сначала напишите тест, затем код, чтобы пройти тест. Это также даст вам большую свободу реорганизовать позже, не нарушая что-то.
• Абстрактные аналогичные классы. Если у вас есть несколько классов, которые делают подобные вещи, создайте родительский класс, который использует сходства между классами и расширяет его.
• Делегирование и модуляция – если вы пишете систему проверки (и, скорее всего, вы, вероятно, захотите), не включайте каждый валидатор в качестве метода в некоторый класс супер-проверки. Разделите их на отдельные классы и вызовите их по мере необходимости. Это можно применять во многих областях: фильтры, языки, алгоритмы, валидаторы и т. Д.
• Защита и приватизация. В большинстве случаев лучше использовать методы getter и setter, а не предоставлять прямой доступ к переменным класса.
• Согласованный API. Если у вас есть метод render () и метод draw (), которые выполняют одни и те же действия в разных классах, выберите один и пойдите с ним по всем классам. Сохраняйте порядок параметров одинаковым для методов, которые используют одни и те же параметры. Согласованный API – это более простой API.
• Помните автозагрузку . Имена классов могут стать немного неуклюжими и длинными, но то, как Zend называет классы и организует каталоги, упрощает автозагрузку. Обновление . Начиная с PHP 5.3, вы должны начать использовать пространства имен.
• Никогда не эхо или ничего не печатайте. Дайте ему как возвращаемое значение и дайте возможность пользователю решить, следует ли его повторять. Много раз вы будете использовать возвращаемое значение в качестве параметра для другого метода.
• Не пытайтесь решать мировые проблемы. Решите свои собственные. Если вам сейчас не нужна функция, например класс для локализации чисел или дат или валюты, не пишите. Подождите, пока это вам не понадобится.
• Do not Preoptimize – Создайте несколько простых приложений с вашей инфраструктурой, прежде чем настраивать их. В противном случае вы можете потратить много времени ни на что полезное.
• Используйте Source Control – Если вы проводите бесчисленные часы, создавая шедевр, не рискуйте потеряться.

Я должен согласиться с вышеупомянутыми плакатами. Если вы не используете фреймворк при программировании на PHP, вы действительно программируете руками, связанными за спиной. Я лично рекомендую CodeIgniter . Это самая быстрая структура, она очень проста в обучении и имеет очень активное сообщество. На все ваши вопросы ответят рамки:

* How your folders are designed 

CodeIgniter (или любая инфраструктура в этом отношении) отделяет вашу логику от представлений, моделей и контроллеров, каждая из которых имеет свою собственную папку.

 * Do you have a standard way of dealing with CRUD, pagination, or any other common tasks? 

CI имеет библиотеку разбиения на страницы, и у нее есть сторонние библиотеки, такие как DataMapper для обертывания вызовов CRUD объектно-ориентированным способом (ORM).

 * What are ways in which you can make your code more elegant? 

Разделение модели, представления и контроллера делает очень элегантный код.

(2 вопроса, на которые я не ответил, в значительной степени подразумеваются при использовании фреймворка)

Я предполагаю, что многие разработчики php следовали аналогичному маршруту: мои скрипты -> процедурный / встроенный код -> возможно, посмотрите на templating -> OOP -> затем фреймворк. Я думаю, что разработчик PHP может довольно часто «взрослевать» с PHP, изучая шаблоны проектирования, чтобы соответствовать функциям, доступным в текущей версии.

MVC является наиболее часто используемым шаблоном проектирования в популярных системах, используемых сегодня. CakePHP – моя выборка, хотя симфония и Zend тоже очень популярны – стоит попробовать несколько, и вскоре станет очевидно, с чем вы чувствуете себя наиболее комфортно.

Для большинства проектов (где быстрое развитие и переносимый код являются приоритетами) я использую Cake, однако для приложений с небольшим весом (один из которых я недавно разработал Good Baad ), который вы хотели бы быстро запускать (на оборудовании с низким спектром) и не нуждаетесь объем / вес, добавленный функциональностью одной из больших фреймворков, я рекомендую прочитать статью Расмуса Лердорфа о своей инфраструктуре No Framework PHP MVC .

В принципе, если вы после истинного объектно-ориентированного языка, который поощряет красивый код и лучшие методы проектирования, PHP всегда будет проигрывать подобным Ruby Python и C #. Но у PHP есть свои сильные стороны, например, нет необходимости в языке шаблонов (он один), PHP может работать очень быстро и дешево и не нуждается в весе большой структуры для всех приложений.

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

Я почти чувствую себя сломанной записью, но я бы рекомендовал вам взглянуть на некоторые общие рамки по двум причинам:

1. Даже если вы решите не использовать их, некоторые из них очень хорошо написаны и очень хорошо разработаны. Мне особенно нравится Zend Framework, но я вернусь к этому через секунду.
2. Спросите себя, почему вы изобретаете колесо. Вы действительно чувствуете, что понимаете те же проблемы с дизайном, с которыми все остальные сталкиваются намного лучше, чем сообщество (вставить рамки выбора здесь), чтобы оправдать написанное что-то с нуля? Выступая в качестве одного из тех, кто первоначально смотрел на несколько рамок и решил, что они слишком большие, слишком много излагает кривую обучения или слишком много накладных расходов и так развивается, я могу сказать, что писать свои собственные с нуля – большая боль, если вы может просто использовать существующую, которая может быть легко расширена.

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

Я обнаружил, что Zend Framework настолько полностью гибкая, что я запускаю один веб-сайт как часть Zend Framework MVC, а также часть моей старой дерьмовой структуры и даже более старого кода crappier, который я еще не переписал. Фактически, поскольку во время нашей перезаписи мы обнаружили одну страницу, которая была неприемлемо медленной с использованием старой структуры, я включил одну страницу для работы под архитектурой Zend Framework.

Чтобы ответить на некоторые из ваших вопросов, я бы рекомендовал вам изучить шаблоны архитектуры корпоративных приложений Мартина Фаулера. Он дает много полезной информации о том, как решить ряд таких распространенных проблем, как создать слой взаимодействия с базой данных в приложении. Фаулер также охватывает такие темы, как MVC и Front Page Controller.

Я объяснил большую часть моей методологии PHP здесь .

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

Я начал работать с моделями шаблонов шаблонов, когда мне сначала надоело смешивать код и html. После хакинга какое-то время я понял, что писать собственные рамки – это просто дублирование работы.

Я сделал несколько проектов с Joomla , который действительно является CMS, но он дает клиентам большой контроль над контентом.

В конечном итоге я решил использовать реальные рамки для своих проектов. Я использую symfony , который вдохновлен Rails и очень хорошо документирован, но я слышал, что cakePHP и ZendFramework также очень хороши.

Я использую Zend Framework, который в значительной степени определяет расположение папок и OOP (парадигма MVC). Для обычных задач, например, для разбивки на страницы, я использую Zend_Paginator (мои классы модели реализуют Zend_Paginator_Adapter_Interface ), для проверки я использую классы Zend_Validate и т. Д. Благодаря этому я могу полностью сконцентрироваться на бизнес-логике, а не изобретать колесо.

Используя Zend Framework и Doctrine , моя структура папок обычно выглядит так:

 root app config (db config, routing config, misc config) doctrine (fixtures, migrations, generated stuff, etc) lib logs models (doctrine models) modules (zend mvc modules) bootstrap.php docs (db diagrams, specs, coding standards, various docs) pub (web root) tests tools (console tools, ie doctrine-cli) vendor (zend and doctrine libraries, preferably as svn-externals) 

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

И затем приходит часть, где я прихожу к осознанию того, что я делаю что-то правильно.

И как таковой я отказался от написания своего собственного фильма с любимой толпой: Zend.

Я смотрел на других, но кажется, что Зенд был вокруг, и они знают свои вещи.

MVC также является тем, как я продвигаюсь вперед с тем, что я пишу сейчас.