asp.net webapi 控制器的设计考虑答案

【问题标题】：design consideration for asp.net webapi controllerasp.net webapi 控制器的设计考虑
【发布时间】：2013-08-30 08:12:20
【问题描述】：

我是使用 EF4 的 MVC WebAPI 的新手。我想知道是否最好将具有多个 GET 和/或 PUT 方法的大型控制器拆分为多个控制器，以避免“找到与请求匹配的多个操作”错误。我更喜欢只使用基于 VERB 的路由模式“api/controller/id”，如下所示。

GlobalConfiguration.Configuration.Routes.MapHttpRoute(
"Api",
"api/{controller}/{id}",
new { id = RouteParameter.Optional }
);

例如，我有两个域对象，Doctor 和 Patient。 ClinicController 具有以下操作：

getDoctors()
getPatientCohort(int doctorId) 
getPatientPrimaryDr(int patientId) 
getPatientDoctors(int patientId, int clinicId)
getPatients()
getPatient(int patientId)
putDoctor(Doctor doctor)
putPatient(Patient patient)
createDoctor(Doctor doctor)
createPatient(Patient patient)

我是否应该将此控制器拆分为 DoctorController 和 PatientController，以便每个控制器只处理一个域对象。既然 Patient Cohort 是一个关联类，那么 getPatientCohort(int doctorId) 应该是 PatientController 还是 DoctorController 的方法？谢谢。

【问题讨论】：

标签： asp.net-web-api

【解决方案1】：

在我看来（我明确地说明了这一点），您应该为每个模型创建单独的控制器。这真的取决于行动本身的目的，但我大概可以猜到意图并大致将其分解。

Put 和 Create 方法应该驻留在它们自己的控制器中，因为这（我再次假设）与 Clinic 无关。患者和医生只是被创建或更新（替换），这在他们自己的控制器中非常好。如果将患者或医生分配到诊所，则诊所控制器内部应该有一个单独的操作来执行此操作。

任何以 Patient 模型为基础并检索关联模型的操作也应驻留在 PatientController 中；类似于 Doctor 模型。

所以本质上归结为：

任何特定于模型的操作都应该在该模型的控制器中。
检索关联模型的任何特定于模型的操作都应驻留在主模型的控制器中。
任何绑定操作都可以驻留在将两者绑定在一起的任一控制器中。

这类似于 OData 框架处理动作和关联的方式，因此我更习惯于以这种方式实现它。希望这可以为您解决一些问题（或至少提供一些指导方针）。

【讨论】：