I have lots of MVC validation attributes on my model. Everything works great when the defaultModelBinder binds my model on submit. But, I need to create a custom modelbinder. I'd like to continue using my validation attributes. Can I? If so, how?
I'm not sure whether this is possible or not, but one thing I can say is that if it is possible then the extension points for default model binder don't make it very discoverable. I spent several hours one day trying to get this to work to no avail.
In lieu of getting this to work, you can use the Controller's TryValidateModel() methods.
Related
would it be considered a valid implementation if I do not use the model for certain parameters? For example a webform posting values directly to the controller which then passes them to another class. Is it necessary to make sure that all the fields in the webform are also referenced/stored in the model?
I consider it a valid implementation, but suggest that you do this only if the parameters you want to exclude from the Model are absolutely NOT going to be used by the View (other than for confirmation of data entry in your webform), AND there is no need for the parameters to be referenced again once handled by the Controller.
Yes, it would work, strictly speaking.
However, you probably want to use the model. You don't want to create a new variable every time you run the view, which would happen if you use the controller.
I would consider it valid implementation if you decided not to use the model for certain parameters. I believe there are instances where certain fields may not relate directly to the model in question therefore giving valid reason to break those fields/parameters off from the model.
I have a project where the data-model and business-layer are located in two different modules. Of course, the bussiness-module has a dependency to the model-module. The entity-validation is implemented through java-validation-api annotations.
I'm wondering where I should implement the cross-entity-validation (business validation, where the relations between different entity types are validated). Currently I see the follwing options:
Create custom javax.validation.ConstraintValidators and associated annotations. Problem is, that the validator would need access to the business-services, i.e. to retrieve related entities, but the model-module should not have a dependency to the business-module.
Implement cross-entity-validation in the business-services persist/merge-methods (i.e. by using interceptors). That would be possible, but the cross-entity-validation is seperated from the entity-validation and I would like to have only one place for validation.
Which option is preferable? Are there any better suggestions?
Thanks,
Sebastian
From the ideological point of view approach 1. is better. Bean Validation is working at the level of Model (in Model-View-Controller) and it is nothing wrong if Model part talks to database. So, for instance, you can create DAOs, which can be used both by service leayer and Model validators in order to avoid code duplication.
Interceptors are also good place to validate something, but you will not be able to use full power and automaticity of Bean Validation. Probably you will need to call validate method on your model objects by hand, throw ConstraintViolationException where needed, etc. Doable, but a little bit of work. In addition some validation probably will be left in Model, so, as you've pointed out, there would be more then one place, where validation is going on.
So I would move necessary DB code to separate layer and go with option 1.
Are there any frameworks or built in mechanisms to perform validation on properties of either model classes or view model classes in WP7?
Ideally I don't want to setup NotifyOnValidationError=True,ValidatesOnExceptions=True and BindingValidationError on every single property in the view and perform switches in the code behind for the property name.Also I would prefer to have the validation logic in either the VM class or the Model class and not the code behind.
Also I would prefer to have the validation logic in either the VM class
IDataErrorInfo is also applied to the view-model. If you're exposing data models directly to the view, you're doing it wrong in the first place.
There's probably some frameworks, if you bother looking for them, but there's nothing extra build-in, than the validation methods you already know (IDataErrorInfo).
I'm currently trying to programmatically insert a ModelClientValidationStringLengthRule ModelValidator via a custom attribute, and wishing to avoid adding to the AdditionalValues dictionary in order to make use of existing functionality.
This is due to using a CMS, and wanting to control the length of the string via the CMS rather than within a model.
I assume I would do this in the OnMetadataCreated event in the custom attribute, however I cannot see how to add to the ModelValidator collection, only get them via GetValidators...
Anyone have any ideas?
Thanks in advance,
Dave
Rather than adding a custom attribute, you want to inject a validator based upon a condition.
You can use the class I detail in this answer to inject your validator based upon the conditions in your CMS.
How do you validate an entity containing DataAnnotations without using the MVC library? Using Model.IsValid is fine when you're within the Presentation layer, but what about when you want to ensure the model is valid in the Domain/Business layer? Do I need a separate validation framework, or is there an easy way I'm missing?
Thanks for any help,
Mark
I suppose you mean ModelState.IsValid by Model.IsValid, right? Well, DataAnnotions don't depend on MVC at all, so you can always use the IValidatableObject interface.
Or perhaps the Validator class will be more appropriate, by using Validator.ValidateObject(object, ValidationContext).
I wrote my validation logic using plain c#, my business layer contains these validations and I use try and catch blocks throughout business layer. The presentation layer catches these custom exceptions so errors are shown on screen to the user. I only kept basic validation inside the data annotations e.g. [Required] mainly for ajax calls and to notify users to enter data in non nullable fields, that way my business logic remained in my middle tier, it remained consistent, it remained in only one place which I can refer to.