Return codes are ignored by lazy programmers
Throwing your customised Exception is much more visible a way to handle the
situation
Regards,
Martin
----- Original Message -----
From: "Guido Garc�a Bernardo" <ggarciab@(protected)>
To: "Struts Users Mailing List" <struts-user@(protected)>
Sent: Monday, December 22, 2003 10:00 AM
Subject: [OT] Validations - 'format' vs 'business'


> Hi,
> I have a design doubt... I must validate data coming from a form. This
> consist typically of:
>   - 'format' validations (i.e. a field is not empty or it is numeric)
> that I do in the validate method of the ActionForm
>   - 'business' validations that usually require a DB access
>
> I actually do 2 steps (actions) per operation. One of them prepare the
> data and the second one does the operation itself. And here comes my
> first question: ��is there any other better aproach?? Maybe something
> similar to a Tiles Controller to prepare the data...
>
>   class PreOperationAction extends Action {
>      public ... execute ( ... ) {
>        // Create JavaBeans to populate html selects and several
> inputs (requires DB access) and include them in the request
>        // Forward to error/success jsp
>      }
>   }
>
>   class PostOperationAction extends Action {
>      public ... execute ( ... ) {
>        // Get data from ActionForm
>        // Business validations (the selected values and inputs are
> valid from the business point of view)
>        // Execute business logic (encapsulated in external business
> logic classes)
>        // Forward to error/success jsp
>      }
>   }
>
> At this point I don't know what is better (from a MVC perspective).
>   1. Do it as actually, that is, doing business validation before
> business logic. This way I think I can't expose the business logic as an
> API or as a web service.
>   2. Include all the validations (business and format) into the
> business logic classes. This way I must duplicate format validations
>   3. Doing a OperationValidations class (? only a vague idea)
>   4. Is there any pattern or any best practice related? Does
> Validator Plugin allow complex business validations?
>
> Finally, I need your opinion about handling validation errors:
>   1. Throwing an Exception from the business logic classes and catch
> it in the Action (or declare the exception in struts-config.xml)
>   2. Returning null (or -1, or a no-sense value) from the business
> logic classes
>   3. Any other way...
>
> Thank you very much,
> Guido Garc�a Bernardo.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@(protected)
> For additional commands, e-mail: struts-user-help@(protected)
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@(protected)
For additional commands, e-mail: struts-user-help@(protected)