我想将大多数业务层方法暴露给Web API项目以允许更广泛的使用。
一个想法是每个资源都有一个Web API控制器。
另一个想法是每个逻辑业务部分有一个控制器,并使用属性路由来公开相关方法。
我喜欢第二种方法,这会导致控制器减少。
每个资源没有一个控制器有什么缺点?
其他信息:
此API将存在于Intranet中,并将为需要来自我们2-3个主应用程序(ERP,Payroll,Barcode e.t.c)的数据的支持应用程序提供服务
此APi的资源是在我们的业务层程序集中定义的业务实体。它们将是简单的对象和复杂的对象。例子:
e.t.c
示例:
我想公开GetCustomerListByArea
或GetItemsListPerCategory
等方法。
然后呢?我应该创建另一个控制器还是使用自定义控制器操作和属性路由并将其放在现有控制器中?
包含更多信息的链接:
REST vs. RPC in ASP.NET Web API? Who cares; it does both.
非常好,相当陈旧,文章解释了我的问题。但它实际上并没有更深入地说如何设计控制器。在地区?或者只是文件夹?
答案 0 :(得分:2)
这归结为一个简单的设计原则 - 关注点分离(SoC),你应该考虑一下你想要公开的业务层中的哪些功能,并根据它来创建控制器。
从上面的示例中,可能创建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
希望有帮助...