为了账号安全,请及时绑定邮箱和手机立即绑定

ASP.NET MVC-控制器中是否应该存在业务逻辑?

ASP.NET MVC-控制器中是否应该存在业务逻辑?

梵蒂冈之花 2019-12-09 09:40:08
几天前,Derik Whitaker发表了一篇文章,达到了我一直以来很好奇的一点:控制器中是否应该存在业务逻辑?到目前为止,我见过的所有ASP.NET MVC演示都将存储库访问和业务逻辑放入了控制器中。有些人甚至还在那里进行验证。这导致相当大的,肿的控制器。这真的是使用MVC框架的方式吗?看来这最终将导致许多重复的代码和逻辑散布在不同的控制器上。
查看完整描述

3 回答

?
白猪掌柜的

TA贡献1893条经验 获得超10个赞

业务逻辑实际上应该在模型中。您应该针对胖模型,瘦控制器。


例如,与其具有:


public interface IOrderService{

    int CalculateTotal(Order order);

}

我宁愿拥有:


public class Order{

    int CalculateTotal(ITaxService service){...}        

}

这假设税收是由外部服务计算的,并且需要您的模型知道与外部服务的接口。


这将使您的控制器看起来像:


public class OrdersController{

    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}


    public void Show(int id){

        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);

    }

}

或类似的东西。


查看完整回答
反对 回复 2019-12-09
?
湖上湖

TA贡献2003条经验 获得超2个赞

您可以查看Stephen Walther撰写的这篇很棒的教程,其中显示了“使用服务层进行验证”。

了解如何将验证逻辑从控制器操作中移出并移到单独的服务层中。在本教程中,Stephen Walther解释了如何通过将服务层与控制器层隔离来保持关注点的清晰分离。


查看完整回答
反对 回复 2019-12-09
?
LEATH

TA贡献1936条经验 获得超6个赞

控制器中不应包含业务逻辑。控制器应该尽可能的瘦,最好遵循模式:

  1. 查找域实体

  2. 对领域实体采取行动

  3. 准备数据以查看/返回结果

另外,控制器可以包含一些应用程序逻辑。

那么我该把业务逻辑放在哪里?在模型中。

什么是型号?现在,这是一个好问题。请参阅Microsoft模式和实践文章(对AlejandroR的出色发现表示赞赏)。这里有三类模型:

  • 视图模型:这只是一个数据包,具有最少的(如果有的话)逻辑来往于视图之间传递数据,其中包含基本的字段验证。

  • 域模型:具有业务逻辑的胖模型,对单个或多个数据实体(即,给定状态下的实体A而不是对实体B的操作)进行操作

  • 数据模型:感知存储的模型,单个实体中包含的逻辑仅与该实体相关(即,如果字段a则字段b)

当然,MVC是一个范式,有多种形式。我在这里描述的只是MVC占据顶层,请参阅Wikipedia上的本文。

如今,MVC和类似的模型视图演示者(MVP)是“关注分离”设计模式,这些设计模式仅适用于较大系统的表示层。在简单的场景中,MVC可以代表系统的主要设计,直接进入数据库。但是,在大多数情况下,MVC中的Controller和Model对Service或Data层/层具有宽松的依赖关系。这一切都与客户端-服务器架构有关


查看完整回答
反对 回复 2019-12-09
  • 3 回答
  • 0 关注
  • 1316 浏览
慕课专栏
更多

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信