We Keep Coding

How to encapsulate code for WCF services without using a base class?

All of our services take a ServiceCallContext object as a parameter. The service then creates a broker and tells the broker what connection string to use based on the ServiceCallContext.
In other words, some of our customers have their own databases so the service calls have to point the brokers to their databases.
I would like to take the code that looks at the ServiceCallContext and chooses the correct connection and put it in a base service class. My team lead doesn't like that idea because with services he feels that this would be 'hiding' behavior and that this would be a bad thing. He suggested that there may be better ways to accomplish the same thing through some sort of WCF extensions.
I honestly don't care how we implement the code so long as I can reuse it because I think it's absolutely silly for me to be rewriting it in every service I create. I began looking into some WCF videos on PluralSight and it looks like there's a lot of great stuff it can do but unfortunately I'm not quite sure where to start. Can anyone give me a little direction as to whether WCF can accomplish what I'm trying to do and if so what particular features of WCF am I looking for?

The functionality you need is a custom interceptor.
This allows you to tell the WCF stack to look at incoming messages and the do some action based on them. If you wrap the interceptor up into it's own assembly then you can reference it from multiple services.

Is using a well know Singleton pattern to save state in a stateless MVC application considered a good approach?

I need to save some session/user related information in my MVC project. Since it should be unique and available throughout the lifetime of the session, I thought about "session-wide" singleton. I found several posts on this subject (for example here, here or here) but then I remembered reading this post about not using the Session object in a MVC application. Since this sounds like a generally bad idea, I thought about using the 4th version of Jon Skeet's singleton. In a couple of quick tests I wasn't able to see any violation of the singleton pattern per user session (i.e. only one object for every session was created). I might have missed something or might not have tested it correctly.
Is it safe to use this pattern for a session singleton in a MVC project (without saving the object in HttpContext.Current.Session or HttpContext.Current.Items)?

WCF service + NHibernate: how to handle the session?

I am writing a wcf service and i wanna use NHibernate for the data access objects. My doubt is about how would be the best approach to handle the nh's sessions.
I've been reading about the topic and seems like per call is the best way, also i found the uNhAddIns implementation, but does anyone know if this is a better choice?
any advice will be appreciated.

Have one NHibernateSessionFactory class such that we always get a single instance of the NHibernate session factory and start using them in wcf service on need basis. You can have a
instance of this in the class implementing the operation contracts
private readonly NHibernateSessionFactory m_sessionfactory = new NHibernateSessionFactory();
you can start using it on need basis with in the class:
using (ISession session = m_sessionfactory.Instance().OpenSession())
{
//----------Do something here
}
I am not sure whether you are looking for these type of details or not. If not please ingnore my response.

Need a solution for middleware caching in C#

I have an ASP.net application that uses some common business object that we have created. These business objects are also used in a few other windows services or console applications.
The problem I am running into is that if I have a class "foo" and a class "bar" and each has a function loadClient(), if I call foo.loadClient() and bar.loadClient(), each request will hit the database. I figure implementing some sort of cache would reduce unnecessary round trips to the DB.
Here's the catch. I want the cache to be specific to each HTTP request that comes in on the ASP.net App. That is, a new request gets a brand new cache. The cache can exist for the lifetime of the other console applications since 90% of them are utilities.
I know I can use System.Web.Cache but I don't want my middleware tied to the System.Web libraries.
Hope that explains it. Can anyone point me in the right direction?
Thanks!

Are you reusing objects during the lifetime of a request? If not,then the model you have suggests that each postback will also create a new set of objects in effect obviating the need for a cache. Typically a cache has value when objects are shared across requests
As far as using a non web specific caching solution I've found the Microsoft Caching Application Block very robust and easy to use.

I think you can take a loot at Velocity project.
http://msdn.microsoft.com/en-us/data/cc655792.aspx - there is a brief article

If you are looking for interprocess caching then thats difficult.
But if you dont want your middleware tied to System.Web then you can write one interface library that will serve as bridge between your middleware and system.web.
In future if you want to tie it to other cache manager then you can just rewrite your bridge interface library keeping your middleware absolutely independent of actual cache manager.

The System.Runtime.Caching.MemoryCache is recommended by Microsoft in lieu of System.Web.Caching. It can be used in the context of the MS Caching Application Block suggested by Abhijeet Patel.
See:
Is System.Web.Caching or System.Runtime.Caching preferable for a .NET 4 web application
http://msdn.microsoft.com/en-us/library/dd997357.aspx

using (Fluent) NHibernate with StructureMap (or any IoCC)

On my quest to learn NHibernate I have reached the next hurdle; how should I go about integrating it with StructureMap?
Although code examples are very welcome, I'm more interested in the general procedure.
What I was planning on doing was...
Use Fluent NHibernate to create my class mappings for use in NHibs Configuration
Implement ISession and ISessionFactory
Bootstrap an instance of my ISessionFactory into StructureMap as a singleton
Register ISession with StructureMap, with per-HttpRequest caching
However, don't I need to call various tidy-up methods on my session instance at the end of the HttpRequest (because thats the end of its life)?
If i do the tidy-up in Dispose(), will structuremap take care of this for me?
If not, what am I supposed to do?
Thanks
Andrew

I use StructureMap with fluent-nhibernate (and NH Validator) in 3 of my current projects. 2 of those are ASP MVC apps and the third is a WCF web service.
Your general strategy sounds about right (except you won't be making your own Session or SessionFactory, as was already pointed out in comments). For details, snag my configuration code from here:
http://brendanjerwin.github.com/development/dotnet/2009/03/11/using-nhibernate-validator-with-fluent-nhibernate.html
The post is really about integrating NH Validator and Fluent-NHibernate but you can see exactly how I register the session factory and ISession with StructureMap in the "Bonus" section of the post.
RE: Tidy up: You should try and always work within a transaction and either commit or roll-back the transaction at the end of your unit of work. NH only utilizes SQL Connections when it needs them and will take care of the cleanup of that limited resource for you. Normal garbage collection will take care of your sessions themselves.
The Session Factory is a very expensive object that you will want to only initialize once and keep around for the life of your app.

I've not used structure map but maybee I can still help guide you in the right direction. Fluent nHibernate is awsome good choice over the hbm files.
As for the http request, you do not need to ensure that you close the session when the http request ends. If you don't you'll end up leaking nHibernate session. I'm not sure if structure map will handle this for you, what I've done is I have an http module which closes the session.
One thing to note though that bite me, is that you will make to sure you wrap all your data access in a transaction and ensure nHibernate actually commits its changes. If you do this as part of your session close, you could miss the chance to handle errors. I'm curious to hear what you ended up having to do to get this workign.