Ajax 请求是否通过 MVC 框架（例如 ColdBox）？
您是通过选择的 MVC 框架还是直接向 CFC 发出 ajax 请求？
我倾向于绕过 MVC，因为我不需要 ajax 请求中的“视图”。
通过 MVC 框架（如 Coldbox）路由 ajax 调用有哪些优点？
更新：找到此页面 http://ortus.svnrepository.com/coldbox/trac .cgi/wiki/cbAjaxHints 但我仍在尝试思考它带来的好处相对于它引入的复杂性......
Do you fire ajax requests through the MVC framework of choice, or directly to the CFC?
I'm leaning towards bypassing the MVC, since I need no 'View' from the ajax request.
What are the pro's of routing ajax calls through MVC framework, like Coldbox?
update: found this page http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbAjaxHints but I am still trying the wrap my mind around what benefits it brings over the complexity it introduces...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
Henry，我向代理模型的对象发出 Ajax 请求。 通常，我这样做时是在“框架”之外的。 话虽如此，利用您的框架可能（非常）有必要，例如在设定的安全模型内工作。
Henry, I make my Ajax requests to proxy objects of my model. Typically, I am outside of a 'framework' when doing so. That being said, it may be (very) necessary to utilize your framework, such as working within a set security model.
我确实看不出绕过 MVC 框架有什么好处 - 结合起来，这三个元素就是您的应用程序。
您的 ajax 元素实际上是视图的一部分。 正如 Luca 所说，视图输出模型和控制器的结果。
这样看——如果你制作了一个 iPhone 友好的 Web 界面（即一个新的视图），你会绕过模型和控制器吗？
I can't really see any benefit of bypassing the MVC framework - in combination, those three elements are your application.
Your ajax elements are really part of the view. As Luca says, the view outputs the results of the model and controller.
Look at it this way - if you made an iPhone-friendly web interface (that is, a new View), would you bypass the model and controller?
Luis Majano，ColdBox 的创建者 说：
Luis Majano, creator of ColdBox said:
MVC 框架中“视图”的目的是在“模型”和“控制器”生成数据后显示数据。 如果不需要“视图”，那么使用这样的设计模式有什么意义呢？
The purpose of the "view" in MVC frameworks is to show the data after the "model" and "controller" have generated it. If you don't need the "view", then what's the point of using such a design pattern?
我同意卢卡的观点。 它还绕过 MC 堆栈中的任何类型的清理和过滤逻辑。 它基本上否定了您可能有或没有的任何类型的查询处理。
I agree with Luca. It also bypasses any kind of sanitization and filtering logic you have in your MC stack. It basically negates any kind of query processing that you may or may not have in place.
是的，我不会绕过你的框架，找出导致你悲伤的原因并找出有问题的部分，添加逻辑以排除常见组件（例如页眉或页脚），并寻找注入空白的方法，尽管对于 html 来说很好，但很烦人或令人沮丧解析 json 时出现问题。
添加 output="false" 特别是在您的 application.cfc 及其方法中将是我清理的第一件事。
我坚信永远不要直接访问 CFC，我发现当重大重构可能想要合并或消除组件时，它会产生长期问题，直接访问可能会使这变得比应有的困难，特别是如果第三方是从另一个域（例如 flash remoting）访问您的 ajax。
对史蒂夫的回答+1。
Yeah, I wouldn't bypass your framework, figure out what's causing you grief and hunt down the offending pieces, adding logic to exclude common components such as headers or footers, and looking for methods injecting whitespace that while fine for html is annoying or down right problematic when parsing json.
Adding output="false" especially in your application.cfc and it's methods would be the first thing I cleaned up.
I am a strong believer in NEVER directly accessing the CFC's directly, I find it creates long term problems when a major refactor might want to consolidate or eliminate components, the direct accesses potentially make this harder than it should be, especially if a third party is hitting your ajax from another domain(e.g. flash remoting).
+1 to Steve's answer.