App Note on DTOs

[Peter Kriens]

Looking for feedback on an app note on OSGi DTOs …

Read at http://enroute.osgi.org/appnotes/dtos.html and PRs at https://github.com/osgi/osgi.enroute.site

Kind regards,

Peter Kriens

[BJ Hargrave]

Nice!

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
BJ

[David Leangen]

Hi Peter,

This is very interesting.

Because you are using the words “paradigm shift” (and yes, you are right, a paradigm shift is hard to make), I feel that I am not “getting it”. I think it is difficult for the mind to make a shift from reading only one article.

What I take:

 * How DTOs are constructed

 * The basic properties of DTOs

 * Comparison Java—>DTO, Javascript—>JSON object

 * The problem with beans (Maginot analogy)

 * Great for distribution

 * Ease of converting to and from different data notations (XML, JSON, ….)

I can “see” how this would be very useful for a REST-type API.

But I cannot “see” the paradigm shift you mention. You are advocating moving from OO to what? Something akin to a REST-oriented architecture? Or what am I not getting?

Cheers,

=David

[Peter Kriens]

You could have used less to word to say I was using too big a phrase :-)

Paradigm shifts are usually a variation on the previous themes. In a way your reaction reminds me of the reaction I got when I was a used objects salesman in the eighties and nineties of the previous century. I got similar lists from people telling me that OO was nothing special. Just a struct with a list of functions. 

It was only when people started to architect around the concepts of inheritance and data hiding that we got the benefits of this model.

I do believe service oriented programming requires this kind of thinking. It does not throw away objects but the insight that the data that is transferred over the service boundary is public is an important insight that I do not see recognized and is causing a lot of unnecessary work.

But maybe I am too high on my horse :-)

Kind regards,

Peter Kriens

[David Leangen]

So, the “core" concept that you think is a big shift boils down to:

 * Data encapsulation (hiding) is a myth

 * If we embrace that myth, we gain clarity

 * This clarify helps us to avoid unnecessary work (due to coding a bunch of crud to try

     to hide data, when you can’t really hide it, anyway)

Something like that? Or am I off track?

I’m not trying to rewrite, just trying to parrot back in my own words to ensure that I get what you are saying.

Cheers,

=David

[BJ Hargrave]

It is not a myth. The point is that when you do remote calls, your data _is_ API. Whether it is an XML document, a JSON document, a serialized Java object or a DTO. DTOs are about acknowledging that your data is API when you send it in a remote API call.

--
BJ

[Peter Kriens]

As I warn in the paper, don’t go over board. DTOs should only be used when your data is already public API. There is a great deal of advantage for using classic objects for other cases. All code that only runs in your process should use objects because you can often make things more elegant and easier to change.

As usual, the greyness makes it hard to see where the line is. :-)

Kind regards,

Peter Kriens