Ajax请求,通过MVC框架(如Coldbox)还是不?

亨利,我发出Ajax请求来代理我模型的对象。通常情况下,我这样做是在“框架”之外的。也就是说,可能需要(非常)利用您的框架,例如在一个集合安全模型内工作。

我真的看不到绕过MVC框架的任何好处——结合起来,这三个元素 是 你的申请。

Ajax元素实际上是视图的一部分。正如Luca所说,视图输出模型和控制器的结果。

以这种方式看——如果你制作了一个iPhone友好的网络界面(也就是一个新的视图),你会绕过这个模型和控制器吗?

路易斯马加诺,冷盒的创造者 said :

这是阿贾克斯的两个学校 互动亨利。

我更喜欢代理方法,因为它 添加以下内容:

1. 调试
2. 在调试器中跟踪
3. AOP拦截点
4. 安全性
5. 设置可用性
6. 代理将中继到事件模型,因此我可以使用本地拦截 点、本地AOP、插件等。

换句话说,它可以是 受监视的调用而不是简单的调用 服务CFC呼叫,您仍然可以 做。

我,作为一个人,我喜欢我的处决 探查器正在运行(Coldbox的一部分 调试器),这样我可以看到Ajax 请求来了,什么时候来了 出来。我可以看到请求的数据 返回的数据。我不需要 查看日志文件,或尝试想象 结果或问题。它确实有帮助 在调试中。

但是,它将是一个开发人员 选择你决定走哪条路。 我个人的偏好是 使用我的代理进行事件委派 因为它给了我更多 灵活性、调试和和平 介意。

MVC框架中“视图”的目的是 显示 “模型”和“控制器”之后的数据生成了它。如果你不需要“视图”,那么使用这种设计模式有什么意义呢?

我同意卢卡的看法。它还绕过您的mc堆栈中的任何类型的清理和过滤逻辑。它基本上否定了任何类型的查询处理,而这些查询处理可能已经到位,也可能还没有到位。

是的,我不会绕过您的框架,弄清楚是什么让您感到悲伤,并找出有问题的部分,添加逻辑以排除常见组件(如页眉或页脚),并寻找在解析JSON时注入空白的方法,这些方法虽然对HTML很好,但却很烦人或有问题。

添加output=“false”,尤其是在application.cfc和它的方法中,这将是我清理的第一件事。

我坚信永远不要直接访问cfc,我发现当一个主要的重构可能想要合并或消除组件时,它会产生长期的问题,直接访问可能会使这比它应该的更困难,特别是当第三方从另一个域(如flash remoting)访问您的Ajax时。

+史蒂夫的答案。