是否需要工厂类来创建视图模型？

我的一位同事建议在我们的ASP.NET MVC解决方案中使用工厂类创建视图模型对象。其想法是，它可以帮助我们的应用程序中构建视图模型的方式设计和可维护性。

我想找出是否有人对此有经验。我进行了一些研究，但在这种实践上发现得很少。

当前，我们在控制器级别创建viewmodel对象，例如

public ActionResult Index()
{
    return this.View(this.BuildIndexViewModel());
}

因此this.BuildIndexViewModel（）负责创建viewmodel类（显然是：）。但是我们正在研究以下可能性：

public ActionResult Index()
{
    return this.View(ViewModelFactory.CreateIndexViewModel());
}

这是一个有趣的想法，但我不是100％相信。我对其他人对此的看法感兴趣。

design asp.net-mvc

— 杰森·埃文斯（Jason Evans）
source

我很难看到诚实的好处。您将使用工厂来隐藏对象的构造，但是在这种情况下为什么要这么做？

— CodeART 2012年

您的BuildIndexViewModel方法已经是工厂方法，该方法可能是控制器专用的。将其提取到不同的工厂类的唯一原因是在另一个控制器中重用它。

— MattDavey 2012年

你们俩在这方面都和我有相同的想法，所以很高兴我并不孤单:) @MattDavey我可以坦白地说，我非常怀疑视图模型是否将用于一个以上的控制器，这使得工厂想法多余。当主题再次出现时，我将与您分享。

— 杰森·埃文斯

就我个人而言，我更希望viewmodel类型是构造自身过程的专家。专门知识应该放在其他地方的唯一时间是，如果构造需要其他应用程序领域（例如存储库）的知识，那么在这种情况下，您可能希望中间人将视图模型保持

— 沉默

@MattDavey：您能将这两条评论包装成我可以投票赞成的答案吗？

— pdr 2012年

在这种情况下，我要说的最佳指导就是GRASP原则。特别要注意分配对象创建的四个标准：

通常，如果满足以下一项或多项优选条件，则B类应负责创建A类的实例

您的控制器类（B）与该列表中的项目＃3和＃4相匹配（如果将视图模型回发了，则与＃2匹配），因此，对于已经存在的视图模型（A）构造行为而言，这已经是一个非常明智的选择。正如我所看到的，只有两个原因会迫使我将这种构造行为提取到专业班级中。

回顾GRASP中的这4个对象创建标准，如果将其吸引到我，我只会将该行为提取到单独的工厂中。否则，这样做将没有任何价值。

希望有帮助！

— 马特·戴维
source