OpenSessionInView vs DTO/VO vs ?

[karldmoore]

I read this thread (http://forum.springframework.org/showthread.php?t=19429) with great intrest, but the OpenSessionInView vs DTO/VO debate continues.

I understand both arguments, but given a blank sheet of paper what would people go with?

I like the idea of OpenSessionInView in some ways, but putting JDBC code in a JSP would be considered bad practice, so why isn't transparant persistance as provided by OpenSessionInView with Hibernate lazy loaded collections? Clients calling methods on my business method isn't ideal, so should i just lower the scope (default, protected) to try and prevent someone calling them? What other problems do we face here?

DTO/VO also seems viable, but when I start writing the same code again and again, I really start to wonder. I do like the fact people only have access to the methods I provide them and that I can change the Business Model independantly. But again what other problems do we have.

When writing a web application from scratch (Struts, SpringMVC) which would be the better approach? What about a thick client (Swing)?

The last company I was at used DTOs and had Struts and Swing clients. It worked but was it right? There must be some kind of middle ground that can be struck. I think the question is, "is there a better way?".

[karldmoore]

BTW, if anyone has anything to add to this debate apart from just a vote that would be greatly appreciated.

I'm basically after peoples experiences, problems and solutions to this common issue.

Thanks

Karl

[benethridge]

...but putting JDBC code in a JSP would be considered bad practice...

DTO/VO also seems viable, but when I start writing the same code again and again, I really start to wonder.

At the risk of being labeled a heretic, I cannot say that putting JDBC code in a JSP is ALWAYS a bad practice. It depends on whether (a) the code will be repeated elsewhere and/or (b) whether a reasonable chance exists that the code "layer" will be replaced someday. If there is no reasonable chance, then there is probably no need for the extra layer.

In prototyping projects initially, the data contents and naming is often constantly changing. It never ceases to amaze me how many project designers define layer after layer in the INITIAL prototype, kowtowing to the "layering is good" mantra, only to have the project blow apart (deadline and cost-wise) when the UI designers and database designers can't get together on the supposedly "simple" names and structures, and force the poor developer to keep changing, say, the Person and Address getter/setter logic in ALL 5 of the layers!

If Matt Zanni was not the person who coined the phrase, he's the first developer I heard use it, and it describes the problem perfectly. He called it "meat-grinding": Changing the names and structures of DTO-like objects as they move through the various layers, to conform to that particular layer's DTO-syntax. (I speak of DTO's conceptually, i.e. not just as java objects, i.e. DTO-like structures existed back in the COBOL days).

"Meat-grinding" projects are boring, but do generate a lot of income for the developers and designers, again, every time the UI designers (in the front-end) and database designers (in the back-end) miscommunicate.

A better approach would be to INITIALLY marry the gui to the database, as close as possible with no "layers" in between. Then, when the naming and structuring has settled down, decide what layers are reasonably needed...i.e. what technology component or framework stands a reasonable chance of being swapped out before the useful life of the product ends...and ONLY THEN refactor the code into the layers.

Ben

[benethridge]

To clarify: Why did Matt calll this DTO-churning "meat-grinding"? Because, when it finally made it all the way to the end-layer, it was essentially the same old "meat".

As is probably common with DTO's, there is no real value added to the meat as it is ground and re-ground through the layers.

Ben

[Colin Yates]

At the risk of being labeled a heretic, I cannot say that putting JDBC code in a JSP is ALWAYS a bad practice. It depends on whether (a) the code will be repeated elsewhere and/or (b) whether a reasonable chance exists that the code "layer" will be replaced someday. If there is no reasonable chance, then there is probably no need for the extra layer.

I have to question this practice I would highly recommend not doing this because how would you test the JDBC code? I think JSPs are complicated enough without putting in a whole load of Java.

Even if you only have JSPs and JDBC code, still, please use the DAO pattern, so the JSPs directly call the DAO, it makes the JSPs easier, allows the testing to occur and doesn't add any overhead.

In prototyping projects initially, the data contents and naming is often constantly changing. It never ceases to amaze me how many project designers define layer after layer in the INITIAL prototype, kowtowing to the "layering is good" mantra, only to have the project blow apart (deadline and cost-wise) when the UI designers and database designers can't get together on the supposedly "simple" names and structures, and force the poor developer to keep changing, say, the Person and Address getter/setter logic in ALL 5 of the layers!

Not sure what you mean here. Layering is good if it buys you something, namely seperation of concerns. Layering doesn't mean that you need to have seperate domain representations within each layer. In my apps, I typically have a View layer, a service layer which co-ordinates the domain model and represent a use case, a DAO layer and a domain model containing the business logic (i.e. Address, Person etc.). My domain model however spans all the layers, there is no translation of the Person between the layers.

I do however get the point about over-engineering an application.

I would like to know where you work where they actually do allow "prototypes". Every prototype I have ever written ends up as the basis of the production code

I think there is a difference though about using logical layers, and multiple representations of the same object model. DTOs are only useful if you have physically seperate layers, and they are only useful to reduce network traffic. If you don't have that problem (i.e. co-located apps) then don't use them

You can also use DTOs to provide different views of the same data, but that (I think) is a misuse.

[benethridge]

I have to question this practice I would highly recommend not doing this because how would you test the JDBC code?.

?? Put a breakpoint at the line in the jsp and debug it. This is pretty straightforward in Eclipse, at least (maybe not other IDEs?).

I think JSPs are complicated enough without putting in a whole load of Java.

I don't necessarily agree. <%...%> pretty cleanly separates the java from the HTML. The jsp just looks noisy, when you look at the whole .jsp file. The java has to live SOMEWHERE, and a case can be made that it should live as in-line code in the jsp. (Again, this is probably heresy, these days.)

Even if you only have JSPs and JDBC code, still, please use the DAO pattern, so the JSPs directly call the DAO, it makes the JSPs easier, allows the testing to occur and doesn't add any overhead.

I would agree with this statement, except that I would say that it doesn't add "much overhead". By that I mean, it's a layer (the overhead), but almost always is a useful one, and only adds one potential meat-grind.

Not sure what you mean here. Layering is good if it buys you something, namely seperation of concerns.

There are many ways to separate concerns. Not all of them necessarily involve layering. Take, for example, OracleForms (old) or Sun's Studio Creator (new). Both of them, as I remember, allow you to design and write lots of functionality without having to think about layering. Just the presentation logic and the database logic married closely together...for better or for worse. :-)

In general, as I've said in other forum threads, you need to separate the things that change from the things that don't. This appears to me to be ancient and fundamental law of programming. It covers databases and languages, and over the years I've seen a number of projects bust by violating it. I'm just saying that people need to think hard about what all their layers REALLY buy them in the end...and what it cost them in the meantime.

Layering doesn't mean that you need to have seperate domain representations within each layer.

I agree, but designer/developers tend to end up doing it so often that I sometimes wonder if the current patterns aren't forcing them into it....which is why I'd really like to see some "framework pattern templates" or "architectural blueprints" or what ever you want to call them. (See other thread: http://forum.springframework.org/showthread.php?t=29694)

In my apps, I typically have a View layer, a service layer which co-ordinates the domain model and represent a use case, a DAO layer and a domain model containing the business logic (i.e. Address, Person etc.). My domain model however spans all the layers, there is no translation of the Person between the layers.

Sounds good, and sounds like exactly the kind of thing that the world needs to be "Spring-framework pattern templated". I assume you're using the Spring framework with it.:-)) Perhaps stating it as a pattern template or architectural blueprint would eliminate a lot of these long-winded architectural debates....seriously.

I do however get the point about over-engineering an application.

Thanks. That's really the main point I wanted to get across.

I would like to know where you work where they actually do allow "prototypes". Every prototype I have ever written ends up as the basis of the production code

I'm not at liberty to say. It is sad, though, isn't it, that mocking and prototyping and re-factoring, so common in other industries is not yet an accepted practice in software development. Businesses always seem to run out of money and time after the initial "rough prototype" appears to "work". I imagine this is because in other industries (airlines, toys, etc.), the rough prototypes can be visually seen by upper management. In software, the "product" is all abstract, and buried in the code.

I think there is a difference though about using logical layers, and multiple representations of the same object model. DTOs are only useful if you have physically seperate layers, and they are only useful to reduce network traffic. If you don't have that problem (i.e. co-located apps) then don't use them

You can also use DTOs to provide different views of the same data, but that (I think) is a misuse.

Perhaps, but I see XML, when used as a means of data transport (as opposed to using it for config files), as just another form of DTO...and yet another potential meat-grind point. :-)

Ben

[Colin Yates]

?? Put a breakpoint at the line in the jsp and debug it. This is pretty straightforward in Eclipse, at least (maybe not other IDEs?).

I am sure you will agree Ben, that this is less then ideal, what about automated tests, regression tests etc.?

Debugging, I think, is usually misused. Now, *that* is heretical

I think if you are debugging your code to see how it works and to make sure it does work then that is symptomatic of poorly written code and the lack of an sensible test environment.

I agreed with most of your other points, but this, I just had to take exception to

[Costin Leau]

To chime in, my answer would be it depends. I've used both approaches in the same project since both have some weaknesses and strengths.
I used to rely on OSIV in order to have a session opened across the method call - however with Spring this is not an issue anymore.
I prefer working directly with the object model (i.e no DTO per-se) and not OSIV since I've run into some big performance problems with OSIV. However, I do not dismiss the idea - there are cases when dynamic page generation is required where having an OSIV can easily solve the problem.
The trick, though, is not to abuse it - i.e. try to be preventive and load relationships (if there are any) in one call.

[benethridge]

I am sure you will agree Ben, that this is less then ideal, what about automated tests, regression tests etc.?

Yes, I agree. Good point. Basically, I'm just saying don't use a layer without a good reason, coz there's a price to be paid for each layer. You bring up a good reason.

Debugging, I think, is usually misused. Now, *that* is heretical

Interesting. I like hearing the "heretical" views of designer/developers who have been around the block a few times. It show that they are thinking out of the box. Since we all spend so much time debugging (or is it just me? )...can you expand on this, please, perhaps in a new thread?

Ben

[Dave Syer]

I'm voting for OSIV, but only on pragmatic grounds. Most of the time it is the first tool I would reach for, but there are times when I will be driven to a DTO. I think Bosmon has summarised well the way that the available technologies drive us to these decisions, ultimately to compromise in an imperfect world.

I also think that maybe it is not just Hibernate that needs to be gutted. The semantics of the "declarative demarcation boundaries" would need to be available on both sides of the boundary - the view technology integrated as well as the persistence technology. The view has to know what properties are available for rendering, and ideally a small change to the view, e.g. to expose a new property, would be impossible without declaring that as a valid operation in a way that is immediately transparent to the persistence/transfer layer.