1

我正在编写一个具有许多 Ajax 小部件的应用程序（准确地说是 Kendo-UI）。在没有标准控制器的情况下拥有所有这些 Ajax 响应开始变得混乱，所以我开始考虑让每个实体都成为自己的控制器。如果我花时间来做这件事，我想我还不如继续做那些作为 WebAPI 的事情，因为我计划在不久的将来做这件事，但是嘿，它已经完成了......

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

我见过一些关于性能的争论，但我认为这不适用于这种情况。我相信这更像是一种“控制器调用 WebAPI”的情况，它对性能有明显的影响。但是因为它已经是一个客户端 Ajax 调用，所以无论它进入标准 MVC 控制器还是 WebAPI 控制器都不应该改变任何事情，不是吗？

编辑

有关该项目的其他信息：

  • 我正在使用实体框架进行数据访问。
  • 我有一个使用 UnitOfWork 的存储库模式。
  • 我正在使用正确的 MVC 结构（EF POCO 自动映射到存储库中的 DTO POCO 并由控制器输入视图模型）
  • 这是 .NET 4.0 上的 MVC 4 项目
  • 有很多数据库关系（特别是对于我目前正在使用的对象）
4

2 回答 2

0

我不知道“好的做法”，但肯定不是“坏做法”。无论您是在应用程序中还是在其他应用程序中执行此操作，我都认为没有区别。

于 2012-10-23T19:21:17.857 回答
0

我认为这是一件好事，但只有当你在 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）使用的事物。

于 2013-07-24T04:39:51.047 回答