I have an entity framework generated Model. When the model is initially created I only want to require a few properties, but afterwards I want to require a few more. Is there any notion of validation groups or conditional validation attributes that would help me here?
I tried writing a custom conditional validation attribute that would just take another validation attribute in its parameter and just encapsulate other validation attributes but I get compiler errors saying "An attribute argument must be a constant express, typeof expression or array creation expression of an attribute parameter type"
Any idea how to accomplish this?
I have an entity framework generated Model
That's nice but not something that controllers should pass and take from views. In order to decouple the domain entities which, in theory, should be reusable among different applications from the way those entities are presented on a given view you could use view models. Those are classes which are specifically designed to the requirements of a given view. Thus you could have a CreateFooViewModel and UpdateFooViewModel both representing some domain model but of course with different validation rules (as validation rules differ between your views) and different formatting rules and properties selection. In order to ease the mapping between your view models and domain models you could use AutoMapper.
Related
I've heard about different ways to write validation for domain models, So I want to know which of them is better in the domain-driven-design.
Some people say that it's better to validate the domain model's data before initializing it (it means that validations should be run on the related DTOs).
Some people say that it's better to validate the domain model's data after initializing it (it means that validations should be run on the initialized entity or domain model).
Also, some people say that all the validations should be run inside of the entity (exactly in setters or constructors)
Indeed, I was used to writing a combination of the above validations, but now I'm not sure about that. Which of them is common and basically more sensible?
In domain driven design, what you are most likely to see are "value objects" that guarantee certain constraints are met during initialization, therefore in the constructor of the value object itself. Since values are (by convention) immutable over their lifetime, you wouldn't normally include setters in their interface.
DTOs serve a different purpose, but are mechanically similar to value objects in many ways. So you might see validation in the DTO in addition to validation within the domain model.
You don't normally have value validation in your entities. An entity is typically holds references to values (which validate themselves) or other local entities (validated elsewhere), so checking that the references are correct is in bounds (ie, check for null).
There might be a similar question already or phrased a little bit differently, but I was just wondering if there any valid reasons to use Data Annotations in MVC Models rather then for Model Validations and Code First approach?
The reason I'm asking is that I have a Report page that will never be used for editing, validations and Code First approach
I have created a ReportViewModel where I declared my ReportModels that represent different sections of the report.
I also have a Server Entity that maps the values to the particular Report Model and then the Report Models' properties gets mapped to the view.
Does that make any sense to use DataAnnotations with Report Models at all, if I do not use any editing logic with my report?
Can I just declare properties on my ReportViewModel and map Server Entity data directly to those properties without using Report Models?
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).
In Model-View-Presenter pattern where should we write validations of user input.
Domain specific rules/validations should be in the Model. You can have a model.validate() to let you know if the rules are not violated. Look at Rails model (ActiveRecord) classes for a good implementation of this concept.
The View should make it difficult for the user to key in invalid input. So 'entering a string for a numeric value' class of input errors should be nipped before reaching the presenter.
There may be some duplication of validations between model and view. E.g. AttributeX must range between 1-100. This must be validated in the model.. at the same time you may want to slot in a spinner in the UI with the minValue and maxValue range set to 1-100.
I usually keep my view completely clean, no logic there. But I don't do a lot of web development. In Ajax-ish situations you might want to have client side validation that has to go in the view.
Business logic validation goes in the model. With business logic validation I mean things like checking minimum order size etc.
Input validation goes in the presenter. This can be things like checking if a number field doesn't contain non numeric characters. But depending on your situation this can also mean checking if files exist etc.
In more complex cases where validation should be reusable in different places I usually separate it into a validation engine that can be called in different places. This solves some problems with duplicating validation code that is used in the presentation layer as well as the persistence layer for example.
Presenter....
The view should have have "widgets" that prevent invalid input where possible.
In coding a traditional MVC application, what is the best practice for coding server-side form validations? Does the code belong in the controller, or the model layer? And why?
From Wikipedia:
Model-view-controller (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the model represents the information (the data) of the application and the business rules used to manipulate the data; the view corresponds to elements of the user interface such as text, checkbox items, and so forth; and the controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.
Thus, model - it holds the application and the business rules.
I completely agree with Josh. However you may create a kind of validation layer between Controller and Model so that most of syntactical validations can be carried out on data before it reaches to model.
For example,
The validation layer would validate the date format, amount format, mandatory fields, etc...
So that model would purely concentrate on business validations like x amount should be greater than y amount.
My experience with MVC thus far consists of entirely rails.
Rails does it's validation 100% in the Model.
For the most part this works very well. I'd say 9 out of 10 times it's all you need.
There are some areas however where what you're submitting from a form doesn't match up with your model properly. There may be some additional filtering/rearranging or so on.
The best way to solve these situations I've found is to create faux-model objects, which basically act like Model objects but map 1-to-1 with the form data. These faux-model objects don't actually save anything, they're just a bucket for the data with validations attached.
An example of such a thing (in rails) is ActiveForm
Once the data gets into those (and is valid) it's usually a pretty simple step to transfer it directly across to your actual models.
The basic syntax check should be in the control as it translates the user input for the model. The model needs to do the real data validation.