Now that the bulk of the holiday season is over, I started back in on my side projects. Tonight’s goal: remove some of the lifting required of developers to implement resuming downloads.
While playing around with the Controller class I started digging into the OnActionExecuted method. From here I had access to the Request and Response objects. In essence, I could unify my 2-prong approach (ActionFilter to scan the request and ActionResult to write the response) in one step and eliminate the need for the developer to do anything at all (except change their code to inherit from ResumingController rather than Controller).
What I’m doing is checking for the 3 ActionResult types that are used when a Controller returns a File() result. I take the values I need and replace the object with my custom result.
The upside: controller code stays the same.
The downside: it feels a little dirty to me. I’m explicitly casting and checking the FilterContext.Result type and replacing it with an equivalent. While it works I’m not sure it passes the smell test.
I really want to eliminate the need for the developer to ever see/deal with an object holding the parsed data values. Maybe instead of overriding the OnActionExecuted I can introduce more File() overloads that match the existing ones and add a bool flag for Resumable support or call it ResumableFile() instead while matching the existing methods. This would make things cleaner to me and should pass the smell test. In addition, a developer could continue to use non-resuming results if they chose.
I think this is the approach I will take and will implement this, and a code clean, sometime this week. Luckily I can still leverage my existing ActionResult classes and just put a consistent interface in between. It won’t make adding this functionality a single change but it should be fairly unobtrusive.
My next task is to look at the MVC 3 DI / IoC design and see if I can take advantage of that at all. (Honestly I have no idea what I’m talking about.)