iTrust Design Notes

Here are some archetype classes that the system uses. In adding new code, please keep using the appropriate responsibilities for each class type.

Each JSP uses exactly one Action class. These classes are the ones that integrate all of the other classes together to form the feature. For example, the Action class will take in parameters, validate the information, perform some “business logic” if needed, then pass the information over to the DAO for database interaction. Methods in Action classes can get pretty complex if you're not careful. Rule of thumb: if your method takes up more than a single screen, start splitting your method up into smaller methods. Plenty of Action classes delegate the logic to a separate set of classes (e.g. ChronicDiseaseMediator).

These are abstractions to provide some ease in making new actions. Use a base action when a page requires an ID of some sort to work. For example, “Edit Patient” would have to have a Patient ID in order to make sense. If you use a PatientBaseAction, then its constructor will verify the MID string and throw an exception if it doesn't check out (thus kicking you back to your homepage with an error message).

A bean's purpose is to store data. Period. Little or no functionality is to be added to a bean (with the exception of minor formatting such as concatenating phone numbers together). A bean must only have Getters and Setters (Eclipse Hint: Use Source > Generate Getters and Setters… to create these easily)

A form is a bean, kinda. You could say that it's a “form” of a bean :) Think of a form as a real-life administrative form that you would fill out to get something done, not necessarily making sense by itself. For example, a Patient is a Bean, but the info used to request an Epidemic Detection is a Form.

Loads in information to/from beans using ResultSets and PreparedStatements. Use the superclass to enforce consistency.

Checks a given bean for valid input. This is a must for input from the user! Note that Validators are designed around giving the user all of the errors in their form at once. For example, if the First Name AND the Last Name of a patient are wrong - the validator should report both problems, not just the first error and then stop.

Database Access Object. All info coming into a DAO is already validated. Just worry about DB stuff here. As a result, DAO methods should rarely have if-statements or perform any complex functionality other than storing to and retreiving from the database. If you think a DAO method requires a lot of complexity, consider the alternatives :

• Asking your TA student if it can be done in SQL, or
• Putting the logic in an Action class or a separate delegate class (this usually means splitting your DAO method into separate methods - it's good to keep them small and simple!)

Also, note the following conventions:

• Usually every table has one DAO (e.g. PatientDAO). We also add new DAOs for logical groupings of complex queries on tables (e.g. FamilyDAO). Don't create new DAOs for everything you do. Use what's there and add to it.
• All SQLExceptions are caught and re-thrown as DBExceptions - this is to hide valuable DB information from the user, which is a security risk. Please follow this convention. And don't ignore SQLExceptions as they still need handling once they are caught.
• All DAOs need to have a DAOFactory with which to access other DAOs and to get connections. If you create a new DAO, please add it to DAOFactory using the design that's already in place (e.g. every DAO must have a constructor with a DAOFactory as a parameter)
• Use the built-in utility to close connections gracefully.

Also, see the how do i page for more valuable information on DAOs and database conventions.