我的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 （至少从模式角度来看）。有什么我想念的吗？
答案 0 :(得分：4)
虽然你可能会将Controller放在它的最后以使ASP.NET MVC的路由魔术工作，但我倾向于做你已经完成的事情 - 除非我读到AjaxCartController我< em>想给自己AjaxCartPresenter（如WinForms中常见的Model-View-Presenter模式）。也就是说，这个“控制器”不是控制，而是与视图界面无关。但是，与视图不同，控制器演示者是可测试的。
当我们对网页进行AJAX化时，我们将其转化为能够以细粒度方式做出反应的内容，因此细粒度的方法是可以的。 精细粒度是重点以及它被发明的全部原因。我们故意放弃REST以获取特定场景，因为该特定模式不能解决手头的UI需求，而是选择类似RPC的模型。它们只是模式，在所有情况下都不会比另一种更好，即使我们的技术堆栈可能会将我们推向另一个。 （事实上，HTTP本身在块/页面/实体/代表性状态转移文档中表现更好。）
在精神上，您可以将这些页面视为WinForms应用程序中的表单;这些方法位于“控制器”中的事实只是对所使用技术的一种假象和让步。 （如果它超级麻烦困扰你，你可以将AJAX方法转换为IHttpHandler并完全绕过MVC，但为什么要抛弃自动路由/实例化/方法查找并让自己变得困难？这在架构上是可行的“干净”，纯净但可疑的好处。）
......至少，这就是我对自己合理化的方式=）
答案 1 :(得分：0)
如果您有太多细粒度的请求，您可能希望使用一个Controller Action方法来为所有调用提供服务。您可以在方法中使用“开关”来确定呼叫类型并相应地为其提供服务，而不是使用极少数方法。您甚至可以使用显式字符串常量而不是switch变量的数字。