0

Framework: ASP.Net MVC 3

When a request comes in, I am intercepting the request through a global filter and performing a database look up based on the subdomain. The return int from the DB lookup needs to be persisted to other objects (i.e. Controllers) so that the DB hit doesn't need to be performed again whenever that data might be needed.

I was hoping to avoid using cookies since this information is a pertinent part of the system and I didn't want to rely on cookies being enabled.

I have read the related questions here and here which have not provided any good answers.

I actually have two questions:

  1. As of now I had come up with a Subdomain manager object which does the heavy lifting and through my IoC have the manager object be HTTP Request scoped and I can grab that manager anytime during the request as a possible solution.

    Is there a better way to carry this information across different object in the MVC request pipeline after I have looked it up? - I had examined the idea of putting the information back into the request somehow (which pertains to question #2).

  2. If you were to use the Request to store the data (i.e. intercept the request, perform look up, write to the request) where would be the logical place to hold that information?

    I reviewed the session but this seems to be closely tied to the way the web server is configured for sessions and I already mentioned I don't want to use cookies. Other areas such as post data and query string collections are locked down for their security reasons.

Any suggestions?

Community
  • 1
  • 1
pghtech
  • 3,642
  • 11
  • 48
  • 73
  • why not [MemCached](http://stackoverflow.com/questions/351635/memcached-with-windows-and-net)? that's what I use and it's fast, reliable and super easy to develop to. – balexandre Jun 01 '12 at 12:00
  • Well, if not Session then there's [Cache, look at the answer here](http://stackoverflow.com/a/343935/1180426)..? – Patryk Ćwiek Jun 01 '12 at 12:01

2 Answers2

2

I think your first approach with an IoC container and a http request scope is good to go.

For your second question: The right place would be the HttpContext.Items store, which stores key value pairs for the lifetime of the current request.

Jan
  • 15,802
  • 5
  • 35
  • 59
1

1 Is pretty close.

Your SubDomain manager could probably be a singleton (using your IOC container perhaps), with a simple static Dictionary for looking up a subdomain once the data has been initially loaded. If you are concerned about having this initial load occur and be syncd across several servers without executing the data load multiple times you could look at a distributed cache (appfabric, ncache, memcache) depending on the overhead of making the DB call.

I would not use HttpContext.Item to store the Id however. I would use your IOC container to Inject this into your controller(s) (Property inject probably). Using most IOC containers you should be able to have this fire on the start of a HttpRequest and last last the lifetime of the "User Session/Transaction".

NHibernate Burrows allows all of this to be implemented so easily it's laughable http://nhforge.org/wikis/burrow/default.aspx

Jaimal Chohan
  • 8,530
  • 6
  • 43
  • 64
  • Good idea on utilizing a dictionary and setting up the manager as a Singleton. I am using NH currently in the project, I'll have to look at Burrow.. – pghtech Jun 01 '12 at 12:38