[Lift] Re: jpa, emf Model and unit tests
But you don't want the Session in the domain model I thought. Anyway, after a few hours digging around looking at how other people do this stuff with respect to DDD in particular, it looks like I am asking the wrong question to a certain extent. The way it is done in the DDD site sample app (dddsample.sourceforge.net if you;'re interested) is to have repositories - one for each aggregate - set of linked classes (typical example is an order which aggregates order lines and possibily delivery history). The repositories are implemented as interfaces and have persistence neutral finders get all outstanding orders with credit-stopped customers for example. This is part of the domain model, but returns typical jpa/hibernate persisted objects. The implementation of the repository is hibernate aware and uses getCurrentSession() quite freely. The implementation is injected via spring. Back in my context, this means I want my repository impls to be EM or session aware too - so my original question stands - but the repository mechanism separates the domain model from the direct persistence layer which should allay your concerns. Tim On Apr 28, 6:48 am, Viktor Klang viktor.kl...@gmail.com wrote: Also, if you use Hibernate, you can use: *Session.createFilter*(city.getAddresses(), where this.name like 'S%').list(); On Tue, Apr 28, 2009 at 5:31 AM, Derek Chen-Becker dchenbec...@gmail.comwrote: --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: jpa, emf Model and unit tests
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 -~--~~~~--~~--~--~---
[Lift] Re: jpa, emf Model and unit tests
OK, the DDD approach makes more sense. Having a layer of repository DAO
interfaces that can be implemented by concrete provider classes is a common
way of separating this out, and is much cleaner than having any DAO
functionality on your entities proper. Just thinking off the top of my head,
you could implement this as a manager object, like:
object EntityRepository {
var engine : EntityDAO = _
}
trait EntityDAO {
def locateAddress(addr : String) = {...}
...
}
class HibernateDAO(sessionFactory : ...) extends EntityDAO {
...
}
Then you can set the engine in either your Boot.boot, or in your test setup
hooks based on your needs.
On Tue, Apr 28, 2009 at 2:50 AM, TSP tim.pig...@optrak.co.uk wrote:
But you don't want the Session in the domain model I thought.
Anyway, after a few hours digging around looking at how other people
do this stuff with respect to DDD in particular, it looks like I am
asking the wrong question to a certain extent. The way it is done in
the DDD site sample app (dddsample.sourceforge.net if you;'re
interested) is to have repositories - one for each aggregate - set
of linked classes (typical example is an order which aggregates order
lines and possibily delivery history). The repositories are
implemented as interfaces and have persistence neutral finders get
all outstanding orders with credit-stopped customers for example.
This is part of the domain model, but returns typical jpa/hibernate
persisted objects. The implementation of the repository is hibernate
aware and uses getCurrentSession() quite freely. The implementation is
injected via spring.
Back in my context, this means I want my repository impls to be EM or
session aware too - so my original question stands - but the
repository mechanism separates the domain model from the direct
persistence layer which should allay your concerns.
Tim
On Apr 28, 6:48 am, Viktor Klang viktor.kl...@gmail.com wrote:
Also, if you use Hibernate, you can use:
*Session.createFilter*(city.getAddresses(), where this.name like
'S%').list();
On Tue, Apr 28, 2009 at 5:31 AM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Lift] Re: jpa, emf Model and unit tests
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 tim.pig...@optrak.co.uk 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 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 -~--~~~~--~~--~--~---
[Lift] Re: jpa, emf Model and unit tests
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 tim.pig...@optrak.co.uk 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 viktor.kl...@gmail.com 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 tim.pig...@optrak.co.uk 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 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 -~--~~~~--~~--~--~---
[Lift] Re: jpa, emf Model and unit tests
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 dchenbec...@gmail.com 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 tim.pig...@optrak.co.uk 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 viktor.kl...@gmail.com 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 tim.pig...@optrak.co.uk 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 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
-~--~~~~--~~--~--~---
[Lift] Re: jpa, emf Model and unit tests
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:
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 dchenbec...@gmail.com 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 tim.pig...@optrak.co.uk 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 viktor.kl...@gmail.com 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 tim.pig...@optrak.co.uk
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)
[Lift] Re: jpa, emf Model and unit tests
Also, if you use Hibernate, you can use:
*Session.createFilter*(city.getAddresses(), where this.name like
'S%').list();
On Tue, Apr 28, 2009 at 5:31 AM, Derek Chen-Becker dchenbec...@gmail.comwrote:
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:
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 dchenbec...@gmail.com 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 tim.pig...@optrak.co.uk 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 viktor.kl...@gmail.com 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 tim.pig...@optrak.co.uk
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
