Question

I am still mostly unfamiliar with Inversion of Control (although I am learning about it now) so if that is the solution to my question, just let me know and I’ll get back to learning about it.

I have a pair of controllers which need to a Session variable, naturally nothing too special has happen because of how Session works in the first place, but this got me wondering what the cleanest way to share related objects between two separate controllers is. In my specific scenario I have an UploadController and a ProductController which work in conjunction with one another to upload image files. As files are uploaded by the UploadController, data about the upload is stored in the Session. After this happens I need to access that Session data in the ProductController. If I create a get/set property for the Session variable containing my upload information in both controllers I’ll be able to access that data, but at the same time I’ll be violating all sorts of DRY, not to mention creating a, at best, confusing design where an object is shared and modified by two completely disconnected objects.

What do you suggest?

Exact Context:

A file upload View posts a file to UploadController.ImageWithpreview(), which then reads in the posted file and copies it to a temporary directory. After saving the file, another class produces a thumbnail of the uploaded image. The path to both the original file and the generated thumbnail are then returned with a JsonResult to a javascript callback which updates some dynamic content in a form on the page which can be “Saved” or “Cancelled”. Whether the uploaded image is saved or it is skipped, I need to either move or delete both it and the generated thumbnail from the temporary directory. To facilitate this, UploadController keeps track of all of the upload files and their thumbnails in a Session-maintained Queue object.

Back in the View: after the form is populated with a generated thumbnail of the image that was uploaded, the form posts back to the ProductsController where the selected file is identified (currently I store the filename in a Hidden field, which I realize is a horrible vulnerability), and then copied out of the temp directory to a permanent location. Ideally, I would like to simply access the Queue I have stored in the Session so that the form does not need to contain the image location as it does now. This is how I have envisioned my solution, but I’ll eagerly listen to any comments or criticisms.

Answer 1

A couple of solutions come to mind. You could use a “SessionState” class that maps into the request and gets/sets the info as such (I’m doing this from memory so this is unlikely to compile and is meant to convey the point):

internal class SessionState
{
  string ImageName
  {
    get { return HttpContext.Current.Session["ImageName"]; }
    set { HttpContext.Current.Session["ImageName"] = value; }
  }
}

And then from the controller, do something like:

  var sessionState = new SessionState();
  sessionState.ImageName = "xyz";
  /* Or */
  var imageName = sessionState.ImageName;

Alternatively, you could create a controller extension method:

public static class SessionControllerExtensions
{
  public static string GetImageName(this IController controller)
  {
    return HttpContext.Current.Session["ImageName"];
  }

  public static string SetImageName(this IController controller, string imageName)
  {
    HttpContext.Current.Session["ImageName"] = imageName;
  }
}

Then from the controller:

  this.SetImageName("xyz");
  /* or */
  var imageName = this.GetImageName();

This is certainly DRY. That said, I don’t particularly like either of these solutions as I prefer to store as little data, if any, in session. But if you’re intent is to hold onto all of this information without having to load/discern it from some other source, this is the quickest (dirtiest) way I can think of to do it. I’m quite certain there’s a much more elegant solution, but I don’t have all of the information about what it is you’re trying to do and what the problem domain is.

Keep in mind that when storing information in the session, you will have to dehydrate/rehydrate the objects via serialization and you may not be getting the performance you think you are from doing it this way.

Hope this helps.

EDIT: In response to additional information
Not sure on where you’re looking to deploy this, but processing images “real-time” is a sure fire way to be hit with a DoS attack. My suggestion to you is as follows — this is assuming that this is public facing and anyone can upload an image:

1) Allow the user to upload an image. This image goes into the processing queue for background processing by the application or some service. Additionally, the name of the image goes into the user’s personal processing queue — likely a table in the database. Information about background processing in a web app can be found @ Schedule a job in hosted web server

2) Process these images and, while processing, display a “processing graphic”. You can have an ajax request on the product page that checks for images being processed and trys to reload them every X seconds.

3) While an image is being “processed”, the user can opt out of processing assuming they’re the one that uploaded the image. This is available either on the product page(s) that display the image or on a separate “user queue” view that will allow them to remove the image from consideration.

So, you end up with some more domain objects and those objects are managed by the queue. I’m a strong advocate of convention over configuration so the final destination of the product image(s) should be predefined. Something like:

images/products/{id}.jpg or, if a collection, images/products/{id}/{sequence}.jpg.

You then don’t need to know the destination in the form. It’s the same for all images.

The queue then needs to know where the temp image was uploaded and what the product id was. The queue worker pops items from the queue, processes them, and stores them accordingly.

I know this sounds a little more “structured” than what you originally intended, but I think it’s a little cleaner.