What Im doing is quite similar to this. My business objects are basically just smart value objects , and when populated are passed to the (real) business tier in a single call. If there are problems an appropriate exception will be thrown. for example for things like: Username already in use etc...
In addition our fields are validated before then based on information about the field provided by the b-tier (which is a j2ee app). ie: which fields are editable, mandatory , resource key for the label etc... and also information about data types expected etc... and this 'front line' defense is done in tne action before anything is passed to the b-tier. (This field metainfo is also used when rendering fields for the view) -----Original Message----- From: Robert [mailto:rmcintosh@;bull-enterprises.com] Sent: Thursday, October 24, 2002 05:14 To: 'Struts Users Mailing List' Subject: RE: Validation Philosophy One thing that we do in our product is allow the business object to accumulate its errors and present them all at once instead of an exception on every 'set' method. Much the same way as an ActionForm does with it's validate() method. This allows you to present all the errors at once to the client, regardless of struts or swing. - Robert -----Original Message----- From: David Graham [mailto:dgraham1980@;hotmail.com] Sent: Wednesday, October 23, 2002 3:55 PM To: [EMAIL PROTECTED] Subject: Re: Validation Philosophy That does make sense. I forgot that distinction while under fire :-). So, your model objects will throw some application exception when invalid data is entered like UserNotFoundException? Thanks, David >From: Adam Sherman <[EMAIL PROTECTED]> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >To: Struts Users Mailing List <[EMAIL PROTECTED]> >Subject: Re: Validation Philosophy >Date: Wed, 23 Oct 2002 16:51:24 -0400 > >David Graham wrote: >>I just presented Struts to my team as a strategic solution and it went >>very well. I got beat up on the validation though and didn't have a good >>answer. I explained how the validator works with action forms and how all >>your input is validated before it gets to the business layer but that >>wasn't sufficient. >> >>A few people argued that they want the validation in the model objects so >>every app that uses the model must follow those rules. They said that >>having the validation before the model didn't make sense. > >There's been some comments about this somewhere, can't remember where >exactly... > >Basically, there are two types of validation: business validation & input >validation. > >Business validation is such things as "Invalid Order ID", can't create an >invoice for that order. Or, can't delete that user, he's owned by another >administrator. > >In put validation is "dumb", like syntax. You know, is that a phone number, >is that an email... > >For example, checking an email for valid syntax is one thing, and looking >up the domain to make sure it exists is another. > >Do I make any sense at all? > >Thanks, > >A. > > >-- >Adam Sherman >Software Developer >Teach and Travel Inc. >+1.613.241.3103 > > > >-- >To unsubscribe, e-mail: ><mailto:struts-user-unsubscribe@;jakarta.apache.org> >For additional commands, e-mail: ><mailto:struts-user-help@;jakarta.apache.org> _________________________________________________________________ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
