Domain design causing full object graph serialization

Question

Hello,
I work on a project, based on 3-layer-architecture. We have rich client developed on swing, application server and we persist our domain objects in the database.
We map the domain objects using hibernate, send the same objects (means, we use POJOs and don't use DTO) via spring from application server to the server and visa versa in case the objects are to be saved, deleted etc.
We use an object identity store on the client side, in which all already loaded objects are stored.
My challenge is as follows:
- Since an object is stored in the object store, the same certain object is used in every GUI module. Imagine, we have customer, account and a list of transactions per account. In practice, let's say:
1 customer
2 accounts
1000 transactions per account which ever exist
- In one of the modules, the used loaded all list of transactions. So, at that moment, 1 customer object, 2 accounts and 2000 transaction objects are bound to each other via java references (object graph).
- On another module, the user wants to edit a very small attribute of customer object, say he corrects his birthday date and saves it.
- Saving operation sends the customer object to the server. But the problem is, a very big object graph hangs on this one little customer object and are serialized to the server, although the
service.save(customer);is called, and this costs extremely much time for our application.
boldSOLUTION:*bold* We solved the problem with a hack, as we used the serialization over XStream framework from Thoughtworks in xml-format. We could set a cut in the serialization and have serialized only the customer object for that use case.
So the problem for the save-use case was solved. This has a disadventage: the loading time (server-client (de-)serialization) using xml is longer than the java standard, especially remarkable if you load a big number of objects.
I've read many articles about the enterprise architectures which are related to domain objects, dto, serialization. It is not uncommon to avoid DTOs and use POJOs on the server and client as well, if the domain objects don't contain business logic. So, I just wonder, how the problem above should be solved smartly, if the non-DTO, say POJO alternative is chosen.
I appreciate your opinions.
I hope my question is not too long. Thanks in advance,
A sample code:
(The concrete case in our application requires the navigability from customer to account)
public class Customer implements Serializable {
     private Set<Account> acounts = new HashSet<Account>();
     // Getters, setters
public class Account implements Serializable {
     private Set<AccTransaction> acounts = new HashSet<AccTransaction>();
     // Getters, setters
public class AccTransaction implements Serializable {
     private String operation;
     private Timestamp timestamp;
     // Getters, setters
}Alper

Answer 1

acelik wrote:
Thanks for the quick answer.
The numbers are just wildly guesses, in order to keep the sample simple.
Actually we develop a system for automobile industry. So, instead of customer, you may think of a company, like Ford. Account would be then Fiesta. Instead of AccTransaction we may think a huge number of car pieces (clima, motor, radio, etc.).
So hierarchically we have
Company (Ford, Opel, etc)
Model (Fiesta, Astra, etc.)
Piece (1000 pieces per model, so Fiesta, Opel have 1000 different pieces each)
The problem is, if I loaded the Ford->Fiesta->1000x pieces for one view and then switch to another view. In the second view, I rename Fiesta to Fiesta II, and want to save this renaming operation using:
What exactly does that represent?
If you want to rename an existing car then you need logic to do exactly that. You do not copy the entire tree.
If however you do want to copy the entire tree then that is in fact what you must do. Although I seriously doubt that there is a valid business requirement for that. In terms of efficiency though you could write a proc that did that rather than propogating the tree.
Although further if you do in fact have two cars which use the same inventory item(s) then, again, you do not copy the entire tree because you are not creating a brand new inventory item. Instead you should only be pointing to an existing item.
I wonder how this problem is solved smartly, if you guys share domain objects between the client and server, and avoid DTO.The first step is to start with actual business requirements.