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

Question

Пожалуйста, поделитесь своими любимыми шаблонами дизайна/дизайна приложений для использования со мной в PHP. Некоторые вещи, которые я хотел бы знать:

• Как ваши папки предназначены
• Как использовать объект oritentation в ваших PHP приложений
• У вас есть стандартный способ борьбы с CRUD, пагинацией, или любой другие общие задачи?
• Как избежать использования повторяющегося кода? Каков ваш подход к библиотекам/общий код и т. Д.?
• Каким образом вы можете сделать свой код более элегантным?

Вам не обязательно отвечать на все эти вопросы, ответы на любые или некоторые из них будут полезны.

Причина, по которой я прошу об этом, заключается в том, что я очень устал писать повторяющийся, уродливый код на PHP, и я хочу создать небольшую основу для своих проектов фриланса, которые упростят программирование и позволят мне сосредоточиться на сложные или деловые задачи, а не форма проверки, разбиение на страницы и другие мирские действия, которые составляют 80% работы по программированию в PHP

Все мнения оценены!

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

Я должен согласиться с вышеуказанными плакатами. Если вы не используете фреймворк при программировании на 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 имеет библиотеку постраничную, и она имеет 3-библиотеки, как DataMapper для упаковки ваших CRUD звонков в ориентированном образом объекта (ОРМ).

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

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

(В 2 вопроса я не ответил довольно много подразумевается при использовании рамки)

Answer 6

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

Answer 7

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

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

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

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

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

Answer 8

Использование 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, i.e. doctrine-cli) 
    vendor   (zend and doctrine libraries, preferably as svn-externals) 

Answer 9

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

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

И, таким образом, я отказался от написания своего собственного любимого толпы: Zend.

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

MVC - это также способ, которым я буду двигаться вперед с тем, что я пишу сейчас.