{{ !articles[0].partner.isSponsoringArticle ? "Platinum" : "Portal" }} Partner

Copying Objects in Layered Applications

 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 {{ articles[0].authors[0].realName }}, DZone MVB. (source)

Opinions expressed by DZone contributors are their own.

{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks