Business Objects(BOs) & Data Transfer Objects(DTOs)-need both ?

[Timothy Toe]

I apologise if this is not the most accurate forum to post this question...but since "JavaRanch Big Moose Saloon" does not have a dedicated forum to discuss architectural and design issues, this is the closest forum I can get.

In a J2EE system...

I know that "Business Objects" (BOs) are basically value objects (VOs) ...lots of getters and setters and some business logic. These are basically to model nouns in the system. Eg Student BO.

I know that "Data Transfer Objects" (DTOs) are value objects (VOs)....with getters and setters... with the purpose of avoiding multiple method calls...to avoid overhead...which effects performance. eg it's better to pass a Student DTO then say...pass the student ID and student name and student age etc etc.


Main question : Should a system have both ? If yes, why do I need a StudentBO.java and then another StudentDTO.java....when they are so similar ?...when both are basically VOs ? Can't I just use BOs to serve as DTOs ?


Thanks.

[Peer Reynders]

Originally posted by Timothy Toe:
I know that "Business Objects" (BOs) are basically value objects (VOs) ...lots of getters and setters and some business logic. These are basically to model nouns in the system. Eg Student BO.

Why to you think Business Objects are Value Objects? Many Business Objects are implemented as Composite Entities.
In the non-J2EE community the Business Object is referred to as the Domain Object. The collection of all your domain objects as they define state and behavior of your system is your domain/core object model. You will always need the Domain Objects - otherwise you don't have an "application".
The question is whether your system is complex enough and requires the decoupling between its various parts to warrant Transfer Objects. In J2EE the use of Transfer Objects is advocated to decouple the tiers. Transfer Objects are used to move data between the integration tier and the business tier. The transfer objects used between the Business and Presentation tier are often Java Beans.
Business Object
Transfer Object

Originally posted by Timothy Toe:
If yes, why do I need a StudentBO.java and then another StudentDTO.java....when they are so similar?

If they are so similar there may be a problem with your Student Domain Object definition; it may not actually be a Domain Object. A domain object usually has both behavior and state. Is it possible to refactor the behavior to other domain objects whichout duplication to turn the Student into a plain data container (probably not)? Are other domain objects doing part of Student's responsibilities (more likely)? Or is it simply that currently the Student object isn't doing much because the model is still simple but it is easy to see that it will take on additional responsibilities as the model's (system's) responsibilities grow? (quite likely).
[ November 18, 2005: Message edited by: Peer Reynders ]

[Vaithiya Sundaram]

I know that "Business Objects" (BOs) are basically value objects (VOs) ...lots of getters and setters and some business logic. These are basically to model nouns in the system. Eg Student BO.

No. Business Objects are NOT Value Objects and it will not have lot of getters and setters. BOs will use VO and applies business logic.

For example, in your case,
StudentDTO will have only attributes(like name,age,sex,etc) and, getters and setters for those attributes.

StudentBO will have/use StudentDTO to get/set student information and applies business logic methods like processStudentInfo(), determineEligiblity(), calculateAmountDue(), etc.
i.e. basically BOs are for applying business logic and results are stored in VOs and VOs are transferred to another tier or another BO's.

Hope it helps.

[Jim Janssens]

Originally posted by Vaithiya Sundaram:


No. Business Objects are NOT Value Objects and it will not have lot of getters and setters. BOs will use VO and applies business logic.

For example, in your case,
StudentDTO will have only attributes(like name,age,sex,etc) and, getters and setters for those attributes.

StudentBO will have/use StudentDTO to get/set student information and applies business logic methods like processStudentInfo(), determineEligiblity(), calculateAmountDue(), etc.
i.e. basically BOs are for applying business logic and results are stored in VOs and VOs are transferred to another tier or another BO's.

Hope it helps.

That makes sense.

So is it correct to assume that in your early stage class diagram, you will have a class called 'student'? And that within the next iterations Student is replaced by two different objects ? Like: StudentService (the BO) and Student (the TO). Having StudentService the operations you say: processStudentInfo(), determineEligiblity(), calculateAmountDue(), etc. and using student as a plain TO. ?

This would then basicly mean that you model both data and behaviour in the BODM and later on divide them (when needed) over different classes. In this case the TO will model the attributes of a student and the BO the business logic (behaviour) using the students data...
[ November 19, 2005: Message edited by: Koen Serneels ]

[Timothy Toe]

Thanks for all the replies. They did help me understand better.

This would then basicly mean that you model both data and behaviour in the BODM and later on divide them (when needed) over different classes. In this case the TO will model the attributes of a student and the BO the business logic (behaviour) using the students data...

I just find it kind of weird � the fundamental understanding and design of Object Oriented Programming is to have (encapsulate) both attributes and behaviours in a single class�.but now I find that we are splitting them up into 2 classes � TO and BO.

And� are TO and VO the same thing ? Both have attributes and getter/setter pair for each of its attributes and nothing more ?

Thanks.

[ November 19, 2005: Message edited by: Timothy Toe ]
[ November 19, 2005: Message edited by: Timothy Toe ]

[Jim Janssens]

Originally posted by Timothy Toe:
Thanks for all the replies. They did help me understand better.

I just find it kind of weird � the fundamental understanding and design of Object Oriented Programming is to have (encapsulate) both attributes and behaviours in a single class�.but now I find that we are splitting them up into 2 classes � TO and BO.

If you are developing a multiple tier system, you cannot do otherwise. Take for example that you have a java swing client and an application server. They are connected using iiop tunneled over http(s).

The business side (application server) has an object students, which calculates some things. In order to calculate them , some data from the datasource is needed. The student class therefore has a link to a DAO (assume you are using DAO's directly rather then entity beans). If you would send this object to the client, it would fail. Since the client environment does not have a datasource, and if it has , it has certainly not the same data as you.

So, you must separate your business logic and data. You have a class studentTO containing only the data and a service called 'studentService'. The student service will have a method: 'Student calculateSomething(Student s)' . You pass it a student object with the data needed to perform the calculation. Next the service will use the datasource to get the extra data, and to the calculation. The result is set in the student object, which is then returned as reply (this can also be a primitive, or another object offcourse)

[QB]
And� are TO and VO the same thing ? Both have attributes and getter/setter pair for each of its attributes and nothing more ?

/QB]

They are not the same. TO is a simple class with only getters and setters. A VO is a class that represents something, a currency for example. Read it here: http://c2.com/cgi/wiki?ValueObject

[Timothy Toe]

So, is it recommended to label BO as XXXService.java ? eg StudentService.java ...where it has calculation/processing methods such as calculateExamResult(), determineEntranceEligibility() etc ?

If above is correct...and since BO is a service, it should be implemented as Session Beans ? So, I have SBBOStudentService.java ?

And SBBOStudentService.java's calculateExamResult(TOStudent stu) takes in a TOStudent.java (transfer object)�and get the values from TOStudent.java�s gets methods to perform its calculations ?

How much of my understanding above is correct ?

I think I won�t be using EJB 2.x Entity Beans�since the industry is moving away from it and favouring Hibernate�s way of doing persistence - I guess this will be EJB 3.0�s persistence mechanism.

Thanks a lot.
[ November 19, 2005: Message edited by: Timothy Toe ]