Can I replace some of this with the Fluent Api?

问题

Say I have the following property in a class (where I'm using Code First):

[Required]
[StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
[DataType(DataType.Password)]
[Display(Name = "Password")]
public string Password { get; set; }

I'd rather not decorate my Password property with these annotations. I'd rather use the Fluent Api if possible. How many of these annotations could be done using the Fluent Api? I know Required can be, and StringLength. But I don't know about ErrorMessage, DataType and Display.

回答1:

I know Required can be, and StringLength.

And that's all.

Keep in mind that the same attributes can be used by different "frameworks" and for very different purposes. If you use - for example - the Required attribute in a context of ASP.NET MVC it will be used for MVC model validation - on client side by some Javascript injected into the page or on server side to set ModelState.IsValid.

The Required attribute is also used by Entity Framework Code-First to validate an entity, but this has actually nothing to do with the MVC model validation. If you replace the Required attribute by configuration with Fluent API you still influence Entity Framework, but for ASP.NET MVC you just have removed the attribute, i.e. the property is not required anymore for MVC validation. ASP.NET MVC doesn't care about Entity Framework's Fluent API.

The same is true for StringLength. ErrorMessage, DataType and Display play no role with Entity Framework, neither as attributes nor are there counterparts in Fluent API.

回答2:

I take the View:

a)Decorate the POCO with genuinely useful business constraints. MVC and EF amongst others will check a few of the important constraints for You.

b) You can and should add checking for custom Annotations or other business rules to the POCO. see sample bloew if interested:

c) DB specific annotations belong in EF fluent API. If they are DB specific that dont belong on the POCO in my view. Eg Table name, schema, Foreign key, association maps, column renames and ignores etc.

d) Error messages and Display texts belong on the Model View.Or at least abstracted from teh POCO example below. I know people dont like double effort and will use POCO as Model views and like easy text and error message handling. But I prefer a full error message/text handling solution that is multi-lingual and configurable. Sticking texts on a POCO, isnt the best solution in my view.

Clearly style and build size influence the choice and many will disagree with d) and I dont have a big issue with that . Im taken a big picture design pattern view and look to separate and abstract where it makes sense.

here a little POCO extra sample, not with annotations but it could have been. I have seen some nice examples with annotations as well. This style of error can be used in MVC and is better than texts in annotations in my view.

     public class POCODemo : IValidatableObject //various ways to trigger this. Some for free

    /// poco members .... bla bla


   //Support Business rules...
    public override IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        var vResult = base.Validate(validationContext).ToList();


        if (Poco.property1 || poco.property is nasty or xyz issue)//psuedo code for your check

                var memberList = new List<string> { "PropertyName1" };
                var err = new ValidationResult("Some Text comes from your TEXTPOOL of choice that explains the error", memberList);
                vResult.Add(err);
           // }

        }

        return vResult;
    }

来源：https://stackoverflow.com/questions/14903509/can-i-replace-some-of-this-with-the-fluent-api