This content has been marked as final. Show 6 replies
Not possible with Java serialization, or XMLEncoder for that matter. I wouldn't use Serialization for a task like that in the first place: I would use a database.
Hi, thanks for the quick reply!
I do have a database already and the objects are stored there in the end. The serialization I mean here takes place on the network, from client to the server.
I wrote a system like this, and i'll just say that it was a bear to write and maintain. it kind of turned me off to the idea of making your DAO's and DTO's the same objects. i'm not sure i have a better solution to that problem that doesn't involve a lot of duplicate objects, but anyway.
the way i handled it was writing custom "clone-like" methods on the objects. i was able to write these in a generic fashion because we were using hibernate directly, which exposes all the entity "metadata". this allows you to reflectively clone an entity object without any per-type logic. then, you can write this "clone-like" behavior to create whatever sub-graphs of the entity graph that you want. you can then send these cloned sub-graphs over the wire. since you are only creating new entity objects (you can share the non-entity data, just like a normal clone), it doesn't add much overhead (considering you are about to send these objects over the wire).
javapollo wrote:First step - realize that it is impossible to write a system to generically handle every business scenario.
Do you know any possibility of achieving this in a generic way, without implementing the writeObject, readObject for every single Entity-Object? What would be your suggestions?
Second step - realize that generalization has a downside in increased complexity (and thus increasing maintenance when it comes to debugging, upgrading and even just understanding it.)
From that one decides on a reasonable middle ground where one uses some generalization for simple cases, such as an entity insert, and specific solutions for more complex business logic and even producing one shots for some business problems. And renaming a company might fall into that last category (unless you are in mergers/acquisitions.)
Examples of the second sort come about by realizing that when a user wants a list of company names (and perhaps some misc data) then they do NOT need the entire tree that represents a 1000 companies. All they need is the specific data that will be displayed and a id that allows them to request a single company. That concept generalizes to most trees that represent a lot of data (employees, inventory, etc.)
And myself I am a big fan of DTOs to allow boundary layer communications (and not solely as used for database layers.)
I am not sure if my idea is good.. :) I would say that u can use XML instead of serializing the objects.. There are many tools like JAXB available that will help you to read the XML and convert to object and persist the objects back to XML. You can use this XML for sending data to ur server..
A * R
That doesn't solve the problem because it doesn't inhibit sending the entire object graph.