How can I collect model validation error messages?

I am building an ASP.NET MVC application, and I am trying to find a way where I can collect data from the user in a custom view model, try and set these values to one or more of my entities, then based on validation logic on those entities, collect error messages if any and get them back to the view. I am new to MVC and web design in general, it is therefore quite possible that I am making major conceptual errors, but I have tried to research as far as I开发者_如何学C could.

I realize that this is more work than having the view be strongly typed to the entity, where it would then be easy to have the validation errors display, as in this tutorial. However, I don't want to do this for security and because there are some places where I want to have values collected from a single view model to be set in multiple different entities.

I also realize that I could set validation rules on the view model itself, rather then on the entity, but this seems like poor architecture, as I would have to define them redundantly in different view models, and I would then be less sure whether I had prevented bad values from being persisted to the database.

My plan is therefore to have the validation rules be set on the entity itself and to have the view model as a dumb container. Then, in a different location in the application, I would apply the values from the view model to my entity(ies) in accordance my business logic. At this point, I would like my validation logic to be called. If the data is invalid, I plan on setting the error string in the custom attribute on the view model to the error from the validation logic on the entity. I am thinking it would go something like this:

public class CustomViewModel()
{
    [SomeCustomValidation()] //Has a place for an error string and a boolean IsValid
    String Property { get; set; }
}


public class BusinessLogic()
{
    CustomViewModel TestForValidity(CustomViewModel viewModel)
    {

        MyEntity.Property = viewModel.Property;
        // if(MyEntity.IsValid)?  catch SomeSortOfException?
        // collect error message, put it in the attribute on the view model, set IsValid to false
    }
}

public class MyEntity()
{
    [MoreCustomValidation()]
    public String Property { get; set; }
}

I therefore have three questions:

1. When I try to pass data that does not satisfy my validation rules, will some sort of error or exception be thrown? Is there some indication I can use or collect when I try to pass in invalid data?

2. If there is some error or exception thrown, how can I collect the error message so I can assign it to my view model?

3. Most importantly, am I going about this all wrong? Can attributes not be modified at runtime, for example to include a new error message or to change IsValid to false? I know that I can use reflection to access the attributes. If I can modify them, how would I do so?

Thank you in advance for your help. I apologize if I misunderstand something big.

It seems you might be over-complicating things a bit. I think what you want to do is prevent the model binder from binding to properties that it should not be able to, as well as retaining the ability to check ModelState.IsValid when properties on your model do not meet the requirements of their validation attributes.

IMO the best way to accomplish this is through the use of what I call "strongly-typed binding filters". First define an interface with only the properties that you want the model binder to be allowed to bind on your model.

public interface INewBlogPost
{
    string Title { get; set; }
    string Body { get; set; }
}

Then ensure your entity inherits from the binding filter interface.

public class BlogPost : INewBlogPost
{
    ...
}

Next, modify your action method to create a new entity and manually invoke the model binder whilst typing it to the interface you just defined.

public ActionMethod NewBlogPost()
{
    BlogPost newBlogPost = new BlogPost();
    TryUpdateModel<INewBlogPost>(newBlogPost);
    if (ModelState.IsValid)
    {
        ...
    }
}

Because you passed in a type when invoking the model binder via TryUpdateModel you explicitly told the model binder what type to bind to. This means that the model binder will only have access to the properties listed in the interface. Now when you pass a model into the method to be bound it will have to be of type INewBlogPost. Because your entity inherits from your binding filter interface, an instance of it will satisfy this requirement. The model binder will happily bind to the properties on the interface completely oblivious of any other properties your model object may have.

See this blog post for more information.

Aside

It is sometimes easy to run into action method ambiguity when you have two action methods with the same name; one for POST and one for GET like this:

[HttpGet]
public ActionResult NewBlogPost()
{
     return View();
}

[HttpPost]
public ActionResult NewBlogPost()
{
     BlogPost newBlogPost = new BlogPost();
     TryUpdateModel<INewBlogPost>(newBlogPost);
     if (ModelState.IsValid) { ... }
}

An easy way to fix that is to modify your POST action method to look like this:

[HttpPost]
public ActionResult NewBlogPost(FormCollection formCollection)
{
     BlogPost newBlogPost = new BlogPost();
     TryUpdateModel<INewBlogPost>(newBlogPost, formCollection);
     if (ModelState.IsValid) { ... }
}

The MVC model binder knows how to bind the request form collection to an argument of type FormCollection so it will populate this just fine. Because your POST action now accepts an argument, it is no longer ambiguous with your GET method. You can pass this formCollection into TryUpdateModel to be used as the binding source if you wish, but you don't have to as it will default to the request form collection anyway. But since you are passing it in you may as well use it :)