c# - 该显示逻辑应该存在于 ViewModel 中还是映射层中？

Question

我最近开始了一个 MVC 项目，现在似乎每 5 分钟我就面临着关于如何处理这个项目的重大关键设计决策。总是这样，对吧？

我决定让我的领域模型类完全脱离 View ；它会导致大量外观相似的 ViewModel，但使用 AutoMapper 我认为这不会成为问题，而且我认为这是一种非常干净的方法。

然而，我最近的争论围绕着显示逻辑。假设我有一个模型 MyData，其属性类型为 Status。这是一个如下所示的枚举:

public enum Status {
   Ok,
   NotTooGreat,
   CouldBeBetter,
   Awful
}

在一个 View 中，当我渲染这个模型时，我想输出状态并根据情况的糟糕程度另外为输出着色。例如如果它是 Ok，我会显示绿色，如果它是 NotTooGreat 或 CouldBeBetter 则显示绿色，否则显示红色 Awful .

这个逻辑应该放在哪里？最终，颜色选择本身将在 View 中(例如，确定要输出的 css 类，该类控制颜色)，但确定状态是什么是我认为不应该在 View 中的决定。可能的选项是:

1. 在自定义 ViewModel 类中使用 DataAnnotations，例如

   public class MyDataViewModel {
       /* Amongst other MyData properties required... */
       public StatusViewModel Status; 
   }
   
   public enum StatusViewModel {
       [StatusDisplay(DisplayState.Ok)]
       Ok,
       [StatusDisplay(DisplayState.Warning)]
       NotTooGreat,
       [StatusDisplay(DisplayState.Warning)]
       CouldBeBetter,
       [StatusDisplay(DisplayState.Error)]
       Awful
   }
   

   这意味着我的映射相当笨拙，只能按值映射枚举。然后，View 将依赖 HtmlHelper 根据 DataAnnotation 更改输出。这看起来相当直截了当，但这是否在 ViewModel 中放置了过多的“业务”逻辑？也就是说，这不只是一个 UI 问题，所以 ViewModel 定义显示状态是完全有效的吗？我可能会以这种方式得到大量自定义 DataAnnotations 吗？如果我还需要说明用户可以根据当前状态执行哪些操作，这些不会变得臃肿吗？

2. 保持 ViewModel 简单，并依靠映射代码来容纳逻辑:

   public class MyDataViewModel {
        /* Amongst other MyData properties required... */
        public string StatusText; 
        public DisplayState Status;
   }
   

   这意味着 ViewModel 不知道什么状态与什么 DisplayState 相关联，它只知道可能存在哪些不同的 DisplayState(即 Ok、Warning 或 Error)。然而，这需要将逻辑放在映射代码中，这对我来说不像是“映射”——直到现在，Model + ViewModel 之间的映射一直是 Controller 非常直接的调用——但这也许是一种不必要的恐惧？

3. 这应该在 View 中，ViewModel 应该与模型保持相同，然后 View 或 HtmlHelper 中的一些代码将决定输出什么类，基于Status 是什么。

我想我倾向于第一，但我会欣赏其他人的观点。我想到的一件事是，这是一个非常简单的示例，但是如果 View 复杂得多呢？假设，如果 MyData 的状态为 Ok，我们希望向用户显示 MyData 模型中的更多属性，或者将数据拉入也来自其他模型类？

Answer 1

对于这种特殊情况，我认为 3. 更容易 - 在 View 模型上保留一个 Status 枚举属性，并有一个自定义帮助程序来格式化它。我不喜欢 1. 因为您正在复制相同的枚举，并且最终可能会得到大量数据注释。好像没必要。

顺便说一句，2. 似乎也是一个不错的选择。您不必担心将转换放入映射逻辑。