For a small inhouse app that requires login, you can even rely on client side validation. If users want to put in garbage by composing invalid requests they'll get what they asked for.
Ofcourse most applications are not like that.
Some middle ground between the two scenarios you described wout be to create Command objects or Services. In the controller you make it such that you can easily translate user input to command input, safely. Validation goes to the methods in your Service or your Command. You can return a Result object indicating success or any validation errors. Or throw exceptions if you so prefer.
Now your validation resides in the code, where you have better tooling to validate. But also it doesn't clutter the controller.
To be honest I still struggle at times not to duplicate validation. I want it client side, but it should also be enforced in the domain. If anyone knows how to do a decent job avoiding that I'd be interested to learn.
I typically resign myself to duplicating validation. I think this is ok (but annoying), because really validation is for a different purpose. UI validation is to help the user make the right choices. API validation is to make sure that requests off the wire make sense. They are often so close that literally the same validation could be used, especially in CRUD scenarios. But I do sometimes find variances where if I had applied DRY it would be harder than just validating separately. It is a fine line. :/
UI Validation does not cover all the validations necessary. So, it's pretty common to have them "redundant" through deeper layers.
Example: "name" is mandatory for the UI to have a quick feedback to the user about his small mistake leaving it empty, but the API almost must have this validation as well. But then, suddenly, a wild mobile app appears, and you need to implement this validation again for offline use!
Yep, it's one of those areas where there are significant trade-offs to set it up in a unified manner. It will be worth it in some cases (especially where you have a lot of different clients) but not in others.
I dont know what language and platform you use, but ASP.NET has a nice solution for that. They call this "data annotation validations". You simply put the rules in a ViewModel, and they will be checked both client side and server side. This way, you could simplify the jquery.validate (client side), and in your controller, check them with Model.IsValid (server side)
Indeed, but this is more like a backup for when the client has disabled JS.
What if you want to use Angular + .net API? Anyway you need to duplicate validations. :)
It's really hard to do a 100% business app, beyond CRUD using plain ASPNET MVC.
I second that. Data annotation validations work well for a CRUD type of feature, less so for relational constraints.
I'm working on this domain where computers are leased to customers. In order to record a dispatch, many fields have to be filled in. But there's rules about field values that limit the valid options for other fields. I implemented just the basic ones.
The real challenge would be formalize the rules in such a way you can get the most efficient decision tree in the UI as well being able to validate command input :)
For a small inhouse app that requires login, you can even rely on client side validation. If users want to put in garbage by composing invalid requests they'll get what they asked for.
Ofcourse most applications are not like that.
Some middle ground between the two scenarios you described wout be to create
Command
objects orServices
. In the controller you make it such that you can easily translate user input to command input, safely. Validation goes to the methods in your Service or your Command. You can return a Result object indicating success or any validation errors. Or throw exceptions if you so prefer.Now your validation resides in the code, where you have better tooling to validate. But also it doesn't clutter the controller.
To be honest I still struggle at times not to duplicate validation. I want it client side, but it should also be enforced in the domain. If anyone knows how to do a decent job avoiding that I'd be interested to learn.
Agreed! And validation goes harder when your client has offline capabilities D:
Offline capabilities... May the force be with you :)
I typically resign myself to duplicating validation. I think this is ok (but annoying), because really validation is for a different purpose. UI validation is to help the user make the right choices. API validation is to make sure that requests off the wire make sense. They are often so close that literally the same validation could be used, especially in CRUD scenarios. But I do sometimes find variances where if I had applied DRY it would be harder than just validating separately. It is a fine line. :/
Good to hear it's not uncommon to have duplicate validation :) Thanks for sharing your insight.
UI Validation does not cover all the validations necessary. So, it's pretty common to have them "redundant" through deeper layers.
Example: "name" is mandatory for the UI to have a quick feedback to the user about his small mistake leaving it empty, but the API almost must have this validation as well. But then, suddenly, a wild mobile app appears, and you need to implement this validation again for offline use!
Yep, it's one of those areas where there are significant trade-offs to set it up in a unified manner. It will be worth it in some cases (especially where you have a lot of different clients) but not in others.
I dont know what language and platform you use, but ASP.NET has a nice solution for that. They call this "data annotation validations". You simply put the rules in a ViewModel, and they will be checked both client side and server side. This way, you could simplify the jquery.validate (client side), and in your controller, check them with Model.IsValid (server side)
msdn.microsoft.com/en-us/library/e...
Indeed, but this is more like a backup for when the client has disabled JS.
What if you want to use Angular + .net API? Anyway you need to duplicate validations. :)
It's really hard to do a 100% business app, beyond CRUD using plain ASPNET MVC.
I second that. Data annotation validations work well for a CRUD type of feature, less so for relational constraints.
I'm working on this domain where computers are leased to customers. In order to record a dispatch, many fields have to be filled in. But there's rules about field values that limit the valid options for other fields. I implemented just the basic ones.
The real challenge would be formalize the rules in such a way you can get the most efficient decision tree in the UI as well being able to validate command input :)
Thanks for the advice, it's ASP.Net MVC indeed :)