I am searching about the different ways one can manage an nhibernate session in a web api project. The simplest solution I found binds the session to HttpContext when the request begins. Other, more complex, solutions use dependency injection.
My question is there any reason for not choosing the easiest way of binding the session to HttpContext on BeginRequest?
My question is there any reason for not choosing the easiest way of
binding the session to HttpContext on BeginRequest?
The reason is that Web API is designed to work with OWIN. This means that it could be hosted outside ASP.NET where notions like HttpContext and BeginRequest simply won't exist. So using them you are tying your application to an ASP.NET host forever which is exactly what the designers of the Web API tried to avoid by porting it to the OWIN middleware.
So you can use the HttpRequestMessage.Properties dictionary instead to store your NHibernate session and achieve per-request lifetime.
Related
I have a server on the WebApi2, and I need get all active users on the server.
How to implement it?
I think, maybe, save customerId after logIn in the session storage.
But I don't know how to implement it.
Or maybe exists some best solutions for it.
Help me please, with this issue.
You can access session object using this kind of code.
Keep in mind that Web API provides REST services, and is from a design perpective not meant to access Session objects, as its purpose is to provide stateless methods.
This of course does not mean it is not technically feasible, as you can see on this SO answer.
Use this article Adding Session support to ASP.NET Web API for example
as the entering point to find out the best solution.
We have a completely OWIN project and StructureMap is used for its IoC/DI. This Entity Framework ASP.NET Web API project runs on Helios that means no Http exists at all.
Now the question is what is proper lifecycle for DbContext?
HttpContextScoped?
This is not possible at all because an exception is throwned saying that You cannot use the HttpContextLifecycle outside of a web request.
HybridHttpOrThreadLocalScoped?
DbContext is alive for several requests so managing unit of work is very hard.
Transient?
This works but I'm not sure if it is a really correct choise.
In a self hosted ASP.NET Web Api, how can I:
Detect from a class if there's an "ambient" web api context. This is needed to avoid passing in metadata information on every service call. I'm looking for the equivalent of
System.Web.HttpRequest.Current != null
How can I attach metadata information associated with the current request. Again some of this metadata is just so prevalent that including them on every method and calls is way too painful. Think transaction, multi-tenant architecture and credentialings. I need a way to make this sort of information flow through between requests without cluttering the code.
In another word I also need the equivalent of this as explained here:
HttpContext.Current.Items["user" + X.ToString()]
I think I can still access them, as long as the WebApi is hosted on IIS, but I have got these self hosted and I need a way to keep track of the ambient UoW information - how can I do so?
A few notes:
I have also contemplated using per request DI and injecting a
request context into the managers, there are however a ton of legacy
code that wasn't set up for that (some of which are static) and I
don't have the guts to blow up production by doing such a major
refactor.
I have also used a thread static, static variable - the problem with such is that the thread gets recycled, and the process hosts multiple services, some of which aren't even WebApi... so sometimes my managers thought it's handling a WebApi request when in fact it's serving a WCF one.
The HttpRequestMessage instance has Properties dictionary that is intended for holding arbitrary per-request context.
We have a Silverlight intranet application using old web services, and I've been tasked with adding support for SSL. To do this I was planning to ditch the old web services and replace them with a new WCF service.
I also needed to get rid of the old web references and build the proxy dynamically as well (because the endpoint will vary), and found this useful article which outlines how to build dynamic proxies http://sonyarouje.com/2010/10/01/proxy-less-silverlight-wcf-communication.
I now have that working (although I now need to work out how to call a method that has parameters) but I've just discovered that (a) Silverlight only supports BasicHttpBinding (i.e. not ws), and (b) BasicHttpBinding does not support session state.
Our application currently uses session to keep track of and queue up requests through our singleton data access layer. The only thing I can think of doing at the moment is to write my own implementation of session - but I was wondering if there's a better solution that I'm missing, hence this post.
So basically, is there a 'best practice' approach that supports Silverlight, WCF, session state and SSL, or am I right to go ahead and replace session with my own equivalent?
I think you've mixed WCF session with ASP.NET Sessions. WCF Session and ASP.NET sessions are completely different.
In your case, to enable ASP.NET state in WCF service, you'd just require to enable ASP.NET Compatibility Mode on service,
Please find a very good blog on the same by wenlong,
http://blogs.msdn.com/b/wenlong/archive/2006/01/23/516041.aspx
HTH,
Amit
I have implemented the Session per request pattern for managing nhibernate sessions.
Because it is an httpmodule it runs for every request, be it a jpg or png. Is there a way to only get the module to create a session if the request is made through the MVC framework? I.E excluding png/jpg etc?
Mathieu is right, however it is a good practice for ASP.NET MVC projects to open sessions in an ActionFilter class.You can register it in GlobalFilterCollection, if you want it to run for every action. Take a look at this blog post (also from Ayende, but MVC specific).
Don't bother with that, creating a new session is just newing a few objects. Full explanation here from Ayende : http://ayende.com/blog/4123/what-is-the-cost-of-opening-a-session