【问题标题】:is this a good idea to implement validation in entity framework POCO entities in dabtase first?这是首先在数据库中的实体框架 POCO 实体中实现验证的好主意吗?
【发布时间】:2013-07-22 20:51:28
【问题描述】:

似乎实现验证的最佳位置是尽可能靠近数据库,所以当我使用实体框架时,最近的对象是实体,在我的例子中是 POCO 实体。

这样做的原因是,如果我想重用这个 POCO 实体,验证是在 POCO 对象中实现的,那么在数据库中插入磨损数据的可能性就会减少。

这也避免了有人试图在创建另一个应用程序的数据库中插入不正确的数据,或者因为他没有实现验证。所以更安全。

一种方法是使用扩展 POCO 实体并实现 IValidatableObject 接口并返回验证结果列表的部分类。

但其他方式如下。我有一个通用程序集,它具有以下内容:

  • 一个接口,声明需要实现存储库的方法。
  • 存储库将使用的 POCO 实体。
  • 一个具有实用程序的类,例如复制实体和验证实体数据的方法。

然后我可以创建许多使用不同版本的 EF 或其他技术的存储库,并且它们都使用通用程序集。此存储库使用公共库中的方法实现验证。

在这种情况下,我只执行一次验证。唯一的问题是存储库需要调用方法来验证数据。

但在我看来,这种方式有优势。例如,我可以根据操作的类型来验证实体的数据。例如,如果我要添加一条新记录,并且主键作为自动数字,如果 ID 不是 0,那么我可以抛出异常,或者如果我尝试在 ID 为 0 时删除一个寄存器,那么我不会'不需要将命令发送到数据库。

所以第二个解决方案解决了尽可能靠近数据库实现验证的问题,因为在存储库中使用了存储库,即访问数据库的元素,但存在如果某些开发人员创建新的问题存储库而不使用验证方法,我可能在数据库中有不正确的数据。

所以我的问题是,最好的选择是对部分类使用验证还是使用公共库并在存储库中实现验证,这才是用户真正会使用的。

谢谢。

【问题讨论】:

    标签: validation entity-framework-4 repository repository-pattern


    【解决方案1】:

    好的-唷,大问题。我的观点是,应用程序的 APPLICATION DOMAIN 是一切的老板。数据库只是一个附加服务。因此,应用程序域最终应该验证在某处发送的所有对象。无需验证从数据库中出来的对象,因为它们已经过验证。

    例如,如果您要创建一些需要发送到 Web 服务并且需要验证的对象,该怎么办。可以说它永远不会靠近数据库或存储库。一旦验证了 DOMAIN 业务对象,就可以将它们发送到持久性或其他任何地方。

    要考虑的另一件事是验证的含义。这是否意味着数据类型正确?这是否意味着业务对象有效?这是否意味着业务对象在给定的上下文中有效?它可能意味着所有这些东西,也可能只是其中的一部分。

    例如,如果您的系统允许用户部分更新记录(常见于很长​​的输入表单),该怎么办。业务对象可能仅在捕获所有所需数据时才有效,但数据库允许“部分”数据的持久性。换句话说,您可以将业务对象保存到数据库中,尽管它还不能用于进一步处理。等等等等……

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-01-10
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多