寻找静态助手类的替代品答案

【问题标题】：Looking for a replacement to a static helper class寻找静态助手类的替代品
【发布时间】：2014-09-04 00:47:29
【问题描述】：

我有一个 MVC ASP.NET 项目，我目前使用一个静态 ViewModelHelper 类，它有几个方法（每个视图模型 1 个）接受某些参数和模型对象并生成视图模型对象让我返回到我的我的控制器的意见。它们目前都是静态的，整个类是无状态的，我只是在我想实例化视图模型的实例时使用它，因为某些数据需要相当复杂的逻辑。

这些方法作为视图模型类中的构造函数会更好吗？我的理解是视图模型中最好不要有任何逻辑，但我可能是错的。或者是否有我应该在这里使用的设计模式来帮助我创建这些视图模型？

【问题讨论】：

ViewModel 绝对可以包含逻辑。您可能对 POCO 一词以及 POCO 通常没有逻辑这一事实感到困惑 - 但 ViewModel 肯定有。在 Views 中包含逻辑不是一个好主意......但绝对是在为视图提供服务的模型中。

标签： c# asp.net-mvc static static-libraries static-methods

【解决方案1】：

这是一个关于您的项目架构和设计 ViewModel 应该是什么样子以及它们应该在哪里/如何初始化的问题。现在您的 ViewModel 似乎是 DTO，您使用工厂方法对其进行初始化。这很好，但我建议实际采用抽象工厂模式，并确保工厂实现不会因不相关的职责而超载。这是一个“实用程序”类的继承问题，应该让每个开发人员保持警惕。

另一方面，视图相关的初始化逻辑，例如填充选择列表，可以很好地位于 ViewModel 本身中。在这种情况下，您应该警惕重复。

另一种可能的方法是利用构建器模式。

如果您只使用它而不是混合搭配，任何一种方式都可以是一个干净的解决方案。当然，只要你保持清洁。 ;)

虽然没有看到相当复杂的逻辑，但我建议您检查一下为什么初始化逻辑一开始就那么复杂。如果它真的必须是。可能有一些业务逻辑潜入其中？

【讨论】：

【解决方案2】：

您的 ViewModel 应该只是 DTO，仅具有属性的类。没有逻辑。将逻辑放入其他类（服务或完整的业务逻辑，取决于）并让它们填充 ViewModel。

我知道，相对于实质性的设计考虑，这个答案似乎很短，但这就是它的核心。对于推理等，请查看一些完整的 ASP.NET MVC 解决方案来演示它，例如 https://prodinner.codeplex.com/。

【讨论】：

我不得不不同意“没有逻辑”作为一个明确的规则。当然不是硬性和快速的业务逻辑——但肯定有一些逻辑应该进入 ViewModel。例如，我们有 ViewModels，它根据 ViewModel 满足的条件决定 DOM 元素应该具有什么 CSS 类。它们不是业务问题，而是视图的问题。但逻辑在视图中没有位置。
ViewModel 确实具有与 UI 相关的逻辑，例如当我单击按钮时，显示什么颜色，或者如何将 DTO 呈现给 UI 即。格式化的双精度值。 ViewModel 不应包含的逻辑是业务逻辑，例如如何计算 DTO 中的数据。