URLyBird: Data validation - where to do it? (OCMJD forum at Coderanch) (2024)

Alex Duran

I have a question regarging where I ought to be doing data validation. I'm not concerned about the mechanics of how to do this - I think that the java.text and java.util.regex packages will have all of what I need for the checking operations themselves.

I'm more concerned about where the checks should be performed. I have a couple thoughts:

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.

B) The 48 hour threshold for reserving a room is a buisnes rule. It is independent of the data storage mechanism and, as a result, this sort of check should not be in the database layer. My first guess is that I could create a subclass of AbstractTableModel and registered listeners could call some sort of business object to perform this type of valdiation - when the appropriate event is fired. Does that seem correct or can people suggest a better way?

C) I can't help but think that some form of field format and length validation should be performed before an attempt is made to update the database. Do people have ideas on what is appropriate here?

The implementation of C seems the most difficult. The Data class can easily query the database file at startup for its schema. But if I'm going to validate field format and length, there needs to be some way of publishing this information where it can be used outside the database layer. I would expect this needs to account for the possibility that the order of data fields could change, the names of the fields could change, field lengths and formats could change, etc.

Any thoughts here, too?

ThanksQ!

Mihai Radulescu

I like...

Hi Alex

on A) nearly right, the Data class is a dao it hides the physical access and make to transparent for the user, that why you don't need to care about the validation here otherwise you may lose the "transparent".
on B) this depend on your architecture but as you said

...is a buisnes rule...

so it must be on the layer(side) which provide this.
on C) the same like A.

Regards M.

Timothy Frey

I have a similar question that I thought I'd post here instead of create it's own separate topic.

I'm trying to separate validation from the layer that actually does the legwork. Here's what I have now:

DB (interface provided by Sun)

DBImpl -> RecordManager

I want the DBImpl class to validate the input for a required method. If the input is not valid, throw the proper Exception. If it is valid, delegate the real work to the RecordManager layer. For example, this is the read method supplied by the DB interface:

This is the DBImpl code for this method:

Simple enough, right? However, in my Record Manager class, who is to say that the input has already been validated? The code above ensures that the record will exist when the read() method is called, but what happens if some other programmer (or maybe even an older me) comes along, reuses the Record Manager class but does not do the validation?
[ February 05, 2007: Message edited by: Timothy Frey ]

Mark Smyth

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 ]

I like...

Timothy, it idea is not bad(to have a separate validation mechanisms) but I don't know if is so good to throw a RecordNotFoundException if a record has a wrong format (I mame this presumption after I read your code snippet).

Regards M.

Lucy Hummel

Originally posted by Mihai Radulescu:
Timothy, it idea is not bad(to have a separate validation mechanisms) but I don't know if is so good to throw a RecordNotFoundException if a record has a wrong format (I mame this presumption after I read your code snippet).

Regards M.

Hi,

I agree with Mihai that it is not a good idea to throw a in case the input data in invalid.

From the client point of view it is more helpful to throw a more specific exception. I mean an exception that says, that the input data is invalid/wrong, like . So the client can better understand why (s)he does not get anything back.