我还是ASP.NET MVC世界的新手,仍然尝试学习最佳实践和 最佳建筑模式。这里有一个我无法自己决定并需要社区支持的事情:
我不确定我应该把所有的业务逻辑放在哪里,以及控制器中有多少可用。我知道如果所有业务逻辑都在我的服务层实现,那将是最好的。我最担心的一个问题是,我不仅要在视图中显示简单的模型错误,还要在进行更复杂的业务验证时在不同的地方显示错误消息。但是当我有一个服务层进行完全验证并且与web层(控制器,视图)完全分离时,它会使所有错误传递更复杂并分配给正确的视图属性。
以下哪个选项更有意义,或者没有一般性推荐? 只是高级别的例子。没有正确的语法或命名: - )
选项1:
Controller.Action(){
if(ModelState.IsValid){
ServiceLayer.IsAllowedMoreComplexCheck();
ServiceLayer.IsBusinessModelValidCheck1();
ServiceLayer.IsBusinessModelValidCheck2();
ServiceLayer.IsBusinessModelValidCheck3();
ServiceLayer.DoAction1();
ServiceLayer.DoAction2();
ServiceLayer.DoAction3();
ServiceLayer.SaveChanges();
}
}
选项2:
Controller.Action(){
if(ModelState.IsValid){
ServiceLayer.IsAllowedMoreComplexCheck();
ServiceLayer.DoAllActions();
}
}
ServiceLayer.DoAllActions(){
ServiceLayer.IsBusinessModelValidCheck1();
ServiceLayer.IsBusinessModelValidCheck2();
ServiceLayer.IsBusinessModelValidCheck3();
ServiceLayer.DoAction1();
ServiceLayer.DoAction2();
ServiceLayer.DoAction3();
ServiceLayer.SaveChanges();
}
选项3:
Controller.Action(){
if(ModelState.IsValid){
ServiceLayer.IsAllowedMoreComplexCheck();
ServiceLayer.IsBusinessModelValidAllChecks();
ServiceLayer.DoAllActions();
}
}
ServiceLayer.DoAllActions(){
ServiceLayer.DoAction1();
ServiceLayer.DoAction2();
ServiceLayer.DoAction3();
ServiceLayer.SaveChanges();
}
还有更多的选择......但只是为了表明我在想什么。
欢迎提出反馈意见。
谢谢! 西蒙
答案 0 :(得分:0)
根据我的经验,将您的业务逻辑保留在服务层中,因为我认为通过这种方式您可以保持MVC的松散耦合座右铭。是的,你需要一些额外的代码来处理验证和错误,但我认为对于一个好的企业级应用程序,你必须设计出必须能够存活很长时间的良好架构。
使用MVC的最佳位置是使用其管道并为管道组件提供自定义逻辑。
为简单实施,您可以执行以下操作: -
您可以创建自定义操作属性以进行验证。
对于错误处理,您可以创建自定义错误操作属性,并通过在自定义错误中实现IExceptionFilter接口来提供您自己的OnException()方法实现。
详细参阅this link以了解错误处理。
答案 1 :(得分:0)
我不确定我应该把所有业务逻辑放在哪里,以及控制器中有多少可用。
控制器中不应包含任何业务逻辑。现在,通过放入服务层是什么意思。服务层应该只处理服务的目的,业务逻辑应该在业务逻辑层中,并且应该独立于服务层(如果你想改变服务层的服务方式怎么办?)。
我最担心的一个问题是,我不仅要在视图中显示简单的模型错误,而且还希望在进行更复杂的业务验证时在不同的地方显示错误消息。但是当我有一个服务层进行完全验证并且与web层(控制器,视图)完全分离时,它会使所有错误传递更复杂并分配给正确的视图属性。
从长远来看,这将是有回报的。在开发应用程序时,应充分考虑错误处理,异常处理。