Hi Derek, This is proving a useful debate for me since it has helped clarify my issues.
As far as I can see the "conventional" method of using JPA is, within a single "session" to use some initial query process to obtain one or more entities. All subsequent operations within that session must be via navigation through the associations of those initial entities that are expressly bi-directional. The DDD model, as I understand it, takes the view that there should be no unnecessary bi-directional links and that reaching objects by searching the other side of the association is not only acceptable but to be encouraged, since it reduces the interlinking between components. This is a perfectly respectable viewpoint - not just some weird idea I've dreamed up (honest!). my sympathies are in this camp. Environments like Spring (and Grails which is what I've been working in) enable the second model, since they'll happily inject the current hibernate session (and presumably jpa EM) anywhere you want it to be injected. So it's quite straight forward to use without breaking the usage patterns. But your scalajpa follows, essentially, the stricter line that once the em has given you the first objects (presumably from a controller or service based query, thus outside the domain model), that's it. Does that correctly sum up the arguments? Tim On Apr 28, 4:31 am, Derek Chen-Becker <dchenbec...@gmail.com> wrote: > OK, for one, the bidirectional mapping adds no cost in terms of DB access > other than the time it takes you to write it. Collections are lazily loaded, > so unless your code *retrieves* City.addresses, the database never gets hit. > JPA is really not designed with the concept of entities having access to the > EntityManager that loaded them, although there may be some provider-specific > way to get at it. Unfortunately, you're on your own if you want an entity to > obtain other entities via queries or some other non-relationship means. > Generally, if you need that kind of coverage you should do it through logic > code that can glue things together instead of tying it to your entities. > After all, I'd argue that if the logic isn't part of what you can express in > the database then it doesn't belong in the entity classes anyways. When you > say "bogged down in bidirectional mappings" are you referring simply to the > overhead of adding the mappings to your entities, or do you think that > there's some performance issue with bidirectional mappings (AFAIK, there > aren't any). > > Derek > > On Mon, Apr 27, 2009 at 6:01 PM, TSP <tim.pig...@optrak.co.uk> wrote: > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
