In my Data implementation was I just validated the data against the records schema when updating a file. To do this I dynamically create a schema object (inner class) to hold the record structure information. In my data class I ensure that a record
String[] passed to the create or update method contains the correct number of fields (the size of the array), that each field is the correct length and that each field contains only ascii data. There is no guarantees from the data class that a record contains sensible business information, it just ensures that the file is not allowed to become corrupted by invalid data.
A) The database schema in the form of field lengths and formats (e.g. yyyy/mm/dd for the date the room is available) is available from the database file. In my opinion, checking of the field lengths and formats needs to be done in the database layer (the suncertify.db.Data class, a subclass or delegates of same) because this checking is essential to ensure the data can be properly stored. I'm pretty sure that this is the way to do it.
I don't entirely agree with this statement, the actual format is not available from the file, all the Data class knows from the schema about the date field is that it is a 10 charachter length string. It does not know that the field should be in a date format, or even what a date format is. I would consider this to be an application level detail not a data level detail. What if the date field was moved to another slot in the record in the future? Would you want to have to alter the Data class to cope with this scenario.
I think that you are right to put such application level validation in your DBImpl class, so that if any changes are made to the schema the can be more easily updated here. Also you can easily support other types of data files very easily by simply creating other data file specific wrapper classes and reusing your Generic Data class (Not a requirement or course but nice to have
).
Regards,
Mark
[ February 06, 2007: Message edited by: Mark Smyth ]