我的MVC应用程序往往有很多ajax调用(通过JQuery.get()).我的控制器充满了许多通过ajax调用的微小方法,这让我很烦恼.在我看来,有点像打破MVC模式 - 控制器现在更像是一个数据访问组件,然后是一个URI路由器.
我进行了重构,以便我只为执行标准路由响应的页面设置"真正的"控制器(撤回ActionResponse对象).所以对/ home /的调用显然会启动HomeController类,它将通过返回一个简单的View来以规范的控制器方式响应.
然后我将我的ajax内容移动到一个新的控制器类中,其名称我正在使用'Ajax'.因此,例如,我的页面可能有三个不同的功能部分(比如购物车或用户帐户).我为每个这些(AjaxCartController,AjaxAccountController)都有一个ajax控制器.将ajax调用内容移动到自己的控制器类中并没有什么不同 - 它只是为了让事情变得更清晰.在客户端,显然JQuery将使用这个新的控制器:
//jquery pseudocode call to specific controller that just handles ajax calls
$.get('AjaxAccount/Details'....
(1)MVC中有更好的模式来响应ajax调用吗？
(2)在我看来,当谈到ajax时,MVC模型有点漏洞 - 它并不是真正"控制"的东西.它恰好是处理ajax调用的最好和最痛苦的方式(或者我是无知的)？
换句话说,'Controller'抽象似乎不适合Ajax(至少从模式的角度来看).有什么我想念的吗？
虽然您可能会将Controller其放在最后以使 ASP.NET MVC 的路由魔法发挥作用，但我倾向于做您已经做过的事情 - 除非我在阅读时AjaxCartController我自己思考AjaxCartPresenter（如通常在模型-视图-呈现器模式中那样）在 WinForms 中看到）。也就是说，这个“控制器”不是在控制，而是毫无羞耻地与视图界面绑定在一起。但是，与视图不同，控制器呈现器是可测试的。
当我们对网页进行 AJAX 化时，我们将其转变为可以以细粒度方式做出反应的东西，因此细粒度方法是可以的。细粒度是它的要点，也是它被发明的全部原因。对于特定场景，我们故意放弃 REST，因为该特定模式无法解决当前的 UI 需求，而是选择类似 RPC 的模型。它们只是模式，一种模式不会在所有情况下都比另一种模式更好，即使我们的技术堆栈可能会推动我们走向一种模式而不是另一种模式。（事实上，HTTP 本身在块/页面/实体/表征状态传输文档方面做得更好。）
从心理上来说，您可以将这些页面视为 WinForms 应用程序中的表单。事实上，这些方法位于“控制器”中，这只是所使用技术的产物和让步。（如果它超级麻烦你，你可以将 AJAX 方法卷入一个IHttpHandler并完全绕过 MVC，但为什么要放弃自动路由/实例化/方法查找并让自己变得困难？它在架构上是“干净”和纯粹的但有可疑的好处。）
...至少，这就是我对自己合理化的方式 =)
| 归档时间： |
|
| 查看次数： |
1616 次 |
| 最近记录： |