DTOs: Don’t Trust Oafs

What do you — no, no, I did have a good Memorial Day. I just — I know about the hot dogs. I can’t talk about this, holy Moses, the post is starting. Sorry about that folks, blogcast engineer arguing with me as the post started. How are you? I am your Code Agitator on the Excellence In Programming web-ring, here for another 1200 words of exposition and hallucinations.

There will be no Hydrocon this week on account of my Memorial Day weekend involving the outside world. Yes, yes, I readily accept your accolades for tearing myself away from the EIP standard issue keyboard for a change.

DTOs can get tiresome. Done appropriately, they are only partially tiresome. If your web page contains a drill-down capability, then most of your DTOs will in fact be partial snapshots of some of your domain objects. But sooner or later, they produce Parallel Object Models when your drill-down ends.

One Domain Object and multiple DTOs enter, one solution leaves

Maybe this is why requirements are such a troublesome part of a project. And maybe this is why business system analysts exist.

Unlike as promised, we will not be completing the requirements of the Carbon Copy Whiteboard today. That post has been postponed indefinitely. I have refilled my reservoir of post ideas, and the dryness of subjective ordinal scales is no comparison for what I have planned!

In other words: unfortunately for you, the reading public, I won’t be running out of things to say soon.

That said, I’m surprised that today’s post hadn’t come up sooner. Consider the following.