MVC如何保持模型瘦 [英] MVC How to keep a model skinny

问题描述

观看此视频后，我想知道我是否使用我的控制器错误。

对于我的博客，我有一个post控制器有方法：
create
show
list
loadPost
like
dislike

我的帖子模型只有几个访问规则，验证规则和关系信息。

解决方案

我强烈建议您阅读
http://www.lostechies.com/blogs /jimmy_bogard/archive/2009/04/24/how-we-do-mvc.aspx

这是我不完整的控制器不应该做的列表：

• 将文章数据绑定到视图模型 - 否，模板绑定器应执行此操作




• 计算一些东西 - 不，查看模型或实体应该


• 授权 - 也许，但最好传递给属性/过滤器


• 验证 - 只有当从实体/域（即业务规则）回来时，视图模型
  
  
  
  
  
  
  
  • 处理域层错误
  $ b $ b
  • 根据视图模型/网域结果路由到相应的操作/视图
  
  

    public ActionResult PlaceOrder（Guid orderid）
   {
   if（HttpContext.Session [user] == null）
   return Redirect（Login）; 
   if（！ValidOrderId（orderid））return Redirect（）; 
   var order = cart.Get（orderid）; 
   if（order == null）{ViewData [orderid] = orderid; return View（Select）; } 
   order.Status = OrderStatus.Placed; 
   foreach（var item in order.Items）
   item.Update（）; 
   var cart = Cart.GetCurrent（）; 
   cart.Save（order）; 
   return Redirect（Show，Orders，new {orderid = orderid}）; 
  } 
    

  好

    [Authorize] 
   [ModelStateToTempData] 
   // OrderViewModel.Id/OrderViewModel.Instance  - 验证id，
   //从存储库获取它，设置Instance ModelState错误
   public ActionResult PlaceOrder（OrderViewModel< Order> order）
   {
   if（！ModelState.IsValid）
   return View（Select，order）; 
   var order = order.InstanceFromDatabase; 
   _injectedCart.SetOrderPlaced（order）; 
   return RedirectToAction< OrdersController>（c => c.Show（order））; 
  } 
    

  顺便说一句，我很少看到好的MVC示例，包括NerdDinner。它们都处理行为中的业务逻辑，没有视图模型等等。这通常对他们的目的是正确的 - MVC功能演示 - 但它不应该被视为良好的设计示例。一个或多或少的好例子是 CodeCampServer ，以及伴奏书ASP.NET MVC In Action。但是不是没有它的缺点（例如，贫乏域模型）。

  
  
  

  但是如果不尝试跟随域驱动设计，而是有一个简单的数据驱动需求，事情可以更容易为你。

  
  

  After watching this video, I am wondering if I am using my controllers wrong. What exactly should a controller contain?

  For my blog, I have a post controller which has methods: create show list loadPost like dislike

  Whereas my post model only has a few access rules, validation rules and relation information. Are there any examples of a MVC app on the web?

  解决方案

  I highly recommend reading http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/04/24/how-we-do-mvc.aspx

  Here's my incomplete list of what controller shouldn't do:

  • bind post data to view model - no, model binders should do this
  • get entities from repositories - I'd say no, model binders or action filters should
  • calculate something - no, view models or entities should
  • authorization - maybe, but it's better pass to attributes/filters
  • validation - only if it come back from entities/domain (i.e. business rules), view models (presentation) validation should be handled automatically (binders, etc)

  Should do:

  • get bound, validated view model as input
  • call domain layer, passing data from view model
  • handle domain layer errors
  • route to appropriate action/view depending on view model / domain results

  Bad:

  public ActionResult PlaceOrder(Guid orderid)
  {
    if (HttpContext.Session["user"] == null)
      return Redirect("Login");
    if (!ValidOrderId(orderid)) return Redirect();
    var order = cart.Get(orderid);
    if (order == null) { ViewData["orderid"] = orderid; return View("Select"); }
    order.Status = OrderStatus.Placed;
    foreach (var item in order.Items)
      item.Update();
    var cart = Cart.GetCurrent();
    cart.Save(order);
    return Redirect("Show", "Orders", new { orderid = orderid });
  }
  

  Good

  [Authorize]
  [ModelStateToTempData]
  // OrderViewModel.Id/OrderViewModel.Instance - validates id, 
  // gets it from repository, set Instance or ModelState error
  public ActionResult PlaceOrder(OrderViewModel<Order> order)
  {
    if (!ModelState.IsValid)
       return View("Select", order);
    var order = order.InstanceFromDatabase;
    _injectedCart.SetOrderPlaced(order);
    return RedirectToAction<OrdersController>(c => c.Show(order));
  }
  

  And by the way, I rarely see good MVC examples, including the NerdDinner. They all deal with business logic inside actions, no view models, and so on. This is usually OK for what they are intendet for - MVC features demonstration - but it shouldn't be taken as good design examples. A more-or-less good examples is CodeCampServer, along with accompanion book ASP.NET MVC In Action. But not without its drawbacks (anemic domain model, for example).

  But if do not try to follow domain driven design, and instead have a simple data-driven requirements, things can be easier for you.

  这篇关于MVC如何保持模型瘦的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！