Question

我正在编写一个包含许多Ajax小部件的应用程序（Kendo-UI要做得很好）。在没有标准控制器的情况下让所有Ajax响应开始变得混乱，所以我开始考虑让每个实体成为他们自己的控制器。如果我花时间去做这件事，我想我不得不去做那些像WebAPI那样的事情，因为我计划在不太紧密的将来做这件事，但是，嘿，它已经完成了...... / p>

所以我的问题是：使用MVC应用程序自己的Web API作为Ajax Widget提供是一个好习惯还是有理由坚持使用标准控制器？

我见过一些关于性能的争论，但我不认为这适用于这种情况。我相信它更像是一个“控制器调用WebAPI”的情况，它具有明显的性能命中率。但是因为它已经是客户端Ajax调用，所以它进入标准MVC控制器或WebAPI控制器不应该改变一个东西，不是吗？

修改

有关该项目的其他信息：

我正在使用Entity Framework进行数据访问。
我在UnitOfWork上有一个存储库模式。
我正在使用适当的MVC结构（EF POCO AutoMapped到存储库中的DTO POCO并由控制器提供给View Models）
这是.NET 4.0上的MVC 4项目
有很多数据库关系（特别是我目前正在使用的对象）

Answer 1

我不知道“良好做法”，但肯定不是“不良做法”。无论你是在应用程序中还是在另一个应用程序中执行此操作，我都没有区别。

Answer 2

我认为这是一件好事，但前提是您在API中所做的事情尽可能保持通用，其他应用程序和服务可以重用API。

我编写并继续维护的应用程序几乎与您的应用程序完全相同。

我最近重新考虑了其中一个应用程序，它将API用于所有常见的事情，例如我在视图中绑定到Kendo ComboBoxes等的列表。它是一个相当大的应用程序，可以重复使用许多相同的列表，例如状态，优先级，各种实体和视图的复杂性，因此将它们放入API中是有意义的。

我没有走完全程。我用这样的东西画线：

public ActionResult GetAjaxProjectsList([DataSourceRequest]DataSourceRequest request)
    {
        return Json((DataSourceResult)GetProjectsList().ToDataSourceResult(request), JsonRequestBehavior.AllowGet);
    }

这非常特定于Kendo Grid如何回收数据。我连接到这个应用程序的任何其他内容都不会以这种格式使用这些数据，所以我将它保存在控制器中。

简而言之......我将API用于同一MVC应用程序中的常见内容以及我允许其他应用程序或服务（如Excel）使用的内容。

使用MVC应用程序自己的Web API进行Ajax绑定是一个好习惯吗？

2 个答案: