The simple answer is:
It depends on how you have your application laid out and who the code will be used and reused by.
The long answer could be:
Client side validation, View Model validation, Model validation can all be performed at different points within your application and serve specific purposes depending on how you use/reuse your code. More below...
Model validation
I assume by this you mean the validation of models that are mapped to and sent to your service layer for processing? I'll assume yes for now...
If your service layer is only used by a single application (your application) and will never be reused by another application or by another developer, web/windows service or other, then you may be able to get away with not having validation in your service layer and you can rely purely on your View Model validation to protect your service layer. This is because there is only a single point that data will be coming and hitting your service layer.
However, if your service layer will be reused by another application or used by another developer it's helpful to perform the validation checks in there because it means that your service layer is bulletproof will provide other developers that use your service methods with useful validation information.
Bare in mind that if you don't add validation into your service layer and you ever want to allow other's to use it at a later date, you will need to go through and add the validation and this could be more difficult and time consuming at a later date. Your best bet is to build up the validation in your service layer as you're going along.
View Model validation
If you have decided at this point that you're not going to perform validation in your service layer, or that you need to perform validation that is specific to one or more pages or the service layer validation doesn't produce friendly validation messages for your application users, then you'll find that you need to perform view model validation.
How you perform your View Model validation is up to you. I personally don't perform validation within the Validate() method of IValidatableObject because it is only called when the validation attributes return no errors unless you use a custom model binder and I like to bring back all of the model errors all at once. For this reason, if there is any additional validation that is beyond the limits of what can be performed by the validation attributes (or custom validation attributes), I tend to perform it within the controller and this will go some way towards prevent your 'hard to read' view models, here's an example:
// Validate a field
if (string.IsNullOrWhiteSpace(viewModel.Name))
{
// Add a validation error
this.ModelState.AddModelError("FieldName", "This is an error");
}
if (this.ModelState.IsValid())
{
// Do something...
}
Client side validation
This isn't required, but it's a nice to have as it prevents unnecessary load on your server by performing validation at the earliest opportunity using the client's processing power. But as already stated - it cannot be relied upon. It can be disabled or circumvented and your application can still be 'posted' to from anywhere outside of your application.
If you don't want to work too hard at it, just install the unobtrusive validation Nuget package into you MVC project and use the validation attributes that are provided by default and use the @Html. helper methods within your views. This will activate at least basic client side validation for you but only to the extent provided by the built in validation attributes.
