Вы запускаете ajax-запросы через выбранную среду MVC или напрямую к CFC?
Я склоняюсь к обходу MVC, так как мне не нужен «Просмотр» из запроса ajax.
Каковы преимущества маршрутизации вызовов ajax через структуру MVC, например Coldbox?
обновление: найдена эта страница http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbAjaxHints, но я все еще пытаюсь осмыслить, какие преимущества это приносит по сравнению со сложностью, которую оно вносит...
Генри, я отправляю Ajax-запросы на прокси-объекты моей модели. Как правило, при этом я выхожу за рамки «рамок». При этом может быть (очень) необходимо использовать вашу структуру, например, работать в рамках установленной модели безопасности.
Я не вижу никаких преимуществ в обходе MVC-фреймворка — в сочетании эти три элемента являются вашим приложением.
Ваши элементы ajax действительно являются частью представления. Как говорит Лука, представление выводит результаты модели и контроллера.
Посмотрите на это так — если бы вы сделали удобный для iPhone веб-интерфейс (то есть новый View), вы бы обошли модель и контроллер?
Луис Маяно, создатель ColdBox сказал< /а>:
Это две школы взаимодействия ajax, Генри.
Я предпочитаю прокси-подход, потому что он добавляет следующее:
- Отладка
- Трассировка в отладчике
- Точки перехвата АОП
- Безопасность
- Настройка доступности
- Прокси будет ретранслировать модель событий, поэтому я могу использовать локальные точки перехвата, локальный АОП, плагины и т. д.
Другими словами, это может быть тщательно отслеживаемый вызов вместо простого служебного вызова cfc, который вы все еще можете сделать.
Мне, например, нравится, когда мой профилировщик выполнения (часть отладчика coldbox) работает, поэтому я могу видеть, когда приходят запросы ajax и когда они выходят. Я вижу запрошенные данные и данные, отправленные обратно. Мне не нужно заглядывать в лог-файлы или пытаться представить себе результаты или проблемы. Это действительно помогает в отладке.
Тем не менее, это будет выбор разработчика, по которому вы решите пойти. Я лично предпочитаю всегда использовать мой прокси для делегирования событий, потому что это дает мне гораздо больше гибкости, отладки и душевного спокойствия.
Цель «представления» в фреймворках MVC — показать данные после того, как «модель» и «контроллер» сгенерировали их. Если вам не нужен "вид", то какой смысл использовать такой шаблон проектирования?
Я согласен с Лукой. Он также обходит любую логику очистки и фильтрации, которая есть в вашем стеке MC. Это в основном сводит на нет любую обработку запросов, которую вы можете иметь или не иметь.
Да, я бы не стал обходить вашу структуру, выяснять, что вызывает у вас горе, и выискивать оскорбительные фрагменты, добавляя логику для исключения общих компонентов, таких как верхние и нижние колонтитулы, и искать методы, вводящие пробелы, которые, хотя и подходят для html, раздражают или не работают. правильно проблематично при разборе json.
Добавление output="false" особенно в ваш application.cfc и его методы было бы первым, что я почистил.
Я твердо верю в НИКОГДА не обращаться напрямую к CFC напрямую, я считаю, что это создает долгосрочные проблемы, когда крупный рефакторинг может захотеть объединить или исключить компоненты, прямой доступ потенциально усложняет это, чем должно быть, особенно если третья сторона попадание в ваш ajax из другого домена (например, флеш-удаление).
+1 к ответу Стива.
