Michael Jouravlev wrote:
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.
Oops, typo, I meant DAO here of course.
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.
yes, I'd say EJB popularized the pattern, at least in part due to the
course granularity of the call protocol in EJB 1.0.
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.
I prefer not to introduce objects like this in the domain model unless they
actually make sense as part of the business domain. In other words, if
there is an entity type 'collection of employees' (as a distinct entity,
not just as a collection property on some other entity) in the business
domain, it makes sense for that to be reflected in the model. If not, the
list object is in the application domain and I prefer to keep it in the
service layer instead of the domain layer.
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.
Remember there's a distinction between 'we already model' and 'we already
store'. Also, DTOs are about transporting data from one layer to another,
i.e. as was pointed out elsewhere they're part of the API contract between
layers at least as much as they are a layer (or part thereof). Again, it's
a pattern popularized by EJB and the value DTOs provide gets less and less
clear the further you go from a course-grained, remote invocation call API.
Where I use them outside EJB is to create a distinction between the model
and the view; i.e. I use DTOs as 'view objects' which I pass into my JSPs
or whatever rather than passing the business objects directly. I know you,
and many others, dislike that practice though ;-) I do it so I have a place
to encapsulate view-specific logic, such as for example having a
UserDTO.getDisplayName() method which returns UserBO.getName() if set,
UserBO.getLoginId() if not.
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.
The key here is coding the application to optimize the database usage; if
you have an object with a lot of properties and/or references to and
collections of other objects and all you need to do is display a list of
their names, something that reduces to 'SELECT NAME FROM foo...' is going
to hit the database a lot less than something that pulls back all the data
associated with each instance.
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?
I'm not sure I follow you here. Yes, as soon as you start using DTOs you
have the (minor) overhead of copying data between the DTOs and BOs. I the
application is simple enough, the benefits of using DTOs wont be enough to
justify the cost/complexity of that, but it's not a lot of cost/complexity
in most cases.
On the other hand, application design is usually different for
read-only and for read-write applications (classic OLAP vs. OLTP
case).
Very true.
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.
There's more than one type of validation, though. For example, BOs should
be typed so they should never have to worry about 'is this a valid date?'
or 'is this an integer?'. BOs should implement validation consistent with
business rules to maintain system invariants but it's often appropriate to
have other types of validation in the service and presentation layers.
L.
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.
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
