在控制器中使用FormViewModel与在模型中使用部分模型类的好处

Question

在目前的ASP.NET MVC应用程序中，我很难理解两种设计方法的长时间可扩展性。

我用于提供数据的ORM是Linq2SQL。哪个只是惊人的可以使用，BTW！

现在我在为我的视图设计模型类时遇到了一些麻烦。目前，我对数据库中的每个实体都有一个partial class。

• 这种方法允许我扩展课程而无需在我的视图上切换strongly typed模型
• 我可以轻松地为额外数据添加更多属性（主要是元数据）
• 我可以轻松添加帮助方法，为我填充列表和/或执行其他数据事务
• 还有一个问题：
  • 我无法创建自定义constructor，因为它已由Linq2SQL
  管理

在阅读ASP.NET MVC Book和一些教程后，我发现FormViewModels非常常见地用于提供对象的额外数据。

目前，我对我的实体的partial class设计非常满意。但我不介意切换设计，因为我仍在构建应用程序。

FormViewModel有什么好处，而不是简单的partial class方法，以及最佳做法在这个问题上有什么好处？

所有帮助都非常感谢！

Answer 1

与许多事情一样，这取决于。如果您的应用很小，并且您在用户看到的内容之间存在一对一的关系，则可能不需要视图模型。您可以直接公开模型。大多数应用都是小应用。

随着应用程序（特别是UI）的增长，您可能会发现您希望数据层模型对象与表示层模型对象之间有更大的分离。这就是视图模型的用武之地。即使属性相同（即用户有FirstName，LastName，EmailAddress等），模型的方法和要求也不同。通过视图模型，您可以更加贴近Single Responsibility Principle。

请不要相信不使用视图模型是一个重大的罪过。 Rails世界中没有人使用视图模型。 （至少我可以找到.Rails是一种动态语言，因此会改变很多规则。）

Answer 2

通过使用分部类方法，您可以强制您的域模型了解您的ui。所以我认为使用这种方法被认为是不好的做法。当您的应用程序增长时，维护可能会非常混乱。如果您的视图需要表示来自两个完全不同的模型的数据，会发生什么？

使用viewmodels是一种非常常见的模式，并且已被证明可以很好地工作。但是，使用此模式有不同的方法。您可以使用包含域模型对象的视图模型。或者，您可以创建完全独立的视图模型，这些视图模型仅包含他们需要显示的数据，而不包含任何域模型。如果使用这种方法，最终会得到很多映射代码。在这里，我建议您使用automapper，这将对您有所帮助。