Question

在asp.net mvc中，我一直认为在视图类上指定参数化构造函数比使用ViewData将数据传递给视图更有利。通过这种方式，视图类可以在动作中实例化，并作为IView的实现从那里返回，以便框架最终呈现给客户端。

// An example of an action that returned one of two
// views while passing a data objects from the current
// scope.
IView MyAction(discriminator){
  if(discriminator){
    return new MyView(SomeVal, SomeVal2)
  }else{
    return new AnotherView(SomeVal1)
  }
}

// An Example Definition for IView
public interface IView{
  Render(stream OutputStream);
}

// An Example View Code Behind/Partial Class
public partial class AnotherView{
  public AnotherView(string GimmeData){
    this.GimmeData = GimmeData
  }

  // This value could be accessed in the markup like:
  // <%=this.GimmeData%>
  public string GimmeData {get; set;}
}

我提出这个问题，因为我个人发现强类型视图毫无意义，因为没有1或0但 n 我希望从动作传递给视图的对象数量。我还发现ViewData集合有点过于“无类型”，以便与.net强类型世界很好地融合。

视图上的参数化构造函数甚至公共属性将允许视图的实现者指定渲染视图所需的数据的合约，或者可以在视图中呈现。这种方法可以有效地封装视图。

为什么这会是一个糟糕的设计？ “视图数据集”/“强类型视图”“方式”将数据从操作传递到视图有什么优点。有人认为这是个好主意吗？

更新

我改变了主意。我意识到视图实际上只是渲染。一种非常好的设计方法是引入代表应用程序中可用用户界面的Presentation Models。

如果可以显示某些内容，您的演示模型中应该有一个布尔值。如果某些内容可以显示文本，那么您的演示模型中应该有一个字符串。表示模型不是anemic，因为您使用它来封装UI的逻辑。例如，如果字段为空，则可能其他某些字段显示为灰色。这是表示逻辑，它描述了特定UI的工作方式。

一旦引入了表示模型，通用页面类就可以正常工作，只需将视图传递给正确的表示模型即可。演示模型允许您清理视图中的代码并提供可移植性。如果决定在winforms中实现，他们将非常需要将他们的UI绑定到表示模型。

无论如何，我只想跟进，因为我不再同意我原来的建议。我接受了特拉维斯的回答，因为这基本上就是他的建议。

Answer 1

约定通常是提供一个视图模型，用于封装视图中所需的数据。然后，您可以将此强类型对象传递到视图中。因此，例如，您可能有一个如下所示的BlogDisplay对象：

public object BlogDisplayPage {
  public string PageTitle {get; set;}
  public BlogEntry Content {get; set;}
  public IList<Comment> Comments {get; set;}
  public IList<BlogEntry> RelatedEntries {get; set;}
  public IList<BlogEntry> PreviousEntries {get; set;}
}

请原谅这个例子的假设，但我想你明白我想要的是什么。这样，您可以在一个对象中将与View关联的所有数据都轻松地进行测试和维护。这也具有使用泛型具有强类型视图的优点。

我更倾向于你对参数化构造函数的建议，因为它的意图是明确的，并且这些数据的创建和聚合将在一个可能更容易维护的位置。

ASP.NET MVC视图是否应该参数化

1 个答案: