3

在 MVC 或一般情况下，当尝试将业务逻辑与视图分离时，您在从视图中删除逻辑方面走了多远？视图应该有零逻辑吗？是否应该有多个带有变量填充的简单“洞”的静态视图，或者我们可以有一个可以根据情况输出不同 html 的单个视图？

<html>
    <body>
        <h1>Your name is @uname</h1>
        @if(account<3000) { 
             <p>You are an ok customer</p>
        } else { 
             <p>You are a great customer</p>
        }
    </body>
</html>

以上是OK，还是应该有两种观点，一种给OK客户，一种给大客户？

4

4 回答 4

3

在你的视图中有一些基本的逻辑是很好的，只要它只关心你正在显示的数据的表示。我可能会更改您的示例以删除“ok”或“great”客户的定义，并在模型中更早地设置它。

如果account<3000应该在您的业务逻辑中定义客户是“好的”，无论它可能在哪里 - 模型或业务层，它可以在哪里进行单元测试和重用。然后，您可以在视图中使用客户状态枚举在标记中执行此切换：

if (@Model.CustomerStatus == CustomerStatus.Ok)
{
    <p>You are an ok customer</p>
}
else
{
    <p>You are a great customer</p>
}
于 2012-10-12T12:51:14.103 回答
0

在我看来，拥有额外的视图是错误的，因为它会导致您在许多情况下复制 html 代码。

使用您提供的示例，我会坚持if..else在视图中使用一个块，而最终只有一个块<p>，并将其文本设置在一个变量中。就像是

 @string text = account<3000? "you are ok":"you are great";             
 <p>@text</p>

当然，还有另一种解决方案：使用 ViewModel 类扩展您的模型，该类将具有TypeOfCustomer字符串属性，并带有此相关文本。

总而言之，我不认为在视图中有这样的块来设置正确的 html 是“illega”。只要案例之间的差异小于共享代码，使用if..else块的单一视图就没有错。

于 2012-10-12T12:53:15.533 回答
0

在经典的 MVC 实现中，视图将包含表示逻辑。MVC 设计模式由两层组成：模型层和表示层。视图和控制器构成了表示层的大部分，其中控制器处理用户交互，视图处理用户界面。

因为你实际上不能（嗯..你可以，但在实践中它是半不可能的）为 Web 应用程序实现经典的 MVC 模式，在 ASP.NET MVC 框架中你通常有两种方法来解决这个问题：

  • 类似 Rails：您将表示逻辑推送到控制器中，并使模板几乎没有逻辑。但我会认为这是一个糟糕的选择，因为Rails 实施存在问题。

  • 视图模型。此结构允许您包含与控制器分开的表示逻辑。它实际上有点名不副实，因为 ViewModels，如 ASP.NET MVC 文档中所述，实际上是经典视图应该是的。您将表示逻辑放在ViewModel实例中并使用“视图”作为模板，现在它可以包含尽可能少的表示逻辑。

于 2012-10-12T12:54:59.123 回答
0

不管您的技术堆栈如何，您本质上是说如果客户的帐户少于 3000，则客户是好的，否则他们就很棒。

所以Customer State（换成更好的词，AccountState?）可以是Good或Great。

因此，它State是的一个方面，Customer并且应该是Customer.

于 2012-10-12T13:03:15.207 回答