I've been looking at several of the threads in this forum and it occurs to me that a lot of you opt for using transfer objects for passing the information from the server to the client. I work with a B & S assignment, and the delivered interface dictates a String-based communication. So it seems logical to me to let the server be unaware of any Contractor objects and just deliver String arrays. In this way it pretty much behaves like a JDBC implementation.
But have I missed something important? Why on earth are you so keen on using transfer objects? I know its a popular design pattern, but it shouldn't make you change the defined interface, should it? Please correct me here if I'm wrong, I just can't make any sense of it.
There is no need to change the defined interface when using tranfer objects. The Presentation-tier code is written to correctly process the transfer objects. The Business-tier code is written correctly to create and send the transfer objects. All of this occurs within a single application.
The process of "dumbing down" data and sending in array-based Strings is a non-object-oriented way of programming. This typically requires writing more code to parse the array and extract data and then validate. More code writing equals more time to produce application and more code to review in debugging process. This process creates brittle code. May work for small applications. Problematic for enterprise applications. [ December 08, 2008: Message edited by: James Clark ]
posted 11 years ago
Hi James, thanks for your reply.
Well, if there's a need for 'dumbing down' stuff, I agree with you. If you create a business object on the server, you should keep on using it. But the question was more about to what extent the different parts of the application really need to know what the data is all about. The software reading my harddisk has no idea whether I read a music file or a word file. Equally, it would make sense to me to write a class reading the data file without it knowing what the data was all about. And even more, I thought of the idea of letting the whole server be unaware of the meta data part of the application, just like a JDBC application. I mean, since the interface reqires String, and the JTable as well?
But I realise now that this would not be a good idea. My assignment says that there won't be much of a chance that the application will be used for new user interfaces, but of course this dosn't make it a good idea to scale my application for the current small-size, throw-away-after-use perspective. Thanks, James, you saved me some hours of programming there.
Hoo hoo hoo! Looks like we got a live one! Here, wave this tiny ad at it:
Devious Experiments for a Truly Passive Greenhouse!