У MVC, яка різниця між контролером та маршрутизатором?

Чи означають вони те саме (прив’язування URL-адрес до дій чи дій до URL-адрес) чи є якась різниця, якої я пропускаю?

Приклад: http://github.com/dannyvankooten/PHP-Router vs. http://konstrukt.dk

Маршрутизатор:

Маршрутизація - це процес прийняття кінцевої точки URI (тієї частини URI, яка надходить після базової URL-адреси) та її розкладання на параметри, щоб визначити, який модуль, контролер та дії цього контролера повинні отримувати запит.

Контролер:

Контролер реалізує схему »Контролер, в якій всі запити перехоплюються контролером та відправляються до окремих контролерів дій на основі запитуваної URL-адреси (тобто запит маршрутизації від маршрутизатора).

Frontend-контролер повинен взаємодіяти з маршрутизатором і диспетчером , щоб приймати рішення в залежності від запиту (HTTP) проти застосування якого конкретно дій повинні бути виконані , а потім відправляє його.

В залежності від того, наскільки детально конструкція є, деякі Диспетчерська сек робота без маршрутизатора s і вони роблять маршрутизації їх або маршрутизації мається на увазі в конструкції , як це відбувається при обробці запиту.

Деякий вантажовідправник и також передати запит об'єкт на послані методи дій . Потім Методи дій частково розкладають Запит так, що навіть дії Контролера все-таки можуть виконати деяку маршрутизацію на основі запиту. Типовим прикладом цього є той випадок, коли рамка пропонує зробити переспрямування як відповідь. Це також показує, наскільки пов’язані маршрутизатор та контролер пов'язані або поблизу .

Різниця, яка тут зазвичай намальована, полягає в тому, що маршрутизація бере на себе або допомагає визначити, який метод дії потрібно виконати, а контролер потім несе відповідальність за надання цієї дії, але обидва обробляють запит.

Як бачите, відмінності між маршрутизатором та контролером можуть сильно відрізнятися між реалізаціями та рамками. Зрештою, конкретна заявка має свої потреби, корисний чи ні певний рівень абстракції чи не стоїть на шляху.

Однак із термінів я б сказав, що Controller займає більш високу роль у загальній програмі. Ось тут дії так би мовити.

Маршрут відображає URL-адресу контролеру, що є дією. Іноді ролі насправді не дуже добре розділені залежно від структури.

Маршрутизатори є частиною шару контролера. Механізм обробки маршрутизатора - це заміна старої шкільної моделі переднього контролера (великий перемикач у index.php).

У сучасних рамках маршрутизатор визначає прямий зв'язок між "видом" можливих запитів та його процесором. На відміну від цього, контролер отримує просто ідентифікаційну інформацію та аналізує ці дані у власному контексті.

Простий маршрутизатор розгортається через додаток, як правило, заснований на зовнішньому введенні, такому як змінні GET або POST.

Однак маршрутизатор не є будь-якою частиною MVC, кілька MVC і HMVC фреймів використовують маршрутизатори, але це не прив'язує їх до структури MVC.

Крім того, кілька ранніх впроваджень MVC, які я бачив, фактично покладалися на файлове розділення дій з одним файлом на контролер для доступу до окремих контролерів. Це набагато краще служить додатку, оскільки, маючи худі контролери, з більш надійними моделями, вам ніколи не доведеться прокручувати певний метод в контролері, і тому ви можете отримати доступ до логіки в одному місці (моделі), що дозволяє складати поведінки.

маршрутизатор приймає

запит

і визначає, які методи контролера / контролера будуть обробляти запит.

Контролер приймає запити та обробляє його!

Тепер я також створив контролер, який розбиває URL і використовує першу частину після базового URL як контролер, а другу частину як дію. Це завантажує файл, відповідний контролеру, і метод у цьому файлі, що відповідає дії.

Це насправді не контролер (що стосується MVC), це частина маршрутизації.

Наприклад, візьміть [GET] uri: example.com/article/view/123 Маршрутизатор MVC проаналізує uri та знайде такі сегменти

article view 123 За замовчуванням більшість маршрутизаторів тепер буде екземпляром ArticleController і називатиме його метод перегляду, передаючи 123 як параметр. (Можливо, ви можете мати метод getUriSegment (segmentIdx), це вибір дизайну для вашої основи.)

ArticleController матиме метод перегляду з параметром $ articleId. Цей метод, ймовірно, зробить щось на кшталт: отримати вказану статтю (наприклад, від db через модель), а потім відобразити її (ймовірно, повернути подання, яке було надано статтю, повернутою моделлю