On 25.2.2009, at 18:45, Mike Schrag wrote:

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      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/webobjectspicora%40gmail.com

This email sent to webobjectspic...@gmail.com

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to