transfer object

[Saha Kumar]

All,

I am planning on using a FlightDAO to return flights which match client criteria. The FlightDAO will return a transferObject(TO). The returned TO will be an array of flight objects. I would like each flight object to be composed of: DateTime->Flight->Equipment, where DateTime is an object which can have 1-to-many Flight objects, and the Flight object can have one Equipment object.

Is it correct that a TO can be comprised of other objects, or must it be one-dimensional? I read that a TO must be immutable. Is this correct?

Thanks for any help.

-Saha

[s khosa]

Need some clarification on this. What are you Flight/Equipment object representations? Are they POJOs or EJB objects?

If you are using multiple objects to create your transfer object then TransferObject Assenbler would be a good choice.

Thanks

[Saha Kumar]

Thanks for the reply S Khosa. I was planning using a DAO to read the data. I want the DAO to return an array of TransferObjects. So I will take your advice and use the TransferObject assembler. The DAO uses JDBC, and the assembler will take each resultset and create an array of TransferObjects.

I didn't know if a TO could contain an array of TOs, etc.

I thought I read that a TO had to be immutable. Is this true?

Thanks for the help.

-Saha

[s khosa]

Immutable...hmm...have not heard..and my guess is it should not be the case. I would look at value object as a copy of the data fetched from data source. Different client accessing your airline ticketing system could have different value object copies representing , say you Flight data stored in the database.

So why would we make an individual copy of value object immutable?

Thanks

[Saha Kumar]

According to:

http://java.sun.com/blueprints/patterns/TransferObject.html

Here is part of the article below. I changed to caps that TO should be immutable.

Sample application class OPCAdminFacade (see Session Facade) has a method getChartInfo that returns an immutable, serializable collection of OrderDetails objects, each of which is a transfer object that represents data from an order. The collection returned by method getChartInfo is also a transfer object, because the values it contains are always accessed together where they are used. This hierarchical transfer object is implemented by class OrdersTO .

Figure 1 shows the structure of the OrdersTO transfer object. Class MutableOrdersTO, which extends a serializable ArrayList, contains a collection of OrderDetails objects. But because MutableOrdersTO extends ArrayList, it is mutable. TRANSFER OBJECTS SHOULD BE IMMUTABLE so that clients do not unintentionally change their contents. Interface OrdersTO adapts the MutableOrdersTO collection, allowing read-only access to the collection while preventing modifications.


Saha

[s khosa]

As per my experience Transfer objects can be mutable. A client should be able to set data to trnasfer objects and send them back to business objects.

For e.g In Your case, if you are sending An array of flight objects to the client, it also implies that client should be able to select one of the flights "marked for reservation". So your transfer object should have something like 'applyReservation' flag. This object can be passed completely to the BusinessObject e.g through a setData() method and it can internally set it to database via DAO.

Does this sound correct to you, or am i missing something?

Thanks

[Saha Kumar]

Thanks, s khosa for the response. Yes, you are correct...just have to have setters for only data which can be changed. An example is the apply reservation flag, as you mentioned.

Thanks!

Saha

[Parag Bharambe]

I think the when somebody said/mentioned transfer object as immutable is because most of time TO contain data that will be used only for display purpose.

But TO can also be mutable, one has to devise strategy for how to deal with them.

There are various quotes in the forum regarding where TO should be mentioned.
Do we need to mention TO in Class Diagram Or in sequence diagram?
Which one is better way?

[Saha Kumar]

Hello Parag,

I am planning to put the classes that are contained in the TO into my class diagram. The actual TO will be in the sequence diagram and not the class diagram. For example: Flight, Equipment, etc. objects are contained in TO and will appear in the class diagram.

I hope I'm on the right track, does it seem so?

Thanks.

Saha

[s khosa]

Why would you not show to TO as part of class digram? My guess is you should because TO would be something like a composite object and it would share a relationship with the business object that is generating it. Infact i checked on sun's j2ee patterns guide for this and they have shown TO as part of class diagram.

Thanks

[Saha Kumar]

Hello s khosa,

Infact i checked on sun's j2ee patterns guide for this and they have shown TO as part of class diagram.

Could you give the url of the class diagram you mentioned? I wasn't planning on including DAO, TO, factories, etc. in the class diagram. Only classes such as: Flight, Equipment, Itinerary, etc. I also want to include stateless session beans in the class diagram to follow Cade's class diagram. The TO would show up in the sequence diagram.

Am I on the right track? Do you agree with this?

Thanks.

-Saha

[s khosa]

Ok...i needed some coffee at that time..:-(. They are showing valueObject in the class diagram.
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html

But i still think showing Transfer object would not hurt. Again as an architect your role would be to hand off the design document to the developers, and they should be able to start coding from that point..:-)

But its a matter of choice. I would atleast show the main DAO class and its mapping with the Entity/Session Bean. I think this would make it better as far as readability goes.

BTW, thanks for asking all these questions. They sure have helped me in introspecting the way I want to design the application...though i am feeling plain lazy right now and dont plan to start on it for another few weeks..:-)

Thanks

[Parag Bharambe]

Hi,
I think there is no harm in putting TO in class diagram. But if we mention all the TO, then the class diagram will be clutter with lots of classes and relationships.

I belive the class diagram should have Domain classes and application classes that are related to the domain classes. In Case of TO, althouth they are related to Domain classes, but they do not have add a great deal of value to class diagram.

Any thoughts?

Parag

[Saha Kumar]

Parag,

What you say makes sense. I will try to put the TO and DAO only in the sequence diagrams.



s khosa,

Thanks for your help and discussion...enjoy the break.

-Saha