【问题标题】:Applying DataAnnotation attributes to ViewModel from Model将 DataAnnotation 属性从 Model 应用到 ViewModel
【发布时间】:2010-11-24 21:36:46
【问题描述】:

我们将所有的 DataAnnotations 放在我们的模型类 Customer 上。然后,我们将 Customer 的实例作为我们关联的 ViewModel 上的属性以及国家等的一些查找列表公开,并将其显示在我们的视图中。到目前为止一切都很好。

然后我们阅读 SO 和其他来源,我们不应该将我们的整个客户模型对象传递给视图,因为只为视图提供它需要的最低限度,更重要的是(对我们而言)防止可能当 ModelBinding 潜在的恶意回发添加其他信息以更改视图中不可用的模型属性时出现问题。

我们如何将所有这些 DataAnnotation 属性从模型对象中取出并放到可能被削减的 ViewModel 属性上,而不会将 DRY 原则抛到悬崖边上?

另外,我们认为不应该对从数据库中提取的实体使用 TryUpdateModel 是否正确?我想我们的选择是使用 TryUpdateModel 并传递一个排除属性列表,考虑到该列表只是字符串类型的参数,这对我来说似乎不是特别优雅。或者也许我们应该取消 TryUpdateModel 并使用诸如 AutoMapper 这样更安全的工具?

感谢您对这些问题的任何想法。

【问题讨论】:

    标签: asp.net-mvc data-annotations validation mvvm


    【解决方案1】:

    我们如何将所有这些 DataAnnotation 属性从模型对象中取出并放到可能被削减的 ViewModel 属性上,而不会将 DRY 原则抛到悬崖边上?

    你不能。这是要付出的代价,但我认为它很便宜,因为实际上在这个精简版本中,验证属性可能会有所不同,并且您可能会根据视图的要求具有不同的验证属性。我们举个例子:NewEdit 视图。在Edit 视图中,实体的Id 将是必需的,而在New 视图中则不需要,因为它将由数据存储分配(实际上在您的新模型中甚至可能没有Id财产)。

    另外,通常我只将验证属性放在视图模型上,但这可能不是最好的方法,因为如果您想在不同的应用程序中重用模型,它们上不会有任何验证逻辑。

    另外,我们认为不应该对从数据库中提取的实体使用 TryUpdateModel 是否正确?

    我个人从不使用TryUpdateModel。我更喜欢将视图模型作为控制器操作参数传递,并让默认模型绑定器完成这项工作。在这种情况下,您当然不需要任何包含或排除属性列表,因为此视图模型完全适合给定视图。

    就 AutoMapper 而言,它是在模型类(出现在存储库方法签名中)和传入和传出视图的视图模型之间进行转换的必备工具。

    【讨论】:

      【解决方案2】:

      我发现仅在 ViewModel 上放置验证属性并单独保留模型对象是最好的方法。

      当用户发布任何数据时验证视图模型,如果数据有效,则业务层会使用用户发送的数据在数据库中创建对象模型。

      在服务/业务层类中,更新或添加的函数只接受对象模型(字符串、整数等)的必要值,而不接受整个对象。服务类负责创建对象。

      通过在视图模型上进行验证,您可以确保传入业务逻辑层的所有数据都是有效的,并且您可以安全地提交更改。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2014-04-12
        • 2011-08-26
        • 2019-01-13
        • 2021-11-09
        • 2023-04-07
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多