Web API设计决策：模型作为参数传服务方法还是由服务持有？

我正在创建一个调用服务的Web API方法，代码实现如下：

public class AlertsController : ApiController {
    IAlertsService _alertsService;
    public AlertsController(IAlertsService alertsService) {
        _alertsService = alertsService;
    }
    [HttpPost]
    public IHttpActionResult Save(AlertModel alertModel) {
        if (ModelState.IsValid) {
            var alert = _alertsService.SaveAlert(alertModel);
            if (alert != null) {
                return Ok(alert);
            }
            return InternalServerError();
        }
        return BadRequest();
    }
}

目前我是将AlertModel作为参数传入服务的SaveAlert方法。想咨询一下：在Web API设计中，是将模型作为参数传入服务方法更合理，还是让服务持有模型更优？

我的建议：优先选择将模型作为参数传入服务方法 #

这是大多数Web API和分层架构中的常规做法，原因如下：

1. 保持服务的无状态性 #

服务层应该是无状态的，这样它可以被多个请求安全复用，也更容易进行单元测试和横向扩展。如果让服务持有模型，意味着服务实例需要维护模型的状态，这会带来线程安全问题——尤其是高并发场景下，多个请求可能同时操作同一个服务实例的模型，导致数据混乱。

2. 明确的职责划分 #

你的AlertsController负责处理HTTP请求、验证模型有效性，而IAlertsService专注于业务逻辑处理。把模型作为参数传入，清晰界定了两者的职责：控制器把处理好的有效模型传递给服务，服务只需要接收参数并执行业务操作，不需要关心模型的来源和后续生命周期。

3. 更好的可测试性 #

当服务方法接收模型参数时，你在写单元测试时可以轻松构造不同的AlertModel实例传入，验证服务在各种输入下的行为。如果服务持有模型，你需要先初始化服务的模型属性，测试步骤会更繁琐，还容易引入测试污染（比如上一个测试的模型状态影响下一个测试）。

何时考虑让服务持有模型？ #

当然也有例外场景：

• 如果你的业务逻辑需要长期维护模型的状态（比如多步骤流程，需要在多个服务方法调用间保留模型数据），这时可以考虑让服务持有模型，但通常这种情况会用会话或者数据库来持久化状态，而非让服务实例持有。
• 如果模型是服务内部的核心状态对象，且服务本身是单实例、低并发的场景，但这种情况在Web API中非常少见，因为Web API通常是多实例、高并发的。

总结一下，你当前的实现是合理的，继续保持将模型作为参数传入服务方法的方式，这更符合分层架构的设计原则，也能让你的代码更健壮、更易维护。

内容的提问来源于stack exchange，提问作者user_1856538_