Нет прямого ответа на ваш вопрос, но есть пища для размышлений.
Отделение концернов
Вы можете подумать, можете ли вы разделить свою логику бизнеса и логику компоновки. Часто использование шаблонизатора может сильно помочь в этом. У меня был положительный опыт, например, с Twig или Smarty (некоторое время назад я не был уверен, как они себя сейчас оценивают). Это требует от вас написания кода (менее линейным), но более логичным.
Типичным примером ООП-подобного разделения интересов может быть что-то вроде этого:
$this->setParam('Myparam','myvalue');
if ($this->isAjax())
{
$this->setTemplate('ajax.php');
$this->setLayout(false);
} else {
$this->setTemplate('normal.php');
$this->setLayout('Mylayout');
}
return $this->render();
Это образная ситуация, которая встречается во многих MVC, таких как приложения и фреймворки. Основная идея заключается в том, что у вас должна быть возможность отделить макет от ваших данных. Я бы посоветовал взглянуть на некоторые современные фреймворки для вдохновения (такие как symfony, codeigniter, zend framework).
Глоссарий / Часто применяемые концепции в отделенном PHP-приложении
Вот краткий список понятий, которые можно использовать.
Пример mvc в php: http://www.phpro.org/tutorials/Model-View-Controller-MVC.html
Примечание: мне не очень нравится реализация. Я гораздо больше предпочитаю существующие рамки. Мне нравится объяснение всего этого урока. Например. для меня эта ссылка для обучения, а не для реализации.
Silex
Для простого развязанного php-микро-фреймворка я бы по-настоящему порекомендовал Silex, созданный Symfony2. Его легко реализовать и изучить, но он содержит в себе основные понятия, описанные здесь; и использует все вкусности php 5.3+, такие как пространство имен и замыкания.
см .: http://silex.sensiolabs.org/
Шаблон FrontController
Только один и только одна точка входа для вашего кода. У меня обычно только один и только один пункт в вашей заявке. Обычно фронт-контроллер «отправляет» запрос остальной части приложения
http://en.wikipedia.org/wiki/Front_Controller_pattern
Маршрутизация
Система маршрутизации часто используется в сочетании с шаблоном фронт-контроллера. Это в основном описывает, какой URL подключен к какому модулю / контроллеру. Это позволяет вам изменять способ доступа людей к вашему приложению без изменения URL.
См .: https://stackoverflow.com/questions/115629/simplest-php-routing-framework
Контроллер
Контроллер - это место, где применяется логика бизнеса. Получение данных из базы данных, проверка привилегий, настройка шаблона, настройка макета и т. Д. (Хотя это также перемещается за пределы контроллера, если он становится слишком большим из-за отдельной проблемы).
Модель
Модель в основном представляет собой уровень, в котором используется управление вашей базой данных. Это может быть простой класс, куда вы перемещаете все свои функции mysql_ *, или это может быть полнофункциональный ORM. Основная философия заключается в том, что вся логика, связанная с извлечением и размещением информации в базе данных, разделена.
Один шаг вверх: ORM
В приложениях часто используются методы объектно-реляционных моделей, которые сопоставляют записи SQL с объектами PHP. Doctrine и Propel - две из этих хорошо проработанных библиотек. Я сильно полагаюсь на эти системы в своем развитии. В этом смысле часть доктрины или движущей силы будет представлять модельный слой.
Вид:
Представление обычно состоит из шаблонизатора. Некоторые используют обычный PHP в качестве шаблона, другие, такие как Symfony, создают отдельную область, в которой размещаются переменные. Есть много дискуссий и мнений о том, что лучше, один прямо здесь на stackoverflow:
Мне нравятся:
- Веточка: http://twig.sensiolabs.org/
- sfTemplate: http://components.symfony -project.org / templating /
- Smarty: http://components.symfony -project.org / templating /
Разъединяющие механизмы:
Системы, основанные на событиях
Использование событий в вашем может помочь отделить код. Например, если вы хотите отправить электронное письмо после сохранения записи, события - хорошее решение для этого; в общем, модель не должна знать об электронной почте. Таким образом, события являются способом их подключения: вы можете позволить вашему -email-send-class прослушивать определенные записи, чтобы они могли отправлять правильные электронные письма. (Возможно, вы захотите, чтобы ваши электронные письма отправлялись с вашего контроллера, это, вероятно, дело вкуса).
Инъекция зависимости
При использовании ООП-кода в PHP многие полагались на использование одноэлементных классов (конфигурация и т. Д.). С точки зрения ООП, это может считаться плохим, потому что это сложно проверить, и не так уж и элегантно иметь такие зависимости. Внедрение зависимостей - это паттерн, пришедший из Java и теперь используемый в более новых средах для решения этой проблемы. Может быть немного сложно обернуть голову, но вы увидите, что это возвращается в нескольких новых рамках.
Внедрение зависимостей в php: Внедрение зависимостей в PHP 5.3
рамочные:
Многие из этих методов трудны, или много работы, чтобы реализовать себя. Многие будут жить в рамках этого. Вы можете или не можете нуждаться в структуре. Вы можете или не можете хотеть для вас рамки, это ваш выбор. Но все же полезно узнать, как это делают фреймворки, а не пытаться изобретать велосипед самостоятельно.
Фреймворки php без фреймворка: https://stackoverflow.com/questions/694929/whats-your-no-framework-php-framework
Хорошие привычки: https://stackoverflow.com/questions/694246/how-is-php-done-the-right-way
Фреймворки, на которые стоит обратить внимание (imho): CodeIgniter, Kahona, CakePHP, Symfony (1.4 / 2.0), Silex, Zend Franework, Yii. Их намного больше, каждый со своими преданными поклонниками и ненавистниками.