DTO are presentation of business objects. Let's say that your client needs to retrieve some data from a Customer's table. The table resides in a relational database. A business object could be a class composed of state and behaviours on your Customer's table. For istance it could provide all the get/set methods and other business methods related to the Customer's table(i.e. update customer's info, retrieve customer's info and so on). The final result of a Customer's Business Object execution shall be to create an object with the relevant information, in other words the object being informed is the DTO. DTO will not have any business method in it, it represent a course grained whole of the Customer's info. Then, the view components, could use totally or partially the DTO to display info to the client(in the presentation lyer).
If I could suggest an approach, you shouldn't spend too much time in undestanding the 'words' but more likely the 'concepts'. Let's say that in a web application there are different lyers: for sure you will have presentation, business and probally data lyers. The bibliography suggests that your application(in this case your Struts application) shall decouple the presentation lyer from the model(business logic) lyer from the data lyer(which is also the concept behind J2EE architecture). It's clear if you think at your application with a composition of components. As we are going ever much towards the open source market(therefore towards the open source products) it will be likely that you could change one of the lyer's product any time. The goal of your application should be to be able to do that, without changing the others lyer's code. You should be able to change the Struts framework, or the business logic framework, or the data access framework withoth changing any of the other lyers. Hope it will help. Marco -----Original Message----- From: Vinay [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 9:51 PM To: Marco Tedone Subject: Re: Packaging struts business logic and action classes Thanks Marco, Now I have a clear perception of all these concepts.I am working with struts with no EJB involved and trying to relate my application to these concepts. I have two struts action classes, a DTO ,DAO and Business Delegate. Are DTO's in my application business objects (or) Are both business objects and DTO's mutuually exclusive?. I am little confused about the distinction business objects and DTO's I am new to J2EE and so started with struts without involving EJB . Thank you vinay ----- Original Message ----- From: "Marco Tedone" <[EMAIL PROTECTED]> To: "'Vinay'" <[EMAIL PROTECTED]> Sent: Thursday, January 23, 2003 1:20 PM Subject: RE: Packaging struts business logic and action classes Dear Vinay, As far as I know I could tell you the following: All the concept you mentioned lead to decouple layers. Business Objects are a wide concept to identify entities which are involved in the business domain and which have states and behaviours; someone identifys them with nouns in a business domain. Examples could be persons, things, concepts. For a class to be considered Business Object it should have the following characteristics: A) Consists of state and behaviour B) Represents a person, place, thing or concept from the business domain C) Is reusable The only DAO concept I know for the moment is related to the DAO pattern, which goal is to decouple the business logic of an application from the data access logic. Using the DAO pattern lets you to change the underlying database without changing your business logic. Value Objects and Data transfer Objects are interchengeable words to mean the same thing. They provide a coarse-grained view of remote, fine-grained data. While Business Objects aim to decouple business logic from data-access logic, DTOs aim to decouple presentation from business objects. In a word they are presentation of business objects, but instead of them, they usually don't provide any logic at all. Using DTOs leads to a better maintenance and extensibility. Marco -----Original Message----- From: Vinay [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 3:34 PM To: Struts Users Mailing List Subject: Packaging struts business logic and action classes Can somebody please clarify or explain the following 1. Business Objects (BO's) 2. Data Access Objects (DAO's) 3. Value Objects (VO's) 4. Data transfer objects (DTO's) All of the above I know is part of the Model(M) in MVC architecture.I think that Value Objects and DTO's are the same , and they have setters and getters.Correct me if I am wrong. What is the general way of packaging a struts application? like if my companyname is www.companyname.neti will probably have an application or context as applicationname as its name. I would like my business logic to be independent from the struts specific controller(action classes) . I also know the package should start with net.companyname.applicationname. Thanks in advance. Help appreciated. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
