Re: Hibernate
Re: Hibernate
- Subject: Re: Hibernate
- From: Mike Schrag <email@hidden>
- Date: Wed, 25 Feb 2009 12:45:22 -0500
While the tone of the emails does sound in favor of EOF, could you
please share some concrete instances and examples of why Hibernate
doesn't cut it for you?
I actually think Hibernate has quite a few very nice features (that
EOF should steal), not the least of which is a very large community
(harder to steal :) ). So a big caveat here is that I only know
Hibernate from reading about it and from friends who use it, and I
don't have any firsthand experience, but I'll at least try to discuss
the points conceptually.
1. the Session doesn't need to be tightly bound. unlike
EOEditingContext that's tightly bound to the EOObjectStoreCoordinator
I'm not exactly sure what you mean here, or what you the desired
features would be if you could "unbind" an EC from an OSC? You can
obviously just make an EC with a new instance of an OSC and have it
standalone, but I'd be curious to hear more about what kinds of
problems you're trying to solve.
2. it's easier to multi-thread and connection pool with Hibernate
I'm not sure this is NECESSARILY true ... I suppose it depends on how
you look at it, but for instance, http://blog.xebia.com/2009/02/07/hibernate-and-multi-threading/
basically shows that Hibernate has some of the same threading
complexities that EOF does with respect to sharing objects between
threads, at which point, you're really probably comparing using
multiple OSC's. I will definitely grant that EOF's snapshot cache is
both a blessing an a curse. I believe hibernate has a "snapshot
cache" (equivalent) as well, but that the default behavior is that the
cache goes away when the session goes away (which is typically session-
per-request in Hibernate as I understand it?), so there are much fewer
issues with cache freshness in exchange for default behavior that hits
the db more often. You can add a second level cache to Hibernate, at
which point, I imagine the issues are identical (cache invalidation is
cache invalidation -- no way around it really). Hibernate is written
with much better abstractions here, though, in that you can rip out
the backing layers and change their behavior -- this is very hard to
do in EOF, though something that will hopefully be changed. I think
one of the issues with WO/EOF is that it's easy to do some really
complicated things, but actually kind of hard to do some easy
things ... If you WANT to make an app that has the behavioral
characteristics of, say, Rails w/ routers and controllers + EOF that
behaves more like Hibernate or ActiveRecord, you really have to work
at it. I'd like to see some more support for alternative use cases --
I sometimes feel like I'm fighting EOF to do something that shouldn't
be hard.
3. Hibernate validators are not too bad for basic validations
I've always felt that EOF should have more out-of-the-box model-
defined validation support (more than just "not null"). I don't know
how much I rank this as an EOF limitation or a Hibernate feature,
though, as both are sort of orthogonal to the core frameworks.
Wonder, for instance, could easily add nice default validators without
requiring any changes to EOF (and actually HAS a bunch of this with
Validity framework, but I'm not sure if anyone actually uses it or
what the state of it is), because EOF happens to have a fairly clean
design here. That said, out-of-the-box experience is valuable -- that
we could theoretically add it is still less cool than that Hibernate
just already has it built in.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden