What technique or library do you recommend for on-screen validation. That is, validation that is very visible to the user.
My requirements:
The validation must have a way to indicate to the user which fields have a problem.
The validation must have a way to indicate to the user how to fix the problem.
The validation must support comparatives like TextboxA > Textbox B.
The validation must support custom logic like "If CheckBoxC is checked, ListBoxD must be empty".
Sometimes, though not always, the user can save a record even though validation fails.
A combination of using IDataErrorInfo and ValidationRules should meet all of your criteria.
1 & 2 - can be handled easily using the standard WPF validation display techniques. For background info, I'd read Josh Smith's MSDN article, in particular, he shows a couple of ways to handle displaying validation information.
3 & 4 - can be handled easily via IDataErrorInfo. This interface lets you do any logic required in order to display validation, and can combine multiple properties in the validation rules.
5 - This is a matter of just tracking which rules prevent saving, and which do not. You'll need to handle this directly, but again, IDataErrorInfo can help here, since you can use a known set that allow saving, and have every other issue prevent it.
For simple cases, Validation Rules make life easy. They can be combined with IDataErrorInfo, however, for a nice mix of simple with extended logic for difficult cases.
You might find the BookLibrary and EmailClient sample applications of the WPF Application Framework (WAF) interesting. They use the IDataErrorInfo interface in combination with the .NET DataAnnotations attributes to define the validation rules.
Related
In my MVVM based application I need to validate fields in a data entry from. If possible, I would like to use the standard WPF validation binding with ErrorTemplates.
However I would like the execution of the validation logic to be completely driven/triggered by the ViewModel (push to the View, not pull by the View) for the following reasons:
It must work asynchronously because validation logic might take a while to execute.
I need to be more deterministic and fine grained when validation logic is to be executed (e.g. only after the user clicks "Apply" or when the internal state changed in a way that entries suddenly become invalid)
I know Silverlight has INotifyDataErrorInfo which was introduced for exactly this purpose, but WPF doesn't. How can I still have my validation logic exectuted deterministically and asynchronously?
I posted an answer on your other question that apparently answered this one too.
Create a visualtree off of a control template in code
The built in validation for WPF and Silverlight is meant for quick client-side validation (such as Regex, parsing values, etc.).
If you need to go to a server to perform validation (or validation takes a long time), I would do that in a custom way. Such as when clicking a save button, etc.
So say you have a Save method in a ViewModel (you don't mention which MVVM framework you use):
public void Save()
{
//Do your validation, this might start a new thread (I use Async CTP myself)
//If validation is good, do your extra work, else display validation errors
}
I would just do all the work required for this within an action in your ViewModel
When looking up tutorials for the best practices to do property validation in WPF MVVM I see a lot of people use the interface IDataErrorInfo I was just wondering if it is possible to setup automatic validation like that used in ASP .Net MVC using attributes?
Can anyone sugest what the best practices are for model validation in MVVM? Should the validation be on the base model class? or on the view model class?
Silverlight has a control called the DataForm that works using the DataAnnotations Attributes and someone was kind enough to port that control to WPF. I believe that is something along the lines of what you're looking for.
These are good questions!! Validation belongs in BOTH the Model and the ViewModel(s). Here is how I usually approach it:
First I put as much validation in the Model as I can - these will be rules that are independent of a given presentation. For example, assume an employee in your domain is not valid if it doesn't have a EmployeeNumber property that is not null, and six characters in length, and each of the six characters must be a digit.
Secondly, I have a base ViewModel class that implements IDataErrorInfo. In this base class I basically ask the Model if it is valid, triggering an error if it isn't (which is easy to translate to the View by virtue of IDataErrorInfo). I also make the implementing methods of IDataError info virtual, because...
Lastly, there will be edge cases unique to a given presentation that cannot be captured by the Model. For a (contrived) example, assume you have one presentation in which an employee is valid if only his first and last name are entered, and another that requires a middle initial as well. While you certainly can and should have a FullName component / valueObject property in Employee to validate that the property is not null, you need a subclassed ViewModel for each presentation to know if the user entries for the properties of the Fullame are valid in this case.
Finally, you can and should use a Validator for your Model validation - I like NHibernateValidator but there are certainly other (very) good ones available. Most of them, including NHibernate's, will support the attribute validation you are looking for. I prefer a cleaner alternative to attributes however, whereby I setup all validation rules for my validator in a separate project (ie, MyDomainImpl). Cleaner in the sense of less noise in the Model, and a cleaner separation of concerns.
Feel free to ask questions if you need to Also give yourself some time to work thru this until you have an approach that works for you - this is not a trivial topic.
HTH,
Berryl
My take is that validation should be on ViewModel and not on Model because :
Validations are for incorrect input
and the first logical point of UI is
ViewModel. It is good practice to
validate and stop request at
ViewModel and not send across invalid
data to the Model
Also many a times Models are legacy and the assumption is that they
cannot be modified. ViewModel creates
a good wrapper over the model.
If you are using any Dependency Injection tool for your aplication like Unity, Windsor Castle etc., you can use interceptors to validate ViewModels. Interceptors are invoked first before any call to ViewModel methods.
An example of using interceptor with Castle can be found here -
http://www.castleproject.org/container/documentation/trunk/usersguide/interceptors.html
Where to put the validation logic?
Software systems mostly need some kind
of validation to ensure that the
business logic has to deal with
correct data only. These validation
rules are defined by the business
model and so the Domain layer is the
right place to implement them. Just
keep in mind that you don’t start to
duplicate the validation code between
the business objects.
link
.
You might be interested in the sample applications of the WPF Application Framework (WAF). They show how to use the .NET DataAnnotations validation attributes together with the MVVM pattern.
As a new WPF programer I cant find the difference between two different way to validate user input:
What are the pros and cons of writing custom validation rule against implementing IDataErrorInfo, and vice versa? WhenShould I prefer one over the other?
Update:
Though I got my answer already, I found related article that may help others.
Basically, if you implement IDataErrorInfo, validation is implemented in the bound object, whereas if you implement validation rules, validation is implemented in objects attached to the binding.
Personally, if you're using MVVM, I think you'd have to be crazy to ever use anything except IDataErrorInfo. You want validation to live in the view model. If it's in your view model, it's centralized and it's testable. If it's in your view, then your validation logic can be wrong, or missing, and the only way to find it is by manually testing your view. That's a huge potential source of avoidable bugs.
There are places where it makes sense to use validation rules - if, for instance, you're building a UI around dumb objects (an XmlDataSource, for example). But for most production applications, I wouldn't go near it.
IDataErrorInfo
Validation logic keep in view model and easy to implement and maintain
Full control over all fields in the viewmodel
Validation Rule
Maintains the validation rule in separate class
Increase re-usability. For example you can implement required field
validations class reuse it throughout the application.
My opinion is, for common validation like required field validations, email address validattions you can use validation rule. If you need to do custom validations like range validations , or whatever custom validation use IDataerrorinfo.
You implement IDataErrorInfo to be able to use databinding with eas. You still build your custom validation rules.
I am creating a WPF app using MVVM. The app manages tagged documents, called Notes, similar to blog posts. A Note has a Title, Text and a Tags collection. I want to validate a Note at the time it is submitted for two validation rules:
The Title can't be empty; and
The Note must have at least one Tag.
If validation fails, then the Note submission is canceled, the offending control in the UI should get the familair red outline, and a tool tip should explain the error. This all seems pretty straightforward if one wants to validate at the time a WPF control updates its binding source. Just create a custom ValidationRule and add it to the <Binding.ValidationRules> collection.
My problem is that I want to validate when the Note is submitted, not when controls update their binding sources. I know I can create a custom error message and display it in a MessageBox, but I would much rather use the red outline-tooltip approach--it's less intrusive. I figure there must be some simple way of doing this.
My question is pretty simple: What is the best way of performing on-submission validation in WPF/MVVM? How does my code instruct the UI to show the red error outline when validation fails? Thanks for your help.
One option is to use IDataErrorInfo in conjunction with WPF.
This would make it fairly easy to handle this scenario. You can just setup the IDataErrorInfo information at submission time, which would then cause the "red outline" (or other error theming) to appear.
In good old MFC, the DDX routines would have built in validation for form entries. For example it was possible to automatically check if the user entered a string in a text box meant for numeric input.
Is there any such mechanism in Winforms? Obviously one can add handlers for the 'onChange' etc kind of events and do the processing there, but I am asking if there is any built-in mechanism.
thanks
You could certainly implement your own ValidatingTextBox with a Regex property which is validated, essentially, whenever you decide you want it to be validated (keystrokes, Enter key, loses focus, ...)
At the simplest level there are Validated and Validating events on the plain TextBox that you can supply handlers to for individual instances.
There have been a couple of attempts to replicate the richer ASP.NET validators on Windows forms. Check out this one by Billy Hollis
No, I don't believe so, but you can easily derive a custom textbox that applies the kind of validation you require based on a parameter or property you set on its instance. Then you'd have a built-in mechanism. ;-)