This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The design decision I have been pondering on, and would like to hear your opinions on is reading the schema of the data file.
Unfortunately the schema does not describe whether different data-types are currency, strings, numbers etc. It can be deduced by using common sense by the programmer obviously. But if I add things like search for more than, or less than this number of employees or this cost etc, I am hardcoding that data-type... That means that if there is a schema update server side, ALL clients have to be re-coded... Yiuk!
... How did you guys justify this decision and what did you decide=?
I've used a two-tiered approach, first validating whether the datafile is well-formed, then validating whether the record contents are as expected. The second layer relies on object inheritence to establish a "plugin" structure, keeping the datafile reader completely generic.
SCJP 1.4, SCJD 1.4, SCWCD 1.3, ICSD:Websphere 5.1
Joined: Dec 10, 2004
Perhaps I didn't ask the question with enough accuracy...
Validating the data according to the schema I have no issues with.
It is how I display the GUI to reflect the schema dynamically I believe is difficult. Either I hardcode the GUI, in which case my problem of how to display different search option for different kinds of data types etc is solved... But will result in a client "re-code" if there is a schema update. This is not desirable.
Or I generate the GUI completely dynamically.... In which case it I can't assume that the data-type "no of employees" is a number and "rate" is a currency and therefoer also a number etc... Making searching more difficult.
My personal choice was to use a ValueObject to represent a record from the database. The fields within the ValueObject could then be referenced as the original field type (String) or as my interpreted field type. My reasoning was that if the field type definition changed at the database level, I would only need to change how to construct my ValueObject using that new field type - the classes which used the value object would still use the same getters.
I constructed my ValueObjects in the model of my MVC, mainly because of my belief that the instructions require the business logic to be client side (I can point you to a huge discussion on that if you are interested). Similar logic to why I am used a ValueObject in the first place: if the method of connecting to the database / getting the raw data changed, I would only need to change the model of the MVC (which is one of the common reasons for using an MVC).
I have seen other candidates returning ValueObjects from business methods in their servers. If you are already doing conversions from String to some other data format within the ValueObject constructor, then if the database field format changes, you only need to change the constructor to handle the new field format.