i saw it in the HibernateJAOO ppt

i can't exatly understand the meaning of this section:



what's the meaning of DTOs?

and how is LOC?

any help is high appreciated!

Data Transfer Object
Lines Of Code

thanks , gavin

i am building a ppt to introduct Hbernate to my company.

i wanna more people to enjoy the Hibernate World!

What's the alternative to DTOs if you don't want to expose your domain objects, detached or not, to your presentation layers?

Nothing. DTO is a (partial/ aggregate) copy of your domain model.
Your domain model is what you need to think about. So opening it as a public API seems quite good to me. Most time, domain model updates will update DTO (or whatever you call them)

Why do you not want to expose your domain objects to the presentation layer? You don't like object orientation?

I subscribe to the (IMO extremely sound) principle of architectural serparation of the major layers within an application, therefore I must not like object orientation?

I did think as you did, but as a developper, I was sick of rewriting my domain model to a new DTO domain model for almost nothing.
I know it envolve agile devt and this not so accepted, but in real life it's quite convinient (IMO).

Soundness is in the eye of the beholder.

Let me ask you a question: do you actually achieve any real seperation here? Or do you really just achieve code duplication?

Is it really the case that your presentation layer does not change when you change your domain model?? I have never ever seen a single practical case where I made a change to my domain model that did not also involve some change in my presentation layer. All the extra DTO layer meant was that I had to change in three places instead of only two. This is what Fowler calls the "shotgun change" code smell.



Sounds like it. DTOs are not objects (state + behavior).

Hmmmmm, quoting from Fowler to back up one's arguments. Sounds like fun - let me try:


Chapter 1 - "Layering", 2nd paragraph, page 17.
Patterns of Enterprise Application Architecture (written & published much more recently than the refactoring book)


Now seriously, in the words of another wise man, I don't want this to degenerate into a pissing contest.

In part at least, I do agree with you. We do actually achieve some real separation, but it's really hard it's imperfect at best and it does suffer from all the problems you've mentioned. To be honest, I've been asking myself some hard questions about the real value of strictly enforcing separation of the application layers this way, and I actually am pretty sure it's not worth the level of effort it takes.

But on the other hand, I don't know what else to do.
Layering sounds like a good idea, it's just that enforcing the separation of layers (which is the whole point) just turns out to be too hard. But is the answer really to just throw away the concept and say "it's too hard, so we'll just let the domain model propogate back up to the presentation layer, stop thinking about it and tell anyone who asks that they don't know squat about real object orientation"?



Actually, yes, for small changes. We've created a concept we call Declarative DTOs, where the DTO is not only a packaging for the data, it is also a declaration of where in the domain model (given an arbitrary graph root) each attribute comes from. So when attributes move around, the DTO can actually track those movements. Of course, it only works for simple changes; but then if the domain model really drastically changes, the presentation layer will change too (uh-oh, sounds like a shotgun change, better refactor that domain model away from the GUI, eh?).
That said, our Declarative DTOs suck, thw whole concept sucks and I wouldn't recommend anyone even bother with the idea. But what else to do?

You said in your blog that Christian got very excited about CarrierWave a while ago - which kind of implies that he's not excited about it anymore? I looked at it and it seems like it might be a way forward, especially with a quote like this from their front page: I'd really like to hear from Christian on this if he did any serious research int it?

Also, from your blog entry and on the dev mailing list, you've been talking about SDOs lately. Do you see them being useful for this kind of stuff, or are you looking at them from some other kind of perspective? (maybe looking at making Hibernate intergate as one of the datasources or something)

CarrierWave is still very very interesting, because it addresses all the concerns discussed in this thread. The jury is still out if CarrierWave, SDO or any of the other approaches (some people even try to use XML, but I don't think its a good choice for various reasons) is the way to go.

I'm still making up my mind about this, in fact, I've been thinking about the decoupling of the UI tier for quite some time (a year?), but never had the patience to think it through.

Because I'm talking about this in my presentation at JavaPolis, I'm having a look at CarrierWave again right now. You can expect more on this subject in the next weeks, it's definitely at the top of my list. Oh, there is even a (messy) Wiki page I started some time ago:

http://www.hibernate.org/Documentation/ ... chitecture

Sorry, my comment wasn't meant in that way.

I just try to challenge people to think about things and not sign on to concepts like layering where they are not appropriate.

Overengineering is absolutely endemic in the J2EE community and is really starting to threaten the very existence of Java. Microsoft exploit this mercilessly at the moment.

I know, you started it based on a topic request I posted :)
But it never turned into what I wanted, which was someone else to do all the thinking and then tell me how to solve the whole issue :\

Incidentally, will all the Hibernate team (including yourself) be having Hibernate related blogs?

Cheers,
Shorn.

Ideally I would be using my persisted object classes as my DTOs. They're really just beans, so the only issue I currently have is that Hibernate collections serialize to Hibernate collections, so either my clients need to have the hibernate jars (a pain), or I need to rebuild each object with a copied collection. On another thread someone discussed modifying the writeObject methods in the hibernate collections so that they write out a normal serializable collection. I don't know if this will break anything else, but it seems useful to me...

Derek

My 0.02c worth:

Back in the 'bad' old days of SQL client-server, the domain model was exported directly to the client/business layers via SQL visibility. This seems to have suffered from undue linkage between presentation, business, data model and database layers, for various reasons.

As hibernate objects are basically copies of the data model, we may be going back down the same route.

If we want to use a layered architecture, 'plumbing' as it is called seems a necessary evil. In many ways the DTO pattern provides an abstracted interface between layers which means that for large (or should that be very large :-( applications, changes to the data model to support NEW functionality can be implemented in the most effective manner while avoiding changes to application which access related entities.

I agree there is a lot of plumbing to do, but the ability to keep layers independant (of domain changes as well as technology and tools used) and retain pure-java relationships between objects (not to belittle Hibernate's collections) helps this.

Control over DTO's and serialisation also brings control over performance (especially for remote communications) back into the application.

I deplore the additional work, over-engineering, multi-point (shotgun) changes etc, so have been looking for alternatives.

The best approach seems to be a Model Driven Architecture (MDA) which was rich enough to generate all required entities, relationships etc. This is a complex (and generally expensive) beast.

To counter-argue my own case, such multi-architecture layer MDA system may as well re-introduce the linkage between layers as there would be almost no scope for manual work within the layers!

I think XDoclet or some other technique could be used to support this approach, but the generation of multiple versions of the DTOs may be needed as the domain model changes, and business layers can request a deprecated one unchanged if appropriate.