Question

ASP.NET Web API，拥有一个用于所有业务对象的控制器是一种好习惯吗？

例如，我的控制器中有以下路径：

[Route("{resource}/{id}")]
[HttpGet]
public HttpResponseMessage Get(string resource, int id)
{
    // code not shown for brevity...
}

基于此，我有大约50个业务对象，每个业务对象都有一个名为＆＃34; Resource＆＃34;的属性，它基本上是作为字符串的类的名称（例如＆＃34; Customer＆＃34; ;，＆＃34;订单＆＃34;）。在我上面的控制器操作中，我使用路由参数＆＃34; resource＆＃34;来检索资源。和＆＃34; id＆＃34;。例如：

GET / Customer / 1234 和 GET / Order / 5678

这是不好的做法吗？为每个业务对象创建一个控制器更好吗？每种方法的优缺点是什么？

Answer 1

我喜欢Apple的做法。

每个视图仅由一个视图控制器控制。〜查看适用于iOS的控制器编程指南这个想法是你应该能够轻松交换视图。 IMO，每个视图只有一个控制器，因此更容易实现这一点。

虽然一般的经验法则，所需控制器的数量取决于Web应用程序中的许多模块和子模块。

作为补充，将控制器组织到区域中会很有帮助。 Areas的概念构建在ASP.NET MVC框架中，它简化了为一个模块提供服务的控制器的组织。

有许多相关的讨论：

MVC Architecture

MVCController And View directories organization

What does MVC class organization look like for multiple views and controllers?

ASP.NET MVC controller actions design

Answer 2

我真正的问题是我是否应该这样做：

public class EverythingController : ApiController
{
     [Route("{resource}/{id}")]
     [HttpGet]
     public HttpResponseMessage Get(string resource, int id)
     {
        // decide which type to get using the 'resource' parameter...
     }

}

或者这个：

public class ProductsController : ApiController
{
     [Route("{id}")]
     [HttpGet]
     public HttpResponseMessage Get(int id)
     {
        // get product by id here...
     }

}

public class CustomersController : ApiController
{
     [Route("{id}")]
     [HttpGet]
     public HttpResponseMessage Get(int id)
     {
        // get customer by id here...
     }

}

为所有资源配备一个Controller是不好的做法吗？

2 个答案: