【问题标题】:Code First Fluent API validation not workingCode First Fluent API 验证不起作用
【发布时间】:2012-04-20 07:31:16
【问题描述】:

有一个类——它是一个普通的类,没什么特别的:

public class Trader{

public Guid UserId {get;set;}
public int TraderId { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string PhoneNumber { get; set; }
public string Skype { get; set; }
public string Photo { get; set; }
public string Email { get; set; }

public virtual User User { get; set; }
}

映射:

 public TraderMap()
        {
            this.ToTable("Trader", "General");
            this.HasKey(a => a.TraderId);
            this.HasRequired(a => a.User).WithMany().HasForeignKey(a => a.UserId);
            Property(a => a.UserId).HasColumnName("UserID").IsRequired();
            Property(a => a.TraderId).HasColumnName("TraderID").IsRequired();

            Property(a => a.FirstName).HasMaxLength(50).IsRequired();
            Property(a => a.LastName).HasMaxLength(50).IsRequired();
            Property(a => a.PhoneNumber).HasMaxLength(25).IsRequired();
            Property(a => a.Skype).HasMaxLength(50).IsOptional();
            Property(a => a.Photo).HasMaxLength(100).IsOptional();
            Property(a => a.Email).HasMaxLength(100).IsRequired();
        }

当我在表单(视图)中将 FirstName 或 IsRequired() 的其他字段留空时,验证不会启动。它只是遇到错误:

一个或多个实体的验证失败。看 'EntityValidationErrors' 属性以获取更多详细信息。

不幸的是,这个错误并没有说明太多。我挖得更深了,但我唯一能得到的是

列名鉴别器无效。

我认为这会是某处被遗忘的继承(对于 User 类),但我没有发现任何可疑之处。

问题是当我在 Trader 类中使用属​​性时,一切都按预期工作。

   public class Trader{

    public Guid UserId {get;set;}
    public int TraderId { get; set; }
    [Required]
    public string FirstName { get; set; }
    [Required]
    public string LastName { get; set; }
    [Required]
    public string PhoneNumber { get; set; }
    public string Skype { get; set; }
    public string Photo { get; set; }
    [Required]
    public string Email { get; set; }

    public virtual User User { get; set; }
    }

使用属性验证工作正常,@Html.ValidationMessageFor 开始显示错误消息,它不允许发送 NULL 值。

您对我的映射有什么问题有什么建议吗?

更新 1 其实上面的属性是解决这个问题的一种可能。

【问题讨论】:

  • 你能发布你的用户类和映射吗?
  • 我不明白。显然验证 IS 工作,当您尝试插入空白时,错误是“验证失败”,因此验证工作正常。
  • "基于 Fluent API 配置引发的验证错误不会自动到达 UI,但您可以在代码中捕获它,然后做出相应的响应。"来自msdn.microsoft.com/en-au/data/…

标签: c# asp.net-mvc-3 entity-framework ef-code-first entity-framework-4.3


【解决方案1】:

只有在您使用“数据注释”时才开始验证 - 而 HasRequired 执行映射 - 数据注释属性同时执行映射和验证部分。
即为了验证您的观点,我相信您必须在您的属性上放置注释/属性。

这通常用于在“映射”与映射和验证之间“区分”。即如果你想同时使用属性,如果你只想映射使用流利的配置。

这里也有一个相关的答案https://stackoverflow.com/a/9310435/417747https://stackoverflow.com/a/9789984/417747

编辑:感谢 Justin
How to make Fluent API configuration work with MVC client side validation?

【讨论】:

    【解决方案2】:

    我认为您将 EF 模型验证与 MVC 验证混淆了。 MVC 对 EF 一无所知,反之亦然。它们是独立的技术,可以很好地协同工作。

    当您在流式数据模型上定义验证时,您只是在为实体框架定义验证。这显然有效,因为当您尝试保存更改时,EF 失败并抱怨验证失败。

    再次重申,这与 MVC 验证无关,并且两者在大多数情况下不能一起工作(一个例外是,如果您使用 POCO 类并使用 Data 注释,则某些注释在 MVC 中都有效和 EF,但有些没有。直接在视图中使用数据模型不是一个好习惯,因此这在很大程度上是一个有争议的问题。)

    【讨论】:

      【解决方案3】:

      你们都是对的,我的假设是错误的。

      [Required] 不等同于 .IsRequired()

      有几种可能的解决方案:

      1) 快捷方便Attributes

      模型配置覆盖和验证

      使用 CodeFirst 可以覆盖 使用验证属性定义的模型,例如在 OnModelCreating 方法。重新配置模型会影响验证,因为验证应该 使用实际的模型配置——盲目使用属性会 导致可能有效的值的验证错误 在 OnModelCreating() 中进行的覆盖。这是三个特别的 OnModelCreating 中的覆盖案例:

      • 如果属性用 [Required] 属性修饰并重新配置为可选(.IsOptional() 方法),则 [Required] 属性将被删除并因此在验证时被忽略 发生

      • 如果属性用 [StringLength] 或 [MaxLength] 属性修饰,然后配置了新长度 (.HasMaxLength() 方法)如果可能,将使用新的最大长度

      • 如果属性用 [StringLength] 或 [MaxLength] 属性修饰,然后被定义为允许最大值 长度(.IsMaxLength)然后属性将被删除(如果可能) 并且不会检查属性值的长度

      请注意,上述更改仅在属性为 装饰有一些验证属性。因此,将属性设置为 required (.IsRequired()) 不会导致属性被验证 反对空值。
      EF Feature CTP5: Validation

      2) 快速修复,但正如神秘人所建议的那样,这是一个肮脏的解决方案
      http://thedatafarm.com/blog/data-access/capturing-code-first-fluent-api-validationresults-to-display-in-mvc3-views/

      http://bradwilson.typepad.com/blog/2010/10/service-location-pt6-model-validation.html

      3) 重的The Validation Application Block in Enterprise Library
      http://bradwilson.typepad.com/blog/2009/10/enterprise-library-validation-example-for-aspnet-mvc-2.html 但企业库通常被认为是矫枉过正

      4) 验证必杀技FluentValidation 看起来很有前途,我一定会试一试。
      http://www.nuget.org/packages/FluentValidation.MVC3
      缺点:不是 n 层应用程序中的最佳方法。它主要关注视图。

      5) N层
      http://www.asp.net/mvc/tutorials/older-versions/models-(data)/validating-with-a-service-layer-cs
      这种方法会导致客户端验证出现问题,因此必须单独解决。

      【讨论】:

      • 这不是解决方案。这是一种解决方法。使用异常来处理预期(和常见)情况是非常糟糕的做法。顾名思义,例外就是例外。也就是说,它们应该只在计划外发生的事情发生时才会发生。这是处理问题的一个非常糟糕的选择
      • 嗯,它很好地回答了我的问题,并且讨论中有一个指向 Brad Wilson 的博客 bradwilson.typepad.com/blog/2010/10/… 的链接,这是一个好的开始。
      猜你喜欢
      • 1970-01-01
      • 2014-09-26
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-10-21
      • 2013-03-02
      相关资源
      最近更新 更多