I've just started the design for the URLyBird 1.2.1 SCJD Assignment and wanted to get your opinion on reading the data from the data file. I started by designing a Value Object (Room) that contained all of the relevant database fields and appropriate getters and setters (like the Dennys DVD example in Andrews book). However, I then noticed that the data schema was included at the start of the data file, and that the requirements state that the design should be flexible and allow for future improvements. Therefore, I thought about making the value object more generic, perhaps returning a Map of data column names and associated size, but this means I'll have to alter my class that reads in the data from the datafile, and I'm also thinking this will make my GUI code that allows a user to search for rooms MUCH more complicated
Obviously if I use the Value Object design and the schema were to change in the future - I'm stuffed, but creating a more flexible way of reading and passing the data object around will result in more complex code? I've done a search through the archive and there seems to be no clear decision on which design is best (or most suitable for the exam). Can anyone offer me any advice?
The server can be made generic enough that it knows nothing about what it's serving. It just returns an array of Strings to whatever calls it and leaves it up to that program to decide what to do with it. I've made one small sidestep from that and have implementation classes for the actual datatype stored in the database on top of those generic classes which handle things like validation services on data as it's read and before it's written, thus reducing the risk of data corruption on both client and serverside of the system.
The arrays of Strings are then piped to the client which has a client specific bean class to make for nicer typesafe storage and handling on the client itself. As the client already has to know about the actual data anyway, that's IMO perfectly fine, but the server is at hart ignorant over what is serving.
posted 14 years ago
Many thanks for your comments - I had completely overlooked the fact that the server could be ignorant to what it served (the String return on the interface methods should have given this one away!). Your implementation classes for the actual datatype also sounds like a very good idea.
I have the same stuff, my server just sevrv some Strings, this Strings are warpped in Records on the client side.
Jeroen, what you mean by :
I've made one small sidestep from that and have implementation classes for the actual datatype stored in the database on top of those generic classes which handle things like validation services on data as it's read and before it's written, thus reducing the risk of data corruption on both client and serverside of the system.
Do you mean that you use this Record warppers(Value Object) on the client and server side to validate the service ? If the asnswe is yes how you ho this check - you just check if the Record atributes follow a specific pattern - like date format ?