2010-11-22 3 views
0

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

Итак, у меня есть это PHP приложение построить на вершине моего собственный MVC-ориентированный фреймворк (да, я сделал свой собственный, вместо того, чтобы использовать существующий). И это делается книгой, поэтому у нас есть модель (обработка данных и базы данных), просмотр (шаблоны, заполненные данными и визуализацией вывода), и контроллер (обрабатывает запросы, получает соответствующие данные из модели, помещает данные в представление). Классический и скучный сценарий с маршрутизацией запроса, выполненной с помощью правил .htaccess.

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

Я подумываю о нарушении моего класса контроллера во многих классах, каждый из которых обрабатывает только один тип запроса, например, login или register или showProfile или killMe.

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

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

Например, для URL = "www.example.com/users/login" теперь выглядит следующим образом:

$controller = new url[0](); 
$method = url[1]; 
echo $controller->$method(); 

и теперь URL изменится на "www.example.com/login" и код маршрутизации будет выглядеть так:

$controller = new url[0](); 
controller->Execute(); 

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

Какие преимущества я вижу в этих изменениях?

  • один специальный класс за один запрос
  • файлов меньшего размера
  • меньше коды
  • проще обслуживание
  • ограниченной опасность разрыва работает контроллер при добавлении новых возможностей (новые типов запроса) или исправления ошибок

Недостатки?

  • возможно много классов
  • возможно исполнение ударил
  • ???

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

EDITED Разъяснение вопроса:

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

Теперь у меня есть контроллер Пользователи, которые обрабатывают запросы типа «login», «showLoginForm», «register», «activate» и т. Д. Реализованный код будет состоять из отдельных контроллеров для каждого из этих запросов.

+0

Вы спрашиваете, должен ли ваш [FrontController] (http://martinfowler.com/eaaCatalog/frontController.html) вызывать [Сценарии транзакций] (http://martinfowler.com/eaaCatalog/transactionScript.html) или методы в a [PageController] (http://martinfowler.com/eaaCatalog/pageController.html) или что-то еще? Я не совсем понимаю, что именно вы ищете. – Gordon

+0

Я добавил некоторое объяснение, о чем я спрашиваю :) – grapkulec

ответ

0

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

+0

хорошая точка. Я, вероятно, должен подумать об отделении URL-адресов от фактического кода, который их обрабатывает, текущее сопоставление не очень гибкое. – grapkulec

+0

Я принимаю этот ответ, потому что это именно то, что я сделал в своем коде, и он решил все мои сомнения и проблемы, которые у меня были, когда я был пишущий этот вопрос :) – grapkulec

Смежные вопросы