c# - 每个资源有一个 Web API Controller ，还是有更多自定义操作的更少 Controller ？

Question

我想将我的大部分业务层方法公开给 Web API 项目以允许更广泛的使用。

一个想法是每个资源有一个 Web API Controller 。

另一种想法是每个逻辑业务部分有一个 Controller ，并使用属性路由来公开相关方法。

我喜欢第二种方法，它可以减少 Controller 。

每个资源没有一个 Controller 有什么缺点？

附加信息:

此 API 将存在于 Intranet 中，并将服务于需要来 self 们 2-3 个主应用程序(ERP、Payroll、Barcode 等)数据的支持应用程序

此 API 的资源将是在我们的业务层程序集中定义的业务实体。它们将是简单的对象和复杂的对象。示例:

• 库存元素
• 客户
• 每个客户的项目
• 当前正在加载 pickslips
• 目前的生产数据

e.t.c

示例:

我想公开像 GetCustomerListByArea 或 GetItemsListPerCategory 这样的方法。

然后呢？我应该创建另一个 Controller 还是使用自定义 Controller 操作和属性路由并将其放入现有 Controller 中？

包含更多信息的链接:

REST vs. RPC in ASP.NET Web API? Who cares; it does both.

非常好，相当古老的文章，解释了我的问题。但它并没有更深入地实际说明如何组织 Controller 。在地区？或者只是文件夹？

Answer 1

这归结为一个简单的设计原则 - 关注点分离 (SoC)，您应该考虑要公开业务层中的哪些功能并基于此创建 Controller 。

从上面的示例中，您可能创建一个 ProductController 和 CustomerController，它们可以公开以下端点:

GET /api/customer/1234        # gets customer by id
POST /api/customer/create     # creates a new customer
GET /api/customer/1234/items  # gets all items for a customer
GET /api/product/9876         # gets a product by id
POST /api/product/create      # creates a new product

希望对您有所帮助...