您是通过选择的 MVC 框架还是直接向 CFC 发出 ajax 请求？
我倾向于绕过 MVC，因为我不需要来自 ajax 请求的“视图”。
通过 MVC 框架（如 Coldbox）路由 ajax 调用有哪些优点？
更新：找到此页面http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbAjaxHints，但我仍在努力思考它带来的复杂性带来的好处......
【问题讨论】：
标签： coldfusion cfc coldbox
Henry，我向我的模型的代理对象发出 Ajax 请求。通常，这样做时我在“框架”之外。话虽如此，可能（非常）有必要利用您的框架，例如在设定的安全模型中工作。
【讨论】：
我真的看不出绕过 MVC 框架有什么好处 - 结合起来，这三个元素是您的应用程序。
您的 ajax 元素确实是视图的一部分。正如 Luca 所说，视图输出模型和控制器的结果。
这样看——如果你制作了一个对 iPhone 友好的 Web 界面（即一个新的 View），你会绕过模型和控制器吗？
【讨论】：
Luis Majano，ColdBox 的创建者said：
这是 ajax 的两个流派 互动亨利。
我更喜欢代理方法，因为它 添加以下内容：
- 调试
- 在调试器中跟踪
- AOP 拦截点
- 安全性
- 设置可用性
- 代理会中继到事件模型，所以我可以使用本地拦截 点、本地 AOP、插件等。
换句话说，它可以是一个高度 受监控的呼叫而不是简单的呼叫 服务 cfc 调用，您仍然可以 做。
一方面，我喜欢被处决 分析器正在运行（冷箱的一部分 调试器），所以我可以看到ajax 请求进来和他们什么时候来 出去。我可以看到请求的数据和 发回的数据。我不必 查看日志文件，或尝试想象 结果或问题。它真的有帮助 正在调试中。
但是，这将是一个开发者 选择你决定走哪条路。 我个人的偏好是永远 使用我的代理进行事件委托 因为它给了我更多 灵活性，调试和和平 介意。
【讨论】：
MVC 框架中“视图”的目的是在“模型”和“控制器”生成数据后显示数据。如果你不需要“视图”，那么使用这样的设计模式有什么意义呢？
【讨论】：
我同意卢卡的观点。它还绕过了 MC 堆栈中的任何类型的清理和过滤逻辑。它基本上否定了您可能拥有或未实施的任何类型的查询处理。
【讨论】：
是的，我不会绕过你的框架，找出导致你悲伤的原因并找出有问题的部分，添加逻辑以排除页眉或页脚等常见组件，并寻找注入空格的方法，虽然这对 html 很好解析 json 时烦人或有问题。
添加 output="false" 尤其是在您的 application.cfc 和它的方法将是我清理的第一件事。
我坚信永远不要直接直接访问 CFC，我发现当重大重构可能想要整合或消除组件时，它会产生长期问题，直接访问可能会使这比应有的更难，特别是如果第三方正在从另一个域访问您的 ajax（例如 Flash 远程处理）。
+1 史蒂夫的回答。
【讨论】：