Jeromy Evans wrote:
Mansour wrote:
An alternative approach is that you don't allow persistent entities
to be modified within your actions whatsoever and all updates are
applied behind a service layer that performs reattachment and updates.
How do I do this (reattachment and updates)? Assuming I have a very
big and complex entities.
The most appropriate approach depends mainly on the complexity of
your entities and the separation of concerns you require.
OK, that's what I have in my business layer. Tere's a facade for my
business layer. The actions can obtain a reference to this facade
through the session by implemeting SessionAware.
In this case, at the layer interface you would manually transfer the
relevant content of the persistent entities to simple beans created
especially for the use-case. Your actions use the beans, not the
entities. Updates from the beans are manually applied by your code to
the persistent entities behind the layer (load, apply changes
manually, persist). These simple beans are sometimes called Data
Transfer Objects (DTOs), and by manually I mean you have to write code
to explicitly apply the conversion and updates to and from the simple
beans and persistent entities.
This is exactly what I was trying to avoid doing in the first place. The
way my code works now is by taking the bean from the view and pass it to
the business facade, where it over writes only the properties that have
changed. But again, what If I have complex Entities. On the other hand,
this approach forces you to consider the view when you are working in
your model, so you have to keep in mind that this properties are
populated by the view and it's (IMHO) against the pattern of DAO, where
you use only object (DTO) to communicate between different layers of the
system. In this approach we are really using properties (fields) that
are wrapped in an object.
The way I want to do it, is to totally separate the layers, so if I
needed to update or modify different fields in the future, I shouldn't
touch the business layer, as this is not really a change in the
functionality. Makes sense?
I think the approach you gave me earlier is the best in this case, which
is to use the preparable. Any advice or comments or tutorial about how
to use preparable in this scenario?
This comes at great cost in terms of the amount of code and testing
required as well as processing performance compared to the other
approach. The advantage is that the layer can provide strict
constraints on how data can be viewed and updated (good security),
your business layer is COMPLETELY distinct and independent of the view
(good when you have large teams or multiple views) and the business
layer can easily be distributed (remote and/or clustered services).
That's essentially the basis of EJB. If you ever use GWT you'll also
take the same approach. I stress though, that's a lot more effort and
the additional cost is not appropriate in most web applications.
Glad I could help,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
