Coldfusion, в чем преимущество дизайна фронт-контроллера перед контроллером страниц?

Question

Я не специалист по вычислительной технике, и я изо всех сил пытаюсь разобраться в подходах к проектированию MVC и средах в целом.Я «получаю» повторное использование кода и отделяю логику от отображения, и «получаю» инкапсуляцию и развязку, но я этого не понимаю.

В данный момент я просто помещаю все в корень, отдельные подпапки для изображений, cfcs и _include, все взаимодействия с базой данных через cfcs.Я делаю всю свою обработку в верхней части страницы, затем в строке комментария затем отображается / макет страницы под этим.

Большинство каркасов, на которые я смотрел, предпочитают фронт-контроллер, поэтому моя упрощенная версиядизайн верхнего контроллера MVC - это подпапка для cfcs, контроллеров и представлений, а также большой оператор switch в index.cfm

<cfif not IsDefined("URL.event")>
    <cflocation url="index.cfm?event=home" addtoken="No">
</cfif>

<cfswitch expression="#url.event#">
    <cfcase value="home">
        <cfinclude template="controllers/home.cfm"/>
        <cfinclude template="views/home.cfm"/>
    </cfcase>
    <cfcase value="about">
        <cfinclude template="controllers/about.cfm"/>
        <cfinclude template="views/about.cfm"/>
    </cfcase>
</cfswitch>

... но какое реальное преимущество дает мне этот дизайн контроллера страницы?Если только я не пишу сайты такого типа, я всегда нахожу, что логика контроллера специфична для представления, это не значит, что один контроллер может соответствовать нескольким представлениям или несколько контроллеров могут выводить на одно представление, так что в чем смысл?разделяя их?

Свет еще не включился для меня, какие-нибудь указатели?

Answer 1

Под «верхним» контроллером, я думаю, вы подразумеваете «фронтальный» контроллер , единую точку входа для запросов в приложение. Как писал @bpanulla, большинство сред ColdFusion используют этот шаблон проектирования. Это становится особенно интересным с перезаписью URL , когда становится легко иметь безопасные URL-адреса для поисковых систем , перехватывая URL (например, domain.ext/i/am/friendly.ext) и направляя его к какому-либо стандартному файлу, такому как index.cfm при задании запрошенного URL-адреса в качестве параметра (часто в качестве заголовка запроса). Это также облегчает редизайн сайта, когда URL-адреса меняются легче, поскольку он хорошо подходит для псевдонимов или перенаправлений.

Что касается контроллеров, то они обычно тесно связаны с определенным URL или шаблоном URL. Возможно, это будет более слабо связано с контроллерами, но на практике я обнаружил, что это свойство проявляется после нескольких рефакторингов. В основе контроллера должно быть одно или несколько обращений к уровню службы , который обращается к базе данных, выполняет бизнес-процессы, создает объекты с сохранением состояния и т. Д. Затем контроллер получает выходные данные уровня службы и размещает их в какой-либо механизм (например, event объект) используется для передачи данных в представление (я).

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

Таким образом, данный сервисный объект на сервисном уровне должен иметь возможность обслуживать несколько контроллеров. Например, рассмотрите возможность отображения информации о зарегистрированных пользователях в качестве виджета на сайте. Могут быть разные страницы, обслуживаемые разными контроллерами, но каждая из них будет вызывать один и тот же сервисный объект для входа в пользовательские данные, которые, вероятно, могут быть переданы тому же представлению, которое отображает виджет.

Обновление: преимущества переднего контроллера

• Безопасность : централизованная аутентификация и авторизация.
• i18n & l10n : ввести нужный языковой пакет в запрос глобально
• Process Orchestration : продумайте многоэтапный процесс оформления заказа для корзины покупок, в которой вы не хотите, чтобы кнопки «назад» и «вперед» работали - перенаправляя все через передний контроллер, вы можете выполнить какой шаг (т.е. состояние)
• Ведение журнала и отслеживание : легко добавить Google Analytics или другой запрос отслеживания на сайт, сделав добавление в одном месте
• Обработка ошибок : централизованное поведение

Теперь многие из этих предметов также можно выполнить с помощью <cferror> и Appplication.cfc, но мне проще иметь одну централизованную точку.

Полезные ссылки

• http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
• http://msdn.microsoft.com/en-us/library/ff648617.aspx

Answer 2

Вы фактически реализовали суть Fusebox (http://www.fusebox.org/) с тем, что написали. В этом нет ничего плохого, и большая часть сообщества ColdFusion использовала нечто похожее на это в течение многих лет - Fusebox был наиболее используемой средой CF (вмой опыт) до тех пор, пока всего несколько лет назад не появились ModelGlue, Mach-II и другие фреймворки CF второго поколения.

Одна вещь, на которую я могу обратить внимание, - это то, что ваш подход к контроллерам (в виде файлов .cfm) на самом делене обеспечивает инкапсуляцию типичным способом OOD, когда конкретные аргументы переходят к вызову метода объекта. Если вы не слишком усердны, со временем ваши контроллеры .cfm могут накопить большое количество недокументированных параметров, которые изменяют поведение для решения одной проблемы илидругой.

С помощью различных платформ вы также получаете полезные функции, такие как специальный код Application, Session и Request (onApplicationStart, onRequestEnd и т. д.). Но вы всегда можете получить их с помощью простого Application.cfc.