Каковы преимущества и недостатки использования шаблона Front Controller? - PullRequest
9 голосов
/ 11 февраля 2009

В настоящее время я разрабатываю все свои сайты с файлом для каждой страницы, затем включаю общие элементы, такие как верхний и нижний колонтитулы и так далее. Однако я заметил, что многие фреймворки и CMS используют шаблон Front Controller.

Каковы преимущества и недостатки использования переднего контроллера? Этот шаблон просто используется в фреймворках и CMS, потому что неизвестно, какие страницы будут существовать в конечной системе?

Ответы [ 4 ]

11 голосов
/ 11 февраля 2009

Срикант имеет хороший ответ. Я хотел бы остановиться на альтернативе, хотя. Предположим, у вас есть такая простая иерархия URL:

/gallery
/blog
/admin/login
/admin/newpost

Если это реализовано с помощью контроллеров страниц (например, PHP), то и gallery.php, и blog.php должны будут включать немного common.php в начале (или рядом). Однако, и login.php, и newpost.php могут включать admin-common.php, который сам извлекает файл 'common.php' и выполняет настройку, специфичную для '/ admin /', например, проверку подлинности пользователя.

В общем случае, если у вас есть иерархия URL-адресов, в конечном итоге она выглядит как деревья наследования объектов. За исключением того, что вместо использования наследования на уровне языка вы наследуете окружение того, что foo-common.php вы включаете.

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

Одним из основных недостатков Page Controllers является то, что оно делает ваше веб-приложение зависимым от среды его размещения. Это также вынуждает ваших разработчиков «видеть» ту же структуру, что и конечные пользователи, но я считаю, что это хорошо, учитывая количество сайтов, на которых я вижу абсолютно ужасные URL.

9 голосов
/ 06 декабря 2010

Это причины, по которым я бы никогда не использовал фронт-контроллер.

  • У нас совершенно хороший фронт Контроллер его называется веб-браузером.
  • Каждый http-запрос является уникальным и отдельным и должен рассматриваться как таковой.
  • Невозможно масштабировать приложение с помощью фронтального контроллера.
  • Если вы разбиваете веб-приложение на небольшие, слабо связанные модули, проще протестировать модуль / модуль (например, вы не тестируете архитектуру, а также контроллер).
  • Производительность лучше, если вы имеете дело с единственным запросом однозначно.

Шаблон фронт-контроллера просто не подходит ИМХО. Создавайте приложения почти так же, как в UNIX, разбивайте большую проблему на небольшие блоки, выполняющие одну задачу, и выполняйте эту задачу действительно хорошо. Большинство фреймворков подталкивают разработчиков к использованию фронт-контроллеров, и они просто ошибаются.

7 голосов
/ 11 февраля 2009

Перефразируя статью Википедии о Front Controller :

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

Немного подробнее:

Фронт-контроллер "обеспечивает централизованную точку входа для обработки запросов". Давайте предположим, что фронт-контроллер для вашего веб-приложения index.php.

Этот скрипт, index.php, будет обрабатывать все задачи, которые являются общими для всего приложения или инфраструктуры, например обработка сеансов, кэширование, фильтрация ввода . В зависимости от заданного ввода он затем создает дополнительные объекты и вызывает методы для выполнения конкретной задачи.

Альтернативой фронт-контролеру будут отдельные скрипты, такие как login.php и order.php, каждый из которых будет включать код или объекты, общие для всех задач. Это потребует повторения кода включения в каждом сценарии, но может также оставить больше места для конкретных нужд сценария.

1 голос
/ 11 февраля 2009

Одним из преимуществ использования Front Controller является его тестируемость. если вы используете TDD, гораздо проще протестировать контроллер, чем запрашивать множество различных веб-сайтов.

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

...