ASP.NET MVC3中的视图模型模式及其使用（同时使用EF 4.1）

Question

我已经为这个问题搜寻了好几天，让我感到非常疯狂。目前，我正在使用ASP.NET MVC 3开发一个项目，并尝试使用每个控制器一个ViewModel的方法，正如我查看的许多文章和教程所建议的那样。为了更好地说明我的问题，我将以下列方式概述：

假设我有一个相当简单和直接的模型。用户、客户、地址、电话号码、订单、产品、类别等...当用户在我的网站上注册新帐户时，我想要： 1）创建一个账户（这只是一个账户ID，客户类型） 2）将他们的客户人口统计数据添加到Customers 3）添加N个地址和地址类型 4）添加N个电话号码及其类型。

就我所知，我需要一个RegisterCustomerForRegistrationControllerViewModel。我的困境是，这个模型应该长什么样子？我试图尽可能地保持DRY，但在实现这种模式时，似乎每次都在重复自己。在哪个级别上放置验证的DataAnnotations？那么，即使我只想在给定的ViewModel中使用类中的一个属性，我是否仍然需要new一个新的Customer()？

我甚至不确定这是否是正确的假设。关于这个主题似乎有很多意见，但很少有具体的实现示例。我希望有人能指导我正确的方向，并在此过程中提供一些代码片段...我希望这一切都足够清楚，如果不是，请随时提出跟进问题。

再次感谢！

- Clayton Bench

Answer 1

在应用程序的两个不同层之间重复简单属性并不违反DRY原则，这只是良好的设计。

DataAnnotations适用于ViewModels。

ViewModel看起来会像这样：

public class RegisterCustomerViewModel
{
    [Required]
    public string Name { get; set; }
    public List<AddressViewModels> Addresses { get; set; }
    public List<PhoneNumberViewModel> PhoneNumbers { get; set; |

} 

- John Farrell

---

这很好，但现在你的UI层中有业务逻辑。你的业务层也需要执行“名称必填”规则，否则当你放弃MVC UI转向下一个UI时，你将失去它。 - Andy

@Andy：你应该在应用程序的每个级别上执行验证。我不认为@jfar有其他意思。 - Andrew Whitaker

@Andy，那不是业务逻辑，那是输入净化，你在UI层面上必须要做的。DataAnnotations属性可以在另一个UI层中使用。在这方面没有限制，并且是为此目的而设计的。 - John Farrell

@Andy，更多的背景是，您不能信任用户输入，但应该能够信任调用业务层的代码。因此，如果名称对于地址原因非常重要，则我可能会再次验证，但通常情况下，您应该能够信任通过UI验证的任何输入。我并不是说如果很重要就不要在两个地方进行验证，只是为了避免过度编码而做出权衡。 - John Farrell

@Andy，我现在明白你的观点了。与其仅仅分离一些关注点并复制一些琐碎的逻辑，不如将你的应用程序核心依赖于第三方框架。过度使用DRY会让你陷入困境。 - John Farrell

Answer 2

就像jfar一样，我会采用简单的方法：一个视图，一个带有DataAnnotations的视图模型。

话虽如此...我知道你的感受（不自信），因为我自己也经历过这种情况。我的结论是：除非你认为你的Web应用程序需要如此多层、原则和模式的开销，否则保持简单。我相信没有完美的架构，只有可行和开销。有时候，可行的确很复杂。问问自己是否需要那种复杂性。

把我的第一句话当作对你问题的回答，其余的则是我的谦虚意见。

- maxbeaudoin