问题分离，业务逻辑与表示逻辑

在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客户，另一个用于优秀客户？

来源

2012-10-11 Fergal

在视图中有一些基本的逻辑就可以了，只要它只关心显示的数据的显示即可。我可能会改变你的例子，删除“好”或“好”客户的定义，并在模型中进行更早的设置。

如果account<3000应该在您的业务逻辑中定义，那么可能是 - 模型或业务层，可以在其中进行单元测试和重新使用。然后，您可以使用客户状态枚举在视图中的标记执行此开关：

if (@Model.CustomerStatus == CustomerStatus.Ok) 
{ 
    <p>You are an ok customer</p> 
} 
else 
{ 
    <p>You are a great customer</p> 
}

来源

2012-10-12 12:51:14

有一个额外的观点是错误的，在我看来，因为它会导致你在许多情况下，复制HTML代码。

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

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

当然，还那里有另一种解决方案：用ViewModel类，这将有TypeOfCustomer字符串属性扩展模型，与此相关的文字。总结起来，我不认为它的“非法”在视图中有这样的块，以设置正确的html。只要案例之间的差异小于共享代码，那么使用if..else块来处理一个视图就没有问题。

来源

2012-10-12 12:53:15 YavgenyP

你究竟是什么意思*“用viewmodel扩展模型”*？ –

与你做的事情完全一样，可能是：创建一个新类，可能继承他的基类（User？）或包含它，并将相关文本作为属性访问，其值根据帐户值设置。 – YavgenyP

在传统的MVC实现中，视图将包含表示逻辑。 MVC设计模式由两层构成：模型层和表示层。视图和控制器构成了表示层的大部分，控制器处理用户交互并查看用户界面的处理。因为你实际上不能（很好......你可以，但在实践中它是半不可能的）为web应用程序实现经典的MVC模式，在ASP.NET MVC框架中，你通常有两种方法来处理这个问题：

Rails-like：您将控制器中的表示逻辑推送出去，几乎没有逻辑模板。但我会坐下来，这是一个不好的选择，因为issues与轨道实施。
ViewModels.此结构允许您将表示逻辑与控制器分开。它实际上有点错误，因为如ASP.NET MVC文档中所述的ViewModels实际上是经典视图应该是的。您将演示逻辑放入ViewModel实例中，并将您的“视图”用作模板，该模板现在可以包含尽可能少的演示逻辑。

来源

2012-10-12 12:54:59

不管你的技术层面如何，你基本上说的是客户如果他们的账户少于3000，那么他们是好的，否则他们会很棒。

所以CustomerState（交换这一点有一个更好的词，AccountState?）可以是Good或Great。

State因此是Customer的一个方面，应该是Customer上的财产/方法。

来源

2012-10-12 13:03:15

问题分离，业务逻辑与表示逻辑

回答

相关问题