On 8/4/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
> The idea of a DTO is to encapsulate the persistence logic so that it can be
> independent of the model representation and business logic, and easily
> replaceable.

I thought that this is the idea of DAO.

> There's nothing saying you can't put an update() method on
> your business objects and have it delegate to a DTO but you risk having an
> explosion of data access methods on your business objects that way. Since
> persistence is typically a quite separate concern from other domain logic,
> it makes sense to separate it out.

This I agree with, moving persistence details to DAO is good. But DAO
is not DTO ;-)
 
> Looking up lists of things is sort of a meta-concern; you're right, putting
> that on the Employee object would clutter things up, especially when you
> start needing more complex queries -- e.g.
> getEmployeesEligibleForPerformanceBonus() etc.

If I remeber correctly, EJB encouraged practice like that.

> Since these kinds of
> operations are a higher level concern (i.e. they aren't operations on
> employees but on the entire data class) they should typically live in a
> higher layer.

I would prefer other Rick's idea of having another business object
like ListOfEmployess with different finders.

> OO generally talks about grouping behaviour and data together, so factoring
> out the properties into a separate object would be less OO than factoring
> out a sub-set of the behaviour (the CRUD actions). In particular, CRUD
> actions are not behaviour of the business object ('save employee object to
> the database' is not an operation that makes sense in the context of the
> business domain, it's an implementation artifact [speaking broadly]).
> That's partly what makes them a good candidate for encapsulating separately.

Agree with that.

I would like to return back to the objects. I still think, that a user
works (at least wants to work) with objects, either with singletons or
with sets of objects. Real-life objects (the ones the user wants to
work with) are represented in the application, and OOP theory is all
about representing real objects with app objects. So, if the modeling
and representaion is done right, we do not need DTOs, because we
already store objects that are of interest for a user.

I can understand the idea of loading only 2 fields out of 20 or
aggregating several objects into one, but I really would not care
unless we loading a set of objects.

So, DTOs are useful where:
* model was done incorrectly
* in cases of really severe bandwidth contstraints
* for sets (lists) of objects

Now what if you have list of objects, and you create another one? If
you use DTOs, you need to save DTO1 to database, and also to create
and insert DTO2 in the list. If you had real object, you just create
it, save it, and add to the list. One object instead of two. Of
course, you can reread the list after you save the object, but this is
unefficient, right?

On the other hand, application design is usually different for
read-only and for read-write applications (classic OLAP vs. OLTP
case).

I am for having persistence separate from business objects, but
factored-out persistence still needs to build proper SQL statement
depending on the object it saves... I am against putting validation
outside of business objects. Validation rules belong to business
objects, imho.

On 8/4/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> Then I had a special Action base class that worked against an XML file.
> So, in keeping with my examples from before, you might see:
> 
> <action name="action1">
>   <function id="1">createDTO:ClientDTO</function>
>   <function id="2">copyActionForm:ClientDTO</function>
>   <function
> id="3">callMethod:ClientHelper.isClientValid(ClientDTO)</function>
>   <check sourceid="3">
>     <if outcome="false">returnForward:clientnotvalid</if>
>   </check>
>   <function id="4">callMethod:ClientFB.saveClient(ClientDTO)</function>
>   <check sourceid="4">
>     <if outcome="true">returnForward:goodsave</if>
>     <if outcome="false">returnForward:badsave</if>
>   </check>
> </action>
> 
> The createDTO, copyActionForm, callMethod and returnForward were standard
> "commands" I could issue.  I got it working to this point, never took the
> exercise any further...

Hmm, my CRUDAction does almost exactly the same, but it has predefined
list of events (methods) and outcomes.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to