Business Logic Layer <-> Presentation Layer (DTO?)

Howdy Ranchers!

I was thinking: how did you sent the data from business layer to the presentation layer?
The one way I could think of is to use so obvious Data Transfer Objects. It's nice to have a strongly typed access to underlying data (instead of Object or general String instances). But wasn't the DTO (VO) invented in old J2EE times, to prevent the network traffic; to allow the user to fetch whole object without fetching separated fields in different network requests?

So, it is basically no difference when sending String[] object and RoomDTO object - this is still only one request/response.

But if I decide to stay with the DTO (despite the doubted minimize-network-traffic argument) in order to provide GUI with some meaningful data access (getLocation(), getPrice() instead of String[5] and String[2]), where should I put information about "validators"? I mean not the full-feature validation like JEE6 Bean Validation thing, but just the information about - let's say - maximum size of the field. Then again - isn't this "validation" rules (extra data) changing the DTO pattern into... something else?
I think it would be nice to set grid options based on values fetched from the data instead of putting those hard-coded into the GUI layer.

How did you solve this problem? Or maybe you didn't care about this?

Cheers!

I used simple transfer objects.

To limit my gui (length of a field) I used hard-coded values and I documented and explained this decision in my choices.txt

Pedro Kowalski wrote:Howdy Ranchers!

I was thinking: how did you sent the data from business layer to the presentation layer?
The one way I could think of is to use so obvious Data Transfer Objects. It's nice to have a strongly typed access to underlying data (instead of Object or general String instances).

I created a single domain object representing the kind of thing in play (namely, a Subcontractor), and then provided a business method that returns a typed list. The GUI invokes a controller which calls the method in the business layer. It seemed to me that the GUI ought to be able to ask for, receive, and use strongly typed collections.

Thanks Guys, so I guess I'll call for the DTO.

David - and what about you - did you fetch the maximum width of the field from the schema?

Pedro Kowalski wrote:Thanks Guys, so I guess I'll call for the DTO.

David - and what about you - did you fetch the maximum width of the field from the schema?

I fetched the full field and then trimmed when extracting data from the file, and I padded to max when writing to the file.

I handled validation by passing each incoming object or outgoing collection through a static conversion method in a utility class. Each conversion method (object to array or array to object) throws a validation exception. There's also a simple validation method in my Data class.

Yea David, I'm doing the exact same thing when operating on the BLL <-> DB layers, but what about BLL <-> GUI?

Do you send somehow the maximum field length (read from the file schema) to display the value in the grid (JTable) or do you set the field widths in GUI hard-coded, despite the schema?

Pedro Kowalski wrote:Do you send somehow the maximum field length (read from the file schema) to display the value in the grid (JTable) or do you set the field widths in GUI hard-coded, despite the schema?

No. My GUI has no business knowing anything about the underlying data source; it should answer only to actual data delivered by an appropriate scutworker. So I eyeballed some widths appropriate for my longest known data value in each column, tweaked the numbers, and then hard coded them as preferred widths.

Ok, thank you guys - I think then I'll omit sending maximum length of fields in the DTO's (or whatever it would be named) :-)