Inject ASP.NET MVC Controller property into service layer dependency?
Asked Answered
K

1

9

I am using an approach similar to the one in this ASP.NET MVC tutorial where you pass a wrapper around a controller's ModelState collection into a validation class so that the controller can access error information.

Here is a cooked up example:

interface IProductValidator {
   void Validate(Product item);
}

class ProductValidator {
   // constructor
   public ProductValidator(ModelStateWrapper validationDictionary) { }
}

interface IProductService {
   void AddProduct();
}

public class ProductService : IProductService {
   // constructor
   public ProductService(IProductValidator validator) { }
}

Using the Castle Windsor container for IoC/DI, how do I create the IProductService? Typically, I would have:

MvcApplication.IocContainer.Resolve<IProductService>()

but this isn't able to inject the value of the Controller's ModelState property into the constructor for ProductValidator. I could possibly wire this up using constructor parameters, but that seems really ugly.

Kara answered 6/10, 2010 at 14:26 Comment(3)
Did you check out: #2077555Medical
That is a pretty similar question: in my case, I don't even try to instantiate a validator-- I want the container to resolve it. In any case, the question you linked to doesn't have any answers for me. I'll let this stand and hope for some additional insight.Kara
I was hoping there was some way to obtain the current ControllerContext statically, just like you can get the current HttpContext with HttpContext.Current. Unfortunately, I couldn't find one. One other idea would be to have an additional method on IProductValidator that would accept a "ModelStateWrapper" and would copy the validation errors into there. Not as nice as Dependency Injection, but it should work pretty easily.Fallow
G
2

I'm assuming you want the modelstate passed in to auto inject any errors into your model? IMHO, ModelState should stay where it is, and you bring the validation errors to it. Here's how I handle errors as an example. I'm not saying this is the best way or the only way, but it is one way where your validation layer doesn't have to have knowledge of who or what consumes validation errors.

First, in my poco, I use System.ComponentModel.DataAnnotations for validation rules. Here is my account class, for example.

public class Account : CoreObjectBase<Account>
{
    public virtual int AccountId { get; set; }

    [Required(ErrorMessage = "Email address is required.")]
    public virtual string EmailAddress { get; set; }

    [Required(ErrorMessage = "A password is required.")]
    public virtual string Password { get; set; }
}

Because I want to be able to initiate validation myself (outside of MVC doing it on it's own), I had to implement my own validator.

public class Validator<T> where T : CoreObjectBase<T>
{
    public ValidationResponse Validate(T entity)
    {
        var validationResults = new List<ValidationResult>();
        var context = new ValidationContext(entity, null, null);
        var isValid = Validator.TryValidateObject(entity, context, validationResults);

        return new ValidationResponse(validationResults.ToArray());
    }
}

Here is the ValidationResult I pass back

[Serializable]
public class ValidationResponse
{
    public IList<ValidationResult> Violations { get; private set; }

    public IList<ErrorInfo> Errors { get; private set; }

    public bool HasViolations
    {
        get { return Violations.Count > 0; }
    }

    public ValidationResponse(params ValidationResult[] violations)
    {
        Violations = new List<ValidationResult>(violations);

        var errors = from v in Violations
                     from n in v.MemberNames
                     select new ErrorInfo(n, v.ErrorMessage);

        Errors = errors.ToList();
    }

}

ErrorInfo is a very basic class with information about my error

[Serializable]
public class ErrorInfo
{
    public string ErrorMessage { get; private set; }
    public object Object { get; private set; }
    public string PropertyName { get; private set; }

    public ErrorInfo(string propertyName, string errorMessage)
        : this(propertyName, errorMessage, null)
    {

    }

    public ErrorInfo(string propertyName, string errorMessage, object onObject)
    {
        PropertyName = propertyName;
        ErrorMessage = errorMessage;
        Object = onObject;
    } 
}

in order to wrap this validation up all nice and neat with my poco classes, I inherit from a base class. For validation to make it generic where the inherited child has to tell the base class it's type. It feels circular, but it works.

[Serializable]
public class CoreObjectBase<T> : IValidatable where T : CoreObjectBase<T>  
{
    #region IValidatable Members

    public virtual bool IsValid
    {
        get
        {
            // First, check rules that always apply to this type
            var result = new Validator<T>().Validate((T)this);

            // return false if any violations occurred
            return !result.HasViolations;
        }
    }

    public virtual ValidationResponse ValidationResults
    {
        get
        {
            var result = new Validator<T>().Validate((T)this);
            return result;
        }
    }

    public virtual void Validate()
    {
        // First, check rules that always apply to this type
        var result = new Validator<T>().Validate((T)this);

        // throw error if any violations were detected
        if (result.HasViolations)
            throw new RulesException(result.Errors);
    }

    #endregion
}

And finally, as you can see, my validation throws a RulesException. This class is a wrapper for all the errors.

[Serializable]
public class RulesException : Exception 
{
    public IEnumerable<ErrorInfo> Errors { get; private set; }

    public RulesException(IEnumerable<ErrorInfo> errors)
    {
        Errors = errors != null ? errors : new List<ErrorInfo>();
    }

    public RulesException(string propertyName, string errorMessage) : 
        this(propertyName, errorMessage, null)
    {

    }

    public RulesException(string propertyName, string errorMessage, object onObject) : 
        this (new ErrorInfo[] { new ErrorInfo(propertyName, errorMessage, onObject) } )
    {

    }
}

So, with that said, my validation in my controller looks more like this

public ActionResult MyAction()
{
   try
   {
      //call validation here
   }
   catch (RulesException ex)
   {
      ModelState.AddModelStateErrors(ex);
   }

   return View();
}

ModelState.AddModelStateErrors(ex); is an extension method that I wrote. it is very simple.

    public static void AddModelStateErrors(this System.Web.Mvc.ModelStateDictionary modelState, RulesException exception)
    {
        foreach (ErrorInfo info in exception.Errors)
        {
            modelState.AddModelError(info.PropertyName, info.ErrorMessage);
        }
    }

This way, I can still use DI for my services/repositories, and let them throw up an error when my model is invalid. Then I let the front end - whether that is an MVC app, web service, or windows app - decide what to do with those errors.

I feel that injecting MVC controller/model/view state back into the model/services/repositories/etc is a violation of the basic separation between the layers.

Gallantry answered 28/10, 2010 at 14:18 Comment(2)
Looks good to me! Not sure why your RulesException class is serialiazable? Could you explain please?Mainsheet
I made it serializable so rules exceptions could be consumed and presented in an app calling my code through a web service.Gallantry

© 2022 - 2024 — McMap. All rights reserved.