So, the DTO should always be created by the BO as a response for the Delegate call and then, forwarded from the Delegate to the client, right?
Does it mean that I have to write such DTO-packaging method like getData() for every business method that returns something different than a void and I would like to send it through the network?
I understand, that this is the typo in the BO listing you posted and it should be "return wrapReturnInTO(getPlayerNames());", right?
Should the IGame business interface declare these remote exceptions (and every other possible, as there might be a number of other networked-related exceptions)
Frits Walraven wrote:
Does it mean that I have to write such DTO-packaging method like getData() for every business method that returns something different than a void and I would like to send it through the network?
Yes, but don't forget that your business method could actually gather data from mutliple data interactions.
So, this is known as a Composite Entity which uses the Transfer Object Assembler pattern, right?
Is it allowed to make some Business Objects methods public, when they doesn't return a Transfer Object, like getPlayerAddresses() in the below code:
..... left out code ....
Or is it a bad design to introduce this approach, and every BO public method should return either nothing or a TransferObject?
So, the business delegate doesn't work as a proxy for the Business Object, doesn't it?
So, is the GameDelegate allowed to do such things, or it should be mapping 1:1 the Business Object public functions?
So if I have a "addPlayer(PlayerDTO)" method in Game BO, than in my BusinessDelegate it should be also "addPlayer(PlayerDTO)"?
So the BO is sending the DTO, so I understand that:
IGame - business interface
Game - Business Object
PlayerDTO, GameDetailsDTO, WeaponDTO, etc. - are my DTO's related with the Game BO?
Is this correct? So, the Business Object doesn't come with only one DTO, a BO can encompass many DTO's.
If so, than does the BO have any properties / fields within? I mean should it looks like:
public class Game implements IGame {
private Integer playersNum;
private String gameTitle;
private DifficultyLevelEnum difficultyLevel;
private List<Player> players; // Assume that Player is a different BO
...
// Public and / or private methods here
}
So, a Business Object can have a different Business Object as its field?
So, a Business Object can have a different Business Object as its field? But should it have a fields like "gameTitle", "playersNum", etc (which are already a part of the GameDTO)?
Frits Walraven wrote:Yes, the DTO is only for the outside world, the properties describe the BO.
and so on for every Entity in the application? there is a feeling of duplicated code creation (one property added to the Player object needs to be added in several other places like DB entity property, DTO object property, ...).
Data Access Object:
Consequences
Adds Extra Layer
The DAOs create an additional layer of objects between the data client and the data source that need to be designed and implemented to leverage the benefits of this pattern. But the benefit realized by choosing this approach pays off for the additional effort.
A Transfer Object is likely to duplicate code (getters and setters will shadow those of the EJB)
Here are we assuming that there is a class called TransferObject.
OCPJP 6.0-81% | Preparing for OCWCD
http://www.certpal.com/blogs/cert-articles | http://sites.google.com/site/mostlyjava/scwcd |