代码之家  ›  专栏  ›  技术社区  ›  Darren Lewis

从模型将DataAnnotation属性应用于ViewModel

  •  2
  • Darren Lewis  · 技术社区  · 14 年前

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

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

    我们如何在不将dry原理抛到悬崖上的情况下,从模型对象和可能被削减的viewModel属性中获取所有这些dataAnnotation属性?

    此外,我们是否正确地认为不应该对从数据库中提取的实体使用TryUpdateModel?我想我们的选择是要么使用TryUpdateModel,然后传递一个属性的排除列表,如果列表只是字符串类型的一个参数,那么这个列表对我来说似乎并不特别优雅。或者我们应该放弃TryUpdateModel,使用像automapper这样更安全类型的工具?

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

    2 回复  |  直到 14 年前
        1
  •  1
  •   Darin Dimitrov    14 年前

    我们如何在不将dry原理抛到悬崖上的情况下,从模型对象和可能被削减的viewModel属性中获取所有这些dataAnnotation属性?

    你不能。这是要付出的代价,但我认为这是相当便宜的,因为事实上,在这个精简版本中,验证属性可能是不同的,根据视图的要求,你可能有不同的验证属性。让我们举个例子: New Edit 查看。在 编辑 视图 Id 新的 视图不是必需的,因为它将由数据存储区分配(事实上,在新模型中甚至可能没有ID属性)。

    此外,一般来说,我只将验证属性放在视图模型上,但这可能不是最佳方法,因为如果您希望在不同的应用程序中重用您的模型,那么它们上就不会有任何验证逻辑。

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

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

    就automaper而言,它是一个必须具备的工具,可以在模型类(出现在存储库方法签名中)和视图模型(传递到视图和从视图传递到视图)之间进行转换。

        2
  •  0
  •   Omar    14 年前

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

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

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

    通过对视图模型进行验证,可以确保传递到业务逻辑层的任何和所有数据都是有效的,并且可以安全地提交更改。