Usage of a DTO in common J2EE environment is a POJO or a Java bean; The difference is only a matter of purist view in my opinion. Its like when i use DTO to represent say an Order and call it OrderDTO and then use the same entity for persistence; the TO’s purpose becomes polluted. A TO should do only what its supposed to do; beyond transfer the tier has to take over. In my opinion actual DB entities should be represented as Models in Java / J2EE environment and then passed around through tiers using a DTO (which would mimic the data of Model or state of the Model or could in fact contain the model itself.)

This in my opinion leads to better Separation of concerns.

Regards
Vyas, Anirudh

The idea of DTO vs Value Object being different is fairly common in J2EE community as per my understanding.

You’re not by chance using Lucene for the search and Wicket for the presentation?

I’ve been trying (rather unsucesfully) to integrate Wicket and a search data tier via IDataProvider, but have found that they are not compatible.

The current Wicket paging mechanism expects queries for data and total results (count query) to be executed separately.
Fine if using a DAO and a database.
But of course a Lucene search is executed once to locate both results and totals for the paging.

If you’re interested, have a look at the Apache Jira ticket I created:
https://issues.apache.org/jira/browse/WICKET-1784

Don’t think Igor (lead Wicket developer) is convinced that the use of a DTO object for passing search and paging parameters and returning results between Wicket to the data service tier is widely used.

Was wondering if you have a view on this?

Many thanks.

Could you elaborate more on your definition of a DTO mark and delve a little deeper on DTO vs a Search Object Mark?

Regards
Vyas, Anirudh

Regards
Vyas, Anirudh

An interesting article.
What do you think of a DTO situation like this:

1. A web tier (on one server) constructs a Search object containing a number of search parameters, some of which may or may not be set, depending on search complexity.
2. It calls a data service tier session (on another server) passing the Search object.
3. Data service performs search, adds search results and total results (for paging options), then returns this Search object back to the web tier.

I would say the DTO pattern makes sense here because all the related details are grouped, and the session interface signature is nice and simple as there’s no need to overload with all the various possibilities for the different search parameters.

You can find the slides here:

http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/

What I mean by “self-documenting” is that I can modularize a page into panels, give those panels names oriented towards the business logic, and describe my page in those simple, hierarichical terms — just as I can modularize a batch program as a hierarchy of well-named subroutines. This is much more readable than a HUGE tree of deeply nested tags.

If I am using similar panels in many places, I can write a single panel class to cover all the cases, with the differences in each usage configured via the constructor parameters of my panel subclass. Or, I can design my panel subclass with default or abstract methods to be overriden by (possibly anonymous) subclasses. Or I can combine both techniques. This gives me the same abstraction and re-use capabilities for the presentation logic that I already enjoy when coding the business logic.

If I want aspects of my application to have declarative configuration, I can simply include a configuration textfile in my application and write my code to read, parse, and use the information contained therein (without relying on the framework creator to guess the aspects I want to be declaratively configured).

Once you get the Wicket way of doing things, it’s as flexible and powerful as Java itself.