IStore vs. IRepository

[Bil Simser]

Dave,

Just wondering how you guys are using IStore (and the
NHibernateSessionAdapter) vs. something like an implemenation of an
IRepository using a store?

For example, IRepository<T> would have various methods and you might
have ClientRepository : IRepository<Client> which adds specific
searches for clients. On locating the repository you might inject and
IStore into it which would resovle to NHibernateSessionAdapter.

Or do you have a ClientStore : NHiberneateSessionAdapter class for
your persistance rather than the extra layer of abstraction with
IRepository.

For Smart Client apps I assume a good place to start this persistenace
is in some kind of global application controller (hence the desire for
maybe IApplicationController instead of IShellContext) as you don't
want to be creating session factories all the time. Or do you
generally put your persistance behind a service or maybe a message bus?

[David Laribee]

The IStore represents the storage medium, e.g. database, cache, etc.

It is somewhat equivalent to the ISession in NH. I abstracted it out to reflect a greater SoC. You should rarely, if ever, code directly to the store. The one exception is repositories and running Queries.

The NHibernateSessionAdapter adapts the ISession from NH to our concept of IStore. You might end up creating a different implementation if you just wanted to keep your model in memory, etc.

--


/ Dave

http://thebeelog.com

[Bil Simser]

So is there a controlling class missing to handle creation of sessions
from session factories and invoking transactions? I know you pass an
ITransaction to the TransactionElection so you can vote on commits and
rollbacks, but not sure where that fits in. Who's the controller and
invoker of such things?

> http://thebeelog.com- Hide quoted text -
>
> - Show quoted text -

[David Laribee]

Create your NHibenate ISessionFactory and ISession normally. Then feed the ISession into an NHibernateSessionWrapper and supply that to UnitOfWork.InitializeWithStore. This you can usually do per-request when IIS is hosting the server side of your app.

So steps:

1. Request is intercepted
2. ISessionFactory (thread safe) lives in Application state.
3. Use it to create an ISession
4. new NHibernateSessionWrapper(theCreatedISession)
5. Take #4 and call UnitOfWork.InitializeWithStore(nhibernateSessionWrapper)...

You have to do that in one place and once that's done UnitOfWork pretty much is your go to guy for committing to the DB. Repositories handle stuff just fine and automatically. We need to add FindBy(Criteria criteria), but that's a separate conversation...

Is this clear/sensible?

[Bil Simser]

Makes sense.

 

Did a spike to grok it and it makes sense. It’s elegant as the repositories don’t worry about the underlying store and you can focus on returning queried information. The debate still lingers on session and how often should it be created/destroyed/initialized (earlier email to you). Like I said, I’m going to try it out in a UnitOfWork fork to see if it makes sense and doesn’t kill performance and you can choose to fold it (or some variation) maybe into trunk.

 

Thanks.