[OT]DTO Pattern (was Re: [RT] Attribute Rendering and CForms Convertors)

[Ralph Goers <Ra...@dslextreme.com>]

Leszek Gawron wrote:

> There is one big difference when using Hibernate(d) model: You do not 
> have to use DTOs so it's easier to scale the system but harder to 
> enhance particular views with some specially rendered data.
>
> I try to avoid DTO pattern as much as I can.

This is completely off topic. 

My guess is that your system has a presentation tier and a database?  We 
want to have all our business logic in a separate tier from 
presentation. In our case this happens to be an EJB container.  Thus our 
database structure, our entity model and what is actually returned to 
the presentation tier might be very different things. I don't see how 
you can do that if you are going straight to Hibernate.

I'm not saying we couldn't use Hibernate. However, if we did it would be 
in the business tier as a way to persist our entities. Converting to do 
that would have no impact at all on our DTOs.  Even if we combined the 
presentation tier and business tier, I'd probably still use the pattern 
just to keep the clean line between the presentation logic and business 
logic.

Re: [OT]DTO Pattern (was Re: [RT] Attribute Rendering and CForms Convertors)

[Leszek Gawron <lg...@mobilebox.pl>]

Ralph Goers wrote:
> Leszek Gawron wrote:
> 
>> There is one big difference when using Hibernate(d) model: You do not 
>> have to use DTOs so it's easier to scale the system but harder to 
>> enhance particular views with some specially rendered data.
>>
>> I try to avoid DTO pattern as much as I can.
> 
> 
> This is completely off topic.
> My guess is that your system has a presentation tier and a database?  We 
> want to have all our business logic in a separate tier from 
> presentation. In our case this happens to be an EJB container.  Thus our 
> database structure, our entity model and what is actually returned to 
> the presentation tier might be very different things. I don't see how 
> you can do that if you are going straight to Hibernate.
Data passed from view mostly consists of hibernate entities (and a bunch 
of configuration variables but that doesn't count). Almost whole system are:
- CRUD views (create/update/delete) handled by CForms
- entity listings that allow proper navigation

The remaining 10% was of course most interesing to implement. There are 
some cases (i.e. reporting, complex data manipulation) when a special 
structure is being passed to the view that aggregates a lot of 
information from different entities. That probably is something very 
close to your DTO but as it gathers very different data I wouldn't call 
them DTO (Still I might have a bad idea about what really DTO is).

When using O/R tool and having a model that defines a lot of lazy loaded 
depencidencies you rarely need a custom DTO for the view.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65