ASP.NET MVC中：在控制器还是服务层创建实体更合理？

在ASP.NET MVC开发中，选项2的实现方式更符合分层架构的规范，核心原因在于分层职责的清晰划分：

控制器的本职工作是接收HTTP请求、解析参数、调用业务服务并返回响应结果，不应该涉足实体创建这类业务逻辑范畴的操作。而服务层作为业务逻辑的核心封装层，负责处理实体创建、业务规则校验、数据持久化等核心业务动作，这样的划分更贴合单一职责原则，能大幅提升代码的可维护性与复用性。

两种实现对比 #

选项1（控制器创建实体）

控制器代码：

[HttpPost]
public IActionResult SuccessfullyCreatedPromocode(string promocodeName, decimal discount)
{
    Promocode promocode = new Promocode(promocodeName, discount);
    promocodeService.CreatePromocode(promocode);
    return View();
}

服务层代码：

public void CreatePromocode(Promocode promocode)
{
    context.Promocode.Add(promocode);
    context.SaveChanges();
}

这种方式下，控制器越界承担了实体创建的职责，一旦后续Promocode的创建规则发生变化（比如需要添加默认有效期、校验折扣范围），就必须修改控制器代码，破坏了业务逻辑的封装性。

选项2（服务层创建实体）

控制器代码：

[HttpPost]
public IActionResult SuccessfullyCreatedPromocode(string promocodeName, decimal discount)
{
    promocodeService.CreatePromocode(promocodeName, discount);
    return View();
}

服务层代码：

public void CreatePromocode(string promocodeName, decimal discount)
{
    Promocode promocode = new Promocode(promocodeName, discount);
    context.Promocode.Add(promocode);
    context.SaveChanges();
}

此实现中，控制器仅负责参数传递与服务调用，所有与Promocode相关的创建逻辑都封装在服务层内。后续若需要添加创建时的业务规则（比如校验折扣合法性、生成唯一标识），只需修改服务层代码，控制器完全无需变动，代码结构更清晰，职责边界更明确。同时，其他业务场景需要创建Promocode时，可直接复用服务层方法，避免重复代码。

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