PHP: дилемма дизайна кода - PullRequest
0 голосов
/ 22 ноября 2010

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

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

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

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

Теперь у класса контроллера есть открытые методы, соответствующие частям удобных для пользователя (или, возможно, оптимизированных для SEO) 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();

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

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

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

Недостатки

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

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

EDITED Уточнение вопроса:

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

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

1 Ответ

0 голосов
/ 22 ноября 2010

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

...