Thanks for the reply. It sounds like you and I had similar experiences. I
actually did something similar to your DAO setup at first, but really missed the
convenience of lazy loading and cascading.
You are absolutely correct about one thing; transferring (complex) detached
entities over the internet does not work well in the real world, yet it seems to
be the most common tutorial example I've seen.
All of the tutorial / examples I've seen do a pretty good job as 'getting
started' documentation. However, I've been finding there's a lack of resources
(even commercial books) when it comes to building real world applications.
I ended up trying several solutions for working with data in an application
client just to 'see what worked best'. I suspect the situation will improve as
more people start building rich clients and working on rich client architectures.
Ryan
Witold Szczerba wrote:
> In my application, the first plan was to use something like 'strategy
> 2' but for each entity there was separate session bean. It was
> implementing some generic CRUD interface, similar to the one of yours,
> but with generics. The reason of splitting CRUD implementation was the
> ability to add some specific logic like security constraints.
> Moreover, each session bean had to implement other functionality
> regarding given entity.
> The plan was working fine until we found few problems. First one was
> terrible performance. Some @Entity objects were too big, I mean they
> were connected to other entities, other entities were connected to
> another... and so on. When client was asking for one entity to show it
> on a form, too much data was about to travel across the Internet.
> There was something worse - the way we were thinking about changing
> entities was coupled with our needs regarding GUI. That was
> unacceptable to me, so I decided to introduce DAO. Now, each session
> bean has a pair of methods, for example:
>
> public PersonDTO entity2dao(Person entity) {...}
> public void dao2entity(Person entity, PersonDTO dto) {...}
>
> Now, we can modify DTO, so it can fit client requirements much better,
> for example, when we show some person on a form, we want DTO to
> contain all its properties. But we do not need to download all the
> properties of all his/her companies, loans, documents and so on. We
> can, for example we can show on the form only the number of his
> companies or loans, and when user clicks on the button, we can
> download LoanDTO. Client knows nothing about Person, Loan, Proposal,
> he asks for PersonDTO, LoanDTO, proposalDTO instead. That gives you
> much more power and flexibility. The price you have to pay is extra
> entity2dto and dto2entity methods, but as far as I know, there is
> nothing you can do. Using detached entities downloaded using Internet
> can work only for a tutorial presentation, it will not work for
> anything bigger.