You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Guido García Bernardo <gg...@itdeusto.com> on 2003/12/22 16:00:22 UTC
[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@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Validations - 'format' vs 'business'
Posted by Martin Gainty <mg...@hotmail.com>.
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" <gg...@itdeusto.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
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@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Validations - 'format' vs 'business'
Posted by Vic Cekvenich <ce...@basebeans.com>.
Guido García Bernardo wrote:
> I really think that is a good aproach. At least one of the most simple
> and centralized.
Thanks, I take a lot of time to try to KISS.
> ...from a "pure struts" point of view someone can think that your
> solution is mixing the model with the view.
> I think ActionForm should remains as part of the view, or just a 'box'
> between the view and the controller.
> What do you think?
This is what I do as well when bus. rules are complex, so it's applied
as well, not just theory, by just ovreding the Sturts API validate().
I call the supper vlidate and capture the messages, and then to it I
append my custom messages as follows:
Then I can create a new MyBusRuleHelperClassForMyXYZFormBean:
MyBusRuleHelperClassForMyXYZFormBean rulz = new
MyBusRuleHelperClassForMyXYZFormBean()
messages rulz= rulz.check(this.getCollection()); // or what ever you
want to send in as data of the bean to the bus rule validator.
return messages;
So the action calls validate() on formbean and get messages to put in scope.
But...formBean validate() delegates the work outside of the formbean, in
the bus. rules clayer. That object often creates its own DAOs.
This also makes it very easy to unit test bus. rules outside of the
container.
>
> On the other hand, I _must_ expose business logic as a API for other
> projects. With this fact in mind, business methods should be
> implemented doing validations again (defensive programming, you need to
> think about possible errors from your users and don't assume
> anything...). HOW without duplicated code?
So your MyBASERuleHelperClass may be an interface or have an abstract
base. It should not import any Servlet or Struts jars.
If you want to go nuts, you can even use a rule engine in the bus. rules
layer .... as long as it's fast.
Since my bus rules relie on a fast self caching dao... I have no issues,
but I test w/ OpenSTA anyway.
.V
>
> Thank you again,
> Guido García Bernardo
>
> Vic Cekvenich wrote:
>
>> {repost}
>> I just override validate() method on formbean and do all there,
>> including super.validate() that reads validation.xml. In here I call
>> DAO's to do business validation also, ex: what is the available credit
>> for the client to place this order.
>>
>> Then in action I do this:
>> errors = formbean.validate();
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Validations - 'format' vs 'business'
Posted by Guido García Bernardo <gg...@itdeusto.com>.
I really think that is a good aproach. At least one of the most simple
and centralized. BUT....
...from a "pure struts" point of view someone can think that your
solution is mixing the model with the view.
I think ActionForm should remains as part of the view, or just a 'box'
between the view and the controller.
What do you think?
On the other hand, I _must_ expose business logic as a API for other
projects. With this fact in mind, business methods should be
implemented doing validations again (defensive programming, you need to
think about possible errors from your users and don't assume
anything...). HOW without duplicated code?
Thank you again,
Guido García Bernardo
Vic Cekvenich wrote:
> {repost}
> I just override validate() method on formbean and do all there,
> including super.validate() that reads validation.xml. In here I call
> DAO's to do business validation also, ex: what is the available credit
> for the client to place this order.
>
> Then in action I do this:
> errors = formbean.validate();
>
> hth,
> .V
>
> Guido García Bernardo wrote:
>
>> 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@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Validations - 'format' vs 'business'
Posted by Vic Cekvenich <ce...@basebeans.com>.
{repost}
I just override validate() method on formbean and do all there,
including super.validate() that reads validation.xml. In here I call
DAO's to do business validation also, ex: what is the available credit
for the client to place this order.
Then in action I do this:
errors = formbean.validate();
hth,
.V
Guido García Bernardo wrote:
> 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@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org