The solution in this article mixes validation logic with service logic. These are two problems, and they must be separated. As your application grows, you will quickly find that the validation logic becomes more complex and duplicated at the service level. Therefore, I would like to propose a different approach.
First of all, IMO would be much better if the service level throws an exception when a validation error occurs. This makes it more explicit and harder to forget to check for errors. This leaves a way to handle errors at the presentation level. The following listing shows a ProductController that uses this approach:
public class ProductController : Controller { private readonly IProductService service; public ProductController(IProductService service) => this.service = service; public ActionResult Create( [Bind(Exclude = "Id")] Product productToCreate) { try { this.service.CreateProduct(productToCreate); } catch (ValidationException ex) { this.ModelState.AddModelErrors(ex); return View(); } return RedirectToAction("Index"); } } public static class MvcValidationExtension { public static void AddModelErrors( this ModelStateDictionary state, ValidationException exception) { foreach (var error in exception.Errors) { state.AddModelError(error.Key, error.Message); } } }
The ProductService class itself should not have any validation, but should delegate it to a class specialized for validation, i.e. IValidationProvider :
public interface IValidationProvider { void Validate(object entity); void ValidateAll(IEnumerable entities); } public class ProductService : IProductService { private readonly IValidationProvider validationProvider; private readonly IProductRespository repository; public ProductService( IProductRespository repository, IValidationProvider validationProvider) { this.repository = repository; this.validationProvider = validationProvider; }
This IValidationProvider , however, should not test itself, but rather delegate validation to validation classes that specialize in validating one specific type. When an object (or set of objects) is not valid, the validation provider must throw a ValidationException that can be caught above the call stack. The provider implementation may look like this:
sealed class ValidationProvider : IValidationProvider { private readonly Func<Type, IValidator> validatorFactory; public ValidationProvider(Func<Type, IValidator> validatorFactory) { this.validatorFactory = validatorFactory; } public void Validate(object entity) { IValidator validator = this.validatorFactory(entity.GetType()); var results = validator.Validate(entity).ToArray(); if (results.Length > 0) throw new ValidationException(results); } public void ValidateAll(IEnumerable entities) { var results = ( from entity in entities.Cast<object>() let validator = this.validatorFactory(entity.GetType()) from result in validator.Validate(entity) select result) .ToArray(); if (results.Length > 0) throw new ValidationException(results); } }
ValidationProvider depends on instances of IValidator that perform the actual validation. The provider itself does not know how to create these instances, but for this it uses the Func<Type, IValidator> delegate Func<Type, IValidator> . This method will have container-specific code, for example, for Ninject:
var provider = new ValidationProvider(type => { var valType = typeof(Validator<>).MakeGenericType(type); return (IValidator)kernel.Get(valType); });
This snippet shows the Validator<T> class - I will show this class in a second. First, ValidationProvider depends on the following classes:
public interface IValidator { IEnumerable<ValidationResult> Validate(object entity); } public class ValidationResult { public ValidationResult(string key, string message) { this.Key = key; this.Message = message; } public string Key { get; } public string Message { get; } } public class ValidationException : Exception { public ValidationException(ValidationResult[] r) : base(r[0].Message) { this.Errors = new ReadOnlyCollection<ValidationResult>(r); } public ReadOnlyCollection<ValidationResult> Errors { get; } }
All of the above code is plumbing necessary to confirm correctness. Now you can define a validation class for each entity that you want to validate. However, to help your DI container a bit, you must define a common base class for validators. This will allow you to register verification types:
public abstract class Validator<T> : IValidator { IEnumerable<ValidationResult> IValidator.Validate(object entity) { if (entity == null) throw new ArgumentNullException("entity"); return this.Validate((T)entity); } protected abstract IEnumerable<ValidationResult> Validate(T entity); }
As you can see, this abstract class inherits from IValidator . Now you can define the ProductValidator class derived from Validator<Product> :
public sealed class ProductValidator : Validator<Product> { protected override IEnumerable<ValidationResult> Validate( Product entity) { if (entity.Name.Trim().Length == 0) yield return new ValidationResult( nameof(Product.Name), "Name is required."); if (entity.Description.Trim().Length == 0) yield return new ValidationResult( nameof(Product.Description), "Description is required."); if (entity.UnitsInStock < 0) yield return new ValidationResult( nameof(Product.UnitsInStock), "Units in stock cnnot be less than zero."); } }
As you can see, the ProductValidator class uses the C # yield return which makes returning validation errors smoother.
The last thing you need to do to get it working is to configure the Ninject configuration:
kernel.Bind<IProductService>().To<ProductService>(); kernel.Bind<IProductRepository>().To<L2SProductRepository>(); Func<Type, IValidator> validatorFactory = type => { var valType = typeof(Validator<>).MakeGenericType(type); return (IValidator)kernel.Get(valType); }; kernel.Bind<IValidationProvider>() .ToConstant(new ValidationProvider(validatorFactory)); kernel.Bind<Validator<Product>>().To<ProductValidator>();
Are we really done? It depends. The disadvantage of the above configuration is that for each entity in our domain you will need a Validator<T> implementation. Even when, perhaps, most implementations will be empty.
You can solve this problem by doing two things:
- You can use automatic registration to automatically download all implementations dynamically from a given assembly.
- You can return to the default implementation when no registration exists.
Such a default implementation might look like this:
sealed class NullValidator<T> : Validator<T> { protected override IEnumerable<ValidationResult> Validate(T entity) { return Enumerable.Empty<ValidationResult>(); } }
You can configure this NullValidator<T> as follows:
kernel.Bind(typeof(Validator<>)).To(typeof(NullValidator<>));
After that, Ninject will return a NullValidator<Customer> when a Validator<Customer> requested and a specific implementation is not registered for it.
The last thing that is missing now is auto-registration. This eliminates the need to add registration for each Validator<T> implementation and allows Ninject to dynamically search for your builds. I could not find any examples of this, but I guess Ninject can do this.
UPDATE: see Keiss's answer for how to automatically register these types.
One final note: to do this, you need a lot of work, so if your project (and remains) is pretty small, this approach can lead to excessive overhead. However, when your project grows, you will be very happy when you have such a flexible design. Think about what you need to do if you want to change the validation (for example, a validation application block or DataAnnotations). The only thing you need to do is write an implementation for NullValidator<T> (in this case, I would rename it DefaultValidator<T> . In addition, it is still possible to have your own validation classes for additional validations that are difficult to implement with other verification technologies.
Please note that using abstractions such as IProductService and ICustomerService violates SOLID principles, and it may be useful for you to switch from this template to a template that abstracts the use cases .
Update: also take a look at this question ; it discusses an additional question about the same article.