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
-~----------~----~----~----~------~----~------~--~---
