The reason why there are so few examples for winforms, is imho, managing sessions is a lot more complex in smart clients than in the web world.
In the web world you open a ISession when a http session starts, and you close the ISession when the http session is finishing.
There is no direct translation of the concept of http session in a smart client; multiple screens all open at the same time, some minimised, other screens opening and closing all the time, some get closed without saving changes... you get the idea.
I think there are three basic strategies:
1 session per application
I would stay away from this. Remember, if an exception, like a stale entity exception is thrown by your singleton session, that session is now unusable. Your app is basically in the doo doo.
Session per screen
This is a bit better, you avoid your app going down the pan if a single session blows up. However, some screens might collaberate together in the same unit of work. They need to share the same session or you will have issues trying to share your entities between screens as persistent entities have affinity with the session that loaded them.
Persistent conversations
I think this is the way to go. You define a service which holds the scope of your unit of work. Everytime you call methods on this service, the correct ISession is swapped in invisibly for you. When you are finished with your service, you call another method on it and the session is disposed of.
The instance of the service can be shared between your screens, thus they share the session. Multiple sessions can be open at the same time. All of this is done via Aspect Oriented Programming techniques, you don't need take any action other that to tag up your services with attributes.
This sounds quite complicated so checkout Fabio's posts on it here, here and here.
There is an implementation of this pattern in unoffical nh addins. This works in Windsor, probably could convert it to other IoC containers.
