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 <[email protected]> wrote: > > There are two questions here. I don't really want to get bogged down > in bidrectional mappings I was rather hoping for suggestions on how my > domain objects might simply get at the right Model transparently from > both application and junit (in Grails it was done with Spring > injection - here perhaps an EMF factory (a factory-factory?)) However, > in answer to the bidirectional mapping question here is an example: > > class City { > var name: String; > var population: Int; > // var addresses: java.util.Set[Address] // BAD because London has > approx 3m addresses > > } > > class Address { > name, street etc > var city: City > } > > object Address { > def matchAddress( .. unstructured input strings from ERP > system ...) = { > ,,, > Some[Address] > else > None > } > } > > > class Organisation { > var hq: Address; > } > > So I can easily trace from organisation to it's address and then find > out if the organisation is in a big city. > But I never need to directly fetch the city and iterate through the > addresses. > > There are many more examples where the many side of things runs into > hundreds and thousands (shipments to a daily customer over the last 2 > years, tracking events on trucks at 1 minute intervals stored for 6 > months). > > Again with reference to Evans Domain Driven Design for a large and > complex domain model (I expect to end up with well over 50 objects) > universal bi-directional mappings are strongly discouraged (see for > example discussion on p. 83) > > Now you might argue that my address matching should be delegated to a > service, but the techniques can be quite country specific tying in the > postcodes and town names for example or dealing with peculiarities > (from my point of view) of US street naming conventions - so I want my > address matching tied closely to may data objects (in that case it > would be Address subclasses). Also as soon as I do get rid of bi- > directional mappings then any direct business logic that requires > traversal in the "missing" direction can be readily accomplished by > access to the database. > > On Apr 27, 11:00 pm, Derek Chen-Becker <[email protected]> wrote: > > I may be misunderstanding this, but if you just do bidirectional mappings > in > > JPA then the DB query is generally efficient and transparent. Could you > post > > a little snippet showing what you're trying to do? > > > > Derek > > > > On Mon, Apr 27, 2009 at 2:44 PM, TSP <[email protected]> wrote: > > > > > Viktor, > > > It's a valid point, and I would where possible but I've got quite a > > > lot of uni-directional references (for example, addressable locations > > > in a city) where using a mapping would entail very large fetches that > > > are better handled by querying the database. Evans in Domain Driven > > > Design is very keen on uni-directional references and who am I to > > > argue :-) > > > Tim > > > > > On Apr 27, 9:10 pm, Viktor Klang <[email protected]> wrote: > > > > Why don't collection mappings work? > > > > > > Also, from personal experience, mixing persistence-logic in domain > > > objects > > > > does make you feel somewhat naughty. > > > > > > On Mon, Apr 27, 2009 at 9:15 PM, Tim P <[email protected]> > wrote: > > > > > > > Hi > > > > > I'm looking for some guidance here and I don't think this is > addressed > > > > > in the book. > > > > > > > I've got domain classes that need to go get stuff from the database > > > > > "list all ... " type of methods. > > > > > So presumably my domain class should have, or be allowed to have > > > > > methods that access Model > > > > > But my unit tests need to test these methods. So I need a model > which > > > > > is instantiated within the test environment and so does not need to > be > > > > > extended with RequestVarEM which presumably would be a bad thing > > > > > (though perhaps it's harmless). > > > > > Any suggestions on "best practice" to achieve this? (I'm still very > > > > > much trying to find my way round natural scala constructs) > > > > > > > Should it be mentioned in the jpa chapter in the book? > > > > > > > Tim > > > > > > -- > > > > Viktor Klang > > > > Senior Systems Analyst > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
