No, I wouldn't throw an exception for a validation error. That wasn't the point I was making.
The point I was making was that it reminded me of days in which error handling was done by returning error codes. It was cumbersome, and fragile to handle. The better way to handle major errors is through exceptions, which is what they were built for, rather than having to remember error code 19223.2, you can catch a meaningful exception. In this sort of instance, if something goes horribly wrong, yes, I would throw an exception - that is what it is there fore. I feel like returning a result object for something like that goes against common development practices, and returns us to error codes. For validation type erroring, I have no issue with some sort of validation error collection, be it an object or a struct being coupled to the BO's validation, and the view, I feel funny about that coupling being extended to the service as well. I would ask the BO if it is valid in the controller, because if it is valid, is part of the controller logic. If it is valid, it will probably go to one view, and if it isn't, it would go to another. I feel like this shouldn't be moved to the service to handle. Brian, you have talked about having 'dumb' service objects. Isn't moving this validation logic into your service a move away from that? Mark On Thu, Jul 17, 2008 at 5:40 PM, Alan Livie <[EMAIL PROTECTED]> wrote: > > Mark, I have my validation in BO's too. Say in your User BO in validate() > method you find username is less than 6 chars (which it shouldn't be as a > business rule dictates). > > Are you saying you'll throw an exception rather than return the info in some > sort of error struct / object so your form can handle it? > > Alan > ________________________________________ > From: [email protected] [EMAIL PROTECTED] On Behalf Of Mark Mandel > [EMAIL PROTECTED] > Sent: 17 July 2008 05:22 > To: [email protected] > Subject: [CFCDEV] Re: Service Layer X OO Architecture > > Honestly, the result object approach feels a little funny to me... but > I do see where the reasoning comes from. > > Maybe because it reminds me too much of returning error codes (1234), > rather than throwing exceptions. > > And maybe because it couples your entire model to this result object. > > I don't have validation coming from my service save() methods, I have > it coming from my BO's. I don't think that its the Service's > responsibility to handle validation. Maybe that's just me tho. > > Mark > > On Thu, Jul 17, 2008 at 1:32 PM, Alan Livie > <[EMAIL PROTECTED]> wrote: >> >> Thanks for this Brian. >> >> I'm just returning an array of structs with properties that map to form >> fields, message, error type etc. Makes a lot of sense to wrap this in a nice >> Result object. >> >> I'm just about to refactor the bean validation code so this was a timely >> discussion :-) >> >> >> Alan >> >> ________________________________________ >> From: [email protected] [EMAIL PROTECTED] On Behalf Of Brian Kotek >> [EMAIL PROTECTED] >> Sent: 16 July 2008 21:32 >> To: [email protected] >> Subject: [CFCDEV] Re: Service Layer X OO Architecture >> >> Yep that's pretty much it....things like isSuccess(), setSuccess(), >> hasErrors(), getErrors(), etc. >> >> On Wed, Jul 16, 2008 at 4:17 PM, Baz <[EMAIL PROTECTED]<mailto:[EMAIL >> PROTECTED]>> wrote: >> I think Brian's result object is a generic one that can be re-used with any >> change operation. Something along the lines of: >> >> * Status (i.e. Success/Fail) >> * StatusCode (i.e. User.Validation.Error) >> * Message (i.e. There were some validation errors in the user object) >> * Payload (i.e. contains a structure of validation errors, or a proper >> business object - depending on the whether the operation was success or fail) >> >> The view would check the status of the result object to see how to handle >> the payload. >> >> Correct me if I am wrong Brian... >> >> Baz >> >> >> >> On Wed, Jul 16, 2008 at 1:09 PM, Ronan Lucio <[EMAIL >> PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote: >> >> Brian, >> >> Brian Kotek escreveu: >>> No Result is only returned during change operations, i.e. saving a >>> User. For list operations I just return the query, because there can >>> be no validation failures for simply *getting* something. Hopefully >>> that makes sense. >> >> Yeap. That's clear. >> >> Thank you once again, >> Ronan >> >> >> >> >> >> >> >> >> >> > >> > > > > -- > E: [EMAIL PROTECTED] > W: www.compoundtheory.com > > > > > > -- E: [EMAIL PROTECTED] W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
