Generic Data Validation Questions.

[john_anderson_ii]

As far as following convention goes, which of the following scenarios are considered better form?

Scenario 1: You have a CMP EJB persisting a String type field called "Description". You want to limit the amount of characters in this field to <=100. You set the datatype in the RDBMS to VARCHAR 100, and write code in the bean and client to display an error when the bean throws a SQLException becaue the client used >100 characters when attempting to persist field "description".

Scenario 2: You have a CMP EJB persisting a String type field called "Description". You want to limit the amount of characters in this field to <=100. You allow the container to set whatever datatype it's mapping tells it to set for java.lang.String. You then add code to the CMP EJB's Facade type bean to check and make sure that any strings passed to setDescription() are <= 100, otherwise an error is thrown or displayed.

Scenario 3: A combination of 1 & 2.

I'm sure there is no end-all-be-all answer to this question, but any general advice on data validation would be appreciated, or maybe a comparative blurb on the pros and cons of Scenarios 1 & 2.

I also had a quick question on findByPrimaryKey(). Which class owns this method in javax.ejb? I've looked all through the API documentation from javax.ejb.EntityBean all the way up the tree. Then I read some crazy stuff about this method really being implemented by the container, and not by any inheritance. Weird.

I'm just trying to find out what findByPrimaryKey() does when it does not find the row for which it's looking. Does it return null, or does it throw an exception?

Thank you for your time and patience.

[benstarr]

I believe you should always check the validity of data in the entity bean itself and not rely on any other part of the application to do that. Obviously for user-friendlyness and performance you may also want to check values in the user interface as well. Typically you would do simple checks (data type, format, length, range etc) in the user interface and more complex checks in the middle-tier (not to say that the simple checks shouldn't be performed in the middle-tier as well).

I'm not sure how to find the implementation of the findByPrimaryKey method. However, section 10.5.8.4 of the EJB 2.0 Specification states that an ObjectNotFoundException will be thrown by finder methods if the underlying object does not exist. ObjectNotFoundException is a subclass of FinderException.

[john_anderson_ii]

Thanks, that helped a lot! Currently I've only been validating data on U/I side. But now that I see your point it makes much more sense to validate the data on the middle tier. Especially if I re-use the code someday.