ASP MVC Ajax 控制器模式？

Question

我的MVC应用程序经常会有很多ajax调用（通过JQuery.get()）。我的控制器充斥着许多小方法，这些方法通过ajax被调用，这有点困扰我。在某种程度上，它似乎有点违反了MVC模式 - 控制器现在更像是数据访问组件而不是URI路由器。

我进行了重构，使得我的“真正”的控制器仅执行标准路由响应（返回ActionResponse对象）。因此，对/home/的调用显然会启动HomeController类，该类将以规范控制器方式响应，即返回普通的View。

然后，我将我的ajax内容移动到一个新的控制器类中，其名称我将前缀命名为“Ajax”。因此，例如，我的页面可能有三个不同的功能部分（例如购物车或用户帐户）。我为每个功能部分都有一个ajax控制器（AjaxCartController，AjaxAccountController）。将ajax调用内容移动到自己的控制器类中并没有什么不同 - 它只是为了保持代码整洁。在客户端，JQuery将使用这个新控制器，如下所示：

//jquery pseudocode call to specific controller that just handles ajax calls
$.get('AjaxAccount/Details'....

(1) MVC中响应Ajax调用是否有更好的模式？

(2) 对我来说，当涉及到Ajax时，MVC模型似乎有些不完整 - 它并没有真正地“控制”东西。它只是处理Ajax调用最好且最不痛苦的方式（或者我很无知）？换句话说，“控制器”抽象似乎与Ajax不能很好地协作（至少从模式的角度来看）。我是否遗漏了什么？

- Kevin Won

Answer 1

尽管你可能会在末尾加上`Controller`以使ASP.NET MVC的路由工作，但我倾向于做你已经做过的事情 - 除非我读到`AjaxCartController`时，我会在心里想到`AjaxCartPresenter`（即WinForms中常见的Model-View-Presenter模式）。也就是说，这个“控制器”并不控制，而是无耻地与视图接口相结合。但是，与视图不同，`控制器`呈现器是可测试的。

当我们将Web页面AJAX化时，我们正在将其转变为可以以细粒度方式反应的东西，因此细粒度方法是可以的。 细粒度正是重点和整个被发明的原因。 我们故意远离REST以满足特定场景的要求，因为该特定模式未解决手头的UI需求，而是选择了类似RPC的模型。 它们只是模式，在所有情况下一个都不会比另一个更好，即使我们的技术堆栈可能推动我们选择其中之一。 （实际上，HTTP本身在块/页/实体/表征状态转移文档方面表现得更好。）

在精神上，您可以将这些页面视为WinForms应用程序中的表单；这些方法位于“控制器”中仅是使用的技术的产物和让步。 （如果这让你非常困扰，你可以将AJAX方法卷入`IHttpHandler`并完全绕过MVC，但为什么要放弃自动路由/实例化/方法查找并使其变得更加困难呢？它在架构上是“干净”的和纯粹的，但具有可疑的益处。）

...至少，我是这样给自己辩解的=)

- Nicholas Piasecki

---

同意你的观点——基本上我们在Web上有两种访问“东西”的方式。MVC模式处理一种方式，而另一种方式我们不想谈论，因为它不符合我们的模式。但是，至少对我来说，由于Ajax是一种如此引人注目的技术（而且我的当前应用程序几乎完全通过Ajax驱动），所以花哨的MVC模式实际上大多被规避和修改以响应Ajax调用（我必须添加它做得很好）。似乎还没有一个很好的关于在MVC世界中使用Ajax的故事。 - Kevin Won

Answer 2

如果您有太多细粒度的请求，您可能希望有一个控制器操作方法来服务所有调用。您可以在该方法中使用“switch”来确定调用类型并相应地进行服务，而不是拥有无数个微小的方法。您甚至可以使用显式字符串常量而不是数字作为switch变量。

- Jay Shanker

---

使用 switch 语句似乎对我没有帮助。如果有的话，它只会让情况变得更糟...也许我没有理解你的观点？ - Kevin Won