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]