We already use OSIV, thanks to guice-persist.
This means the read-side of things is rather trivial, and that the
service and dao layers do need to be aware of the exact data the view
needs (since lazy loading is possible).
With regard to the write-side of things: we do what you do (call update
explicitly) right now.
Suppose you are using DDD in a project, how would you go about
constructing and populating a new object? Without DDD my entities were
mere containers for data with some validation and JPA annotations. So it
was simply a matter of creating a Model which wraps a "new Customer",
and wicket pushing its fields to that customer object.
However, when applying DDD, that Customer is no longer a simple
container, but a business object. Having wicket push changes directly to
fields (those fields may even be private-access only, without setters)
seems to go against DDD fashion.
So I feel it would be better to create a DTO for a certain view (e.g.
NewCustomerDTO for a CreateCustomerPanel), and putting all validation
annotations on the DTO, too. When it's time to persist the new customer,
the service layer simply creates a new customer and copies all fields
from the DTO.
But then again, maybe this is overcomplicating things. DDD seems like a
good match for most of my projects though, and I'd like to be able to
properly integrate my domain objects with wicket.
Op 12-2-2012 15:17, schreef James Carman:
I just use open session in view. You can still retrieve stuff outside a
transaction. I explicitly call update to persist.
On Feb 12, 2012 7:54 AM, "Bas Gooren"<b...@iswd.nl> wrote:
Hi All,
I have an architectural question about wicket, DDD and the service layer.
Let's say we have a simple JPA entity (Customer), and a few simple CRUDL
screens.
For database access, we have a DAO layer (CustomerDao) which delegates to
an EntityManager, and provides some convenience methods for searching.
We also like to have clear boundaries, so we have a thin service layer
which wraps persist() and delete() calls in a transaction before forwarding
them to the DAO layer (@Transactional, as provided by guice-persist).
A wicket model fetches one or more customers (by id or by running a
search), and attaches to a form. In the form we use PropertyModels which
push their changes to the entity, and in onSubmit() we call
service.persist(entity).
This means that the actual changes to the model happen outside of the
transaction (in wicket code), and within the transaction (/service layer)
we merely call persist() and flush().
Then parts of the app need something a bit more advanced, so we decide to
apply parts of DDD and put logic where it belongs (on the domain models).
However, some logic coordinates multiple models, so we add a domain- or
application-service for that.
The good thing about DDD is that it's a lot more clear what happens
(intent). We now realize that having a persist() method on a entity-based
service now looks like a bit of a code smell, since it does not capture
intent at all. Also, since the changes to the model happen in wicket,
before the service layer is called, I feel that the service layer is not
doing anything to act as a boundary. We might as well mark the persist()
method on our daos @transactional and remove the service layer.
The only clean way to fix this seems to be either:
(a) using DTO's so the UI/wicket is not actually modifying domain entities
upside: the state of the domain is not modified by wicket itself
downside: duplication of models (actual model + DTO);
downside: validation is currently set-up in wicket by scanning fields
for validation annotations, so we would need to duplicate those on the DTO?
(b) using a concept from CQRS: sending commands to the domain through a
bus. This clearly and cleanly defines the intent and captures the exact
change.
upside: the state of the domain is not modified by wicket itself
downside: likely overkill for what we are trying to achieve; lot of
extra complexity
(c) wrapping the entire request in a transaction
upside: easy to implement
downside: since anything in the request can fetch a dao, read some
entities and modify them, this means we can lose track of what happens in a
request;
downside: feels like moving backwards
(d) simplify by removing thin services and, where necessary, putting more
logic in the dao's
upside: simple api contract: want to save/update an entity? use the dao
directly
downside: dao's contain logic which does not really belong there
downside: if at some point we really do need a service, the api
contract becomes less clear: for X and Y you can use the dao, for Z you
have to use a service
(a) and (b) provide a way to capture a change and execute all of the
change inside a transaction.
So my question to the list is: what are your experiences with this? How do
you deal with this in simple to moderately complex webapps?
Thanks for reading!
