Using NHibernate with different persistance mechanisms

[Paul Batum]

I'm trying to get a feel for just how far you can take NHibernate in
terms of different underlying persistance mechanisms. I know it
supports use of multiple databases simultaneously by maintaining one
session factory per database. I know that it supports different
database types through different providers. But can you get NHibernate
to map objects to say, web service calls?

I know this question is a little "out there" - I understand that if it
were possible at all, it wouldn't be NHibernate that was doing the
mapping - you would have to roll your own. But do sufficient extension
points exist such that if you rolled your own, you could rely on
NHibernate to do atleast SOME of the work, such as dirty tracking? Is
it possible for a call such as ISession.Load(typeof(Person), 1) to be
translated to some sort of message that is NOT sql?

[Ayende Rahien]

It is possible by creating IEntityPersister implementation.
But it is not fun.

[Paul Batum]

Thanks Ayende. I managed to find the CustomPersister in
NHibernate.DomainModel that demonstrates implementing IEntityPersister
and persisting to a hashtable - this looks like a good place to start!
I noticed however that the custom object being persisted doesn't have
relationships with any other types in the model. I am guessing that
dealing with this is even less fun...

Are there any other examples avaliable of implementing
IEntityPersister for a non-relational store? I'm still trying to get
my head around how practical this whole idea is - at the moment it
seems like a fool's errand.

On Jun 25, 12:35 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> It is possible by creating IEntityPersister implementation.
> But it is not fun.
>

[Ayende Rahien]

I would strongly suggest not doing this.
You can probably find some examples on the Java side.

What exactly are you trying to do?

[Paul Batum]

I've been tasked with identifying exactly how a proposed architecture
that includes nhibernate could read and write data provided by an
external system, presumably through some sort of service api.
Currently, I see two distinct approaches (but perhaps I am missing
some, feel free to comment!):

a) Make no distinction between data owned by the system and data owned
by other systems - represent them both in the domain model and do all
the necessary work with IEntityPersister. (ALOT of work, not sure how
far you can go with this.)
b) Do not represent data controlled by external systems in the domain
model. Handle collaboration between your system and the external
system from your services/managers (an example of this stereotype
would be your OrderService from here: http://www.ayende.com/Blog/archive/9042.aspx).

I suspect that option a) is overly ambitious and I -much- prefer
option b). However I want to be sure that I have given both approaches
a reasonable amount of investigation.

I have made some effort to search for examples of implementing option
a) from the java side but am yet to find much.

On Jun 25, 1:27 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> I would strongly suggest not doing this.
> You can probably find some examples on the Java side.
>
> What exactly are you trying to do?
>

[Ayende Rahien]

NHibernate makes a lot of assumptions about the persistence store. Basically, it assumes that it is a RDBMS.
I don't think that I would suggest going with (a). It is bad from the perspective of leaky abstraction as well. (DB tend to be close by, external systems are far away, etc).

Going with (b) would be what I would do

[Ken Egozi]

even worse,
assuming you pull this off, NH is happy and all.
now the users (as in - programmers) will assume that the cost of a call is to a fast DB, on a reliable close-by (same?) server, when actually might go where no-man has gone before

having two redundant DB calls is not as nearly as bad as having two redundant WS calls, and the usage difference should be explicit

--
Ken Egozi.
http://www.kenegozi.com/blog
http://www.musicglue.com
http://www.castleproject.org
http://www.mamaherb.com
http://www.gotfriends.co.il

[Paul Batum]

Thanks Ayende and Ken. I wholeheartedly agree with both your points
and am now satisfied that I've explored the idea sufficiently. I will
definately be pushing for option b!

On Jun 25, 3:31 pm, "Ken Egozi" <egoz...@gmail.com> wrote:
> even worse,
> assuming you pull this off, NH is happy and all.
> now the users (as in - programmers) will assume that the cost of a call is
> to a fast DB, on a reliable close-by (same?) server, when actually might go
> where no-man has gone before
>
> having two redundant DB calls is not as nearly as bad as having two
> redundant WS calls, and the usage difference should be explicit
>
>
>
> On Wed, Jun 25, 2008 at 5:25 PM, Ayende Rahien <aye...@ayende.com> wrote:
> > NHibernate makes a lot of assumptions about the persistence store.
> > Basically, it assumes that it is a RDBMS.
> > I don't think that I would suggest going with (a). It is bad from the
> > perspective of leaky abstraction as well. (DB tend to be close by, external
> > systems are far away, etc).
>
> > Going with (b) would be what I would do
>