本文是小编为大家收集整理的关于ASP.NET MVC-业务逻辑应该存在于控制器中吗？的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
derik whitaker发布了文章几天前，我一直很好奇大约一段时间:控制器中是否存在业务逻辑?
到目前为止，我看到的所有ASP.NET MVC演示都将存储库访问和业务逻辑放在控制器中.有些人甚至在其中也进行了验证.这导致相当大的肿的控制器.这真的是使用MVC框架的方法吗?看来这只会最终得到许多重复的代码和逻辑分布在不同的控制器上.
推荐答案
业务逻辑确实应该在模型中.您应该瞄准脂肪模型，瘦控制器.
例如，而不是:
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);
}
}
或类似的东西.
其他推荐答案
我喜欢 Microsoft模式和实践.我相信句格"图片值得一千个字".
其他推荐答案
这是一个有趣的问题.
我认为，很有趣的是，大量的示例MVC应用程序实际上未能遵循MVC范式，因为它将完全放置在模型中.马丁·福勒(Martin Fowler)指出，从四个团伙的意义上讲，MVC并不是一种模式.相反，如果程序员在玩具应用程序之外创建了一些内容，则程序员必须将模式添加到是范式.
因此，简短的答案是"业务逻辑"确实不应在控制器中生活，因为控制器具有处理视图和用户交互的附加功能，我们只想创建一个目的.
一个更长的答案是，您需要在模型层的设计中考虑一些思考，然后才将逻辑从控制器转移到模型.也许您可以使用REST处理所有App Logic，在这种情况下，模型的设计应相当清楚.如果没有，您应该知道您将使用哪种方法来防止模型变得肿.
问题描述
Derik Whitaker posted an article a couple of days ago that hit a point that I've been curious about for some time: should business logic exist in controllers?
So far all the ASP.NET MVC demos I've seen put repository access and business logic in the controller. Some even throw validation in there as well. This results in fairly large, bloated controllers. Is this really the way to use the MVC framework? It seems that this is just going to end up with a lot of duplicated code and logic spread out across different controllers.
推荐答案
Business logic should really be in the model. You should be aiming for fat models, skinny controllers.
For example, instead of having:
public interface IOrderService{
int CalculateTotal(Order order);
}
I would rather have:
public class Order{
int CalculateTotal(ITaxService service){...}
}
This assumes that tax is calculate by an external service, and requires your model to know about interfaces to your external services.
This would make your controller look something like:
public class OrdersController{
public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}
public void Show(int id){
ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
}
}
Or something like that.
其他推荐答案
I like the diagram presented by Microsoft Patterns & Practices. And I believe in the adage 'A picture is worth a thousand words'.
其他推荐答案
This is a fascinating question.
I think that its interesting that a large number of sample MVC applications actually fail to follow the MVC paradigm in the sense of truly placing the "business logic" entirely in the model. Martin Fowler has pointed out that MVC is not a pattern in the sense of the Gang Of Four. Rather, it is paradigm that the programmer must add patterns to if they are creating something beyond a toy app.
So, the short answer is that "business logic" should indeed not live in the controller, since the controller has the added function of dealing with the view and user interactions and we want to create objects with only one purpose.
A longer answer is that you need to put some thought into the design of your model layer before just moving logic from controller to model. Perhaps you can handle all of app logic using REST, in which case the model's design should be fairly clear. If not, you should know what approach you are going to use to keep your model from becoming bloated.
更多相关问答
联系站长