Jens Schauder is software developer since 1997. He loves software development for the constant challenges and constantly changing environment. A great chance to learn and teach. He is also blogger, author of various articles and speaker at conferences. Jens is a DZone MVB and is not an employee of DZone and has posted 86 posts at DZone. You can read more from them at their website. View Full User Profile

Copying Objects in Layered Applications

  • submit to reddit

 In my last post I wrote about the dependencies in a layered application. There is another antipattern going on in many layered applications: Obsessive copying.

It might look like this:

The User Interface has some representation of the data input by the user, it gets copied over into some kind of transport object (often suffixed TO (Arrrrgh)), which then gets copied over into the domain representation of the data, and finally gets copied over into the persistence representation.

That’s a lot of copying. Not good. In many cases this is just waste. Waste on the runtime side of things when all these objects have to get created and garbage collected and on the implementation side of things when all the stupid code doing the copying is created and maintained. If you look even closer you often see much more copying, when your nice objects get converted to XML, JSON or some other serialized form.

When you see something like this you should start asking questions: copied over?

There are cases where you need to do some copying. For example when you transfer data between layers that are physically separate you have to serialize and deserialize them. But if you want to go from domain object to serialized data stream do you have to go via a transport object? Sure it allows you to use some nice magic library to create your JSON or XML or whatever you want to use. But is it really easier to copy data into a TO and then magically convert it into a JSON structure instead of just creating the JSON structure in the first place, possibly using a little Builder pattern?

If you need different properties in your presentation layer do you have to copy all the stuff over from the domain object? Or maybe you can just provide a thin wrapper providing the additional properties?

I’m perfectly with you if you don’t want the Hibernate mapped entities in your domain logic, because it is bleeding persistence logic in your domain logic. But if you don’t use the Hibernate Entities, is Hibernate really offering a benefit for you?

And beware of reflection for copying. It looks promising in the beginning, but if copying makes any sense at all the structures are different and your reflection based code will become more and more complex and slow. Oh and you might note, that things like Hibernate make extensive use of reflection and/or byte code manipulation
Published at DZone with permission of Jens Schauder, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jakub Holý replied on Tue, 2013/01/15 - 3:06pm

 Agreed, I have blogged about this as well: Bad Code: Too Many Object Conversions Between Application Layers And How to Avoid Them

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.