Sorry, I was writing my post when this came in. I'm in general
agreement, and while I do think moving to something more than JDO is
important, Brett is right, the use of hte store could use a good audit
and re-factor. Probably some of the problems of strange access
approaches used currently could be identified with adding some unit
tests that expand the current assumptions of the model. These would then
provide some good regression tests for the eventual move to something
more robust.
Also, I really like modello, but don't know if there are plans/schedules
around its support for other forms of persistence than JDO. (Though if
we went with JPA and annotated the model, we could go the other way,
generating all the other artifacts from the code.)
regards,
Christian.
Brett Porter wrote:
I've been thinking stay with JDO for now, look at JPA in the long term.
I haven't used iBatis, and would be happy to hear some practical
experience from people who have. I tend to think of it as "a more
productive JDBC", as opposed to the different programming model of
JDO/Hibernate/JPA.
Having worked with a number of models myself on large production sites
(straight jdbc, castor, object structured jdbc, and now jdo2), I
really like the design of the jdo2 API. It does a good job of giving a
nice clean API that manages to keep the declarativeness while still
allowing good performance through fetch groups and lazy loading.
I think the store itself that we have is quite stable, but it's API is
too simple.
I think that the way we use the store hasn't taken into consideration
the way that the objects are returned (ie, they may be missing some
fields you didn't request, etc). The way Continuum is designed means
you get to a certain point where you want to save an object and you
find that you can't, or you aren't saving everything you want, etc.
Changing to another type of store will make that worse and we'll
discover the same problems and have to make the same design choices
then. So, I'd prefer to address them first.
IMO, we need to centralise more of the object access. So, obviously
we've centralised JDO to the store, which is good. But I think you'll
find the use of the store itself is a little too proliferated, at
least for the level of abstraction you have.
What you ideally want to be able to do is say that a certain set of
actions are going to constitute the entire transaction, and do the
reading from the store at the start and the saving at the end
I'm oversimplifying, but that's what I'm generally thinking. I haven't
looked at that code in a year and a half though - so maybe it's not
quite as relevant now.
- Brett
--
*christian** gruber + process coach and architect*
*Israfil Consulting Services Corporation*
*email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
