I'm building C#/.Net 3.5 app using three layers: UI (view/view models), service, and data access/persistence.
Service Layer: Each service layer instance is associated with a unique persistence instance. The service layer references the persistence layer via an interface.
Persistence Layer: Right now, the persistence layer interface has a single concrete implementation that uses (Fluent) NHibernate. All persistence layer instances share the same ISessionFactory. Each persistence instance opens its own ISession using that factory.
Goal: For each view model to operate in its own data context (a.k.a. ISession), as suggested by Ayende Rahien. To make this happen, my app gives each VM its own service layer instance (which, in turn, has its own instance of the persistence layer). To me, having this many instances of the same service layer class smells suspicious.
Questions: Is this a good approach? Would I be better off getting away from one service instance per VM and moving to one service instance per app? If so, how would I do that and still give each VM its own data context?
Thank you,
Ben
I think your current design is correct. There's nothing to gain by merging the service instances.