Ahh, makes perfect sense. Sounds like we do things pretty similarly. On Jul 17, 2008, at 8:58 AM, Mark Mandel wrote:
> > 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 -~----------~----~----~----~------~----~------~--~---
