views:

56

answers:

2

This question relates to my other post.

Ok so after a bit more messing around I decided to do it this way. Which seems to work fine when I run it, although I'm getting the following error in NUnit: Could not load file or assembly 'Castle.Core, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) So not sure what is happening there???

Just wanted to know what others thought about the design and if there are any obvious 'no no's' or improvements. I.e. Is the constructor of the base handler a good place to instantiate the windsor component or is there a better place to do this? As I said in the original post the idea behind doing things this way was to keep the components nicely decoupled and to make unit testing easy. I should also add I'm new to unit testing, mocking. Thanks!

public abstract class BaseHttpHandler : IHttpHandler
{
    private HttpContext _httpContext;
    private ILogger _logger;
    private IDataRepository _dataRepository;
    protected HttpRequest Request { get { return _httpContext.Request; } }
    protected HttpResponse Response { get { return _httpContext.Response; } }
    protected bool IsRequestFromUAD { get { return Request.UserAgent == null ? false : Request.UserAgent.Equals("UAD"); } }
    protected ILogger Logger { get { return _logger; } }
    protected IDataRepository DataRepository { get { return _dataRepository; } }
    public virtual bool IsReusable { get { return false; } }

    public BaseHttpHandler()
    {
        var container = new WindsorContainer(new XmlInterpreter(new ConfigResource("castle")));
        _logger = container.Resolve<ILogger>();
        _dataRepository = container.Resolve<IDataRepository>();
    }

    public void ProcessRequest(HttpContext context)
    {
        _httpContext = context;
        ProcessRequest(new HttpContextWrapper(context));
    }

    public abstract void ProcessRequest(HttpContextBase context);
}

public class UADRecordHttpHandler : BaseHttpHandler
{
    public override void ProcessRequest(HttpContextBase context)
    {
        if (IsRequestFromUAD)
        {
            using (var reader = new StreamReader(context.Request.InputStream))
            {
                string data = reader.ReadToEnd();

                if (Logger != null)
                    Logger.Log(data);

                if(DataRepository != null)
                    DataRepository.Write(data);

                context.Response.Write(data);
            }
        }
        else
            ReturnResponse(HttpStatusCode.BadRequest);
    }
}
A: 

That's a very bad thing to do, what you're doing here. You should have one instance of the container per application, while with this code you will have one per each request.

Krzysztof Koźmic
Hi. Thanks for your response. That makes sense, (which is what I thought would be the case, I was thinking it would be better to create the container somewhere else i.e Application_Start (Global.asax.cs) but even if I do create a static service locator as Mauricio suggests below how does the HttpHandler access the container?
Matt
+1  A: 

About the error in NUnit: make sure you don't have other versions of Castle assemblies in the GAC. If so, uninstall them.

About your BaseHttpHandler: the problem with this implementation is that you're creating a new container. Instead, use a single container per application, like Krzysztof said. Use a static service locator, e.g. CommonServiceLocator. (I never recommend this but it's one of the few places where it does make sense).

Mauricio Scheffer
Could I not simply add the container to the HttpApplicationState?? protected void Application_Start(object sender, EventArgs e) { Application.Add("Container", new WindsorContainer(new XmlInterpreter(new ConfigResource("castle")))); }
Matt
@Matt: yes, that works too.
Mauricio Scheffer
Thanks for your input. About the problem with Castle.Core assembly, I checked the GAC and it's not actually in there?
Matt
Or do you think I should open a new question about this one?
Matt
@Matt: double check your references. There is some wrong reference there. Castle.Core 1.0.3.0 is a very old release.
Mauricio Scheffer
Just for those that may be reading this. The problem was that Moq was referencing the out dated dll. Thanks for help Mauricio.
Matt