> First, there is a kind of awkward coupling between the validate() and save() > functions. You will never want to save invalid data, so these functions will > almost always be called in sequence.
I can think of instances in which I want to save invalid data... but I see your point. > This sequence, or relationship has to > be known, documented and remembered, which will only cause problems down the > road. The same sequence needs to be remembered and documented from a result object, as you need to check it for errors etc. So I don't see much difference here. Consider a slightly more complex example where you had different > degrees of saves(), like savePersonalDataOnly(), and therefore different > degrees of validation(). I don't see that.. if you're only doing a partial edit, then you're still have to fullfill the full validation. I can't see how there can be difference validations for an object, It's either valid, or its not. I can see how you could change validation based on, say for example, if a User object changed Roles, but that would be encapsulated in the object itself. >You will have to either know which validate() > functions to match to which saves() or look into the internal workings of > the save() to know which columns to validate() in your generic validate() > method - the first solution increases coding complexity and is prone to > errors, and the second violates encapsulation. Your team will have to be > heavily trained and up to speed on which functions are related to which and > therefore mistakes will happen. I still can't see a reason to have differing validation schemes. Can you provide an example? > Now on the flip-side, if you use the result > object technique, you can provide simple service functions such as > saveUser() and savePersonalData() that perform the appropriate validation > for you and return a nice neat result object with everything that you need. I still don't see how the validtion would change. > > Another potential problem is the case of interacting with multiple BO's in > one service function. What if saveUser() also needs to validate or save a > second BO that the UserBO is not composed of? There is no real solution to > that except for more controller logic - which is bad. Well, if you save() methods are separate for the objects, the controller logic is about the same, as you need to handle 2 result objects, so I don't see a difference. And if your save() can take more than one BO, then... that is just.. weird? ;) > Another problem is what if your validation is slightly more complex than > pass/fail - for example let's say that in a certain case of saving(), you > want to default one of the invalid values to some other value, rather than > error out the save(). Your options would be to add more controller logic, or > make to make yet another coupled special validation() function that also > changes the values of your BO - awkward. Can you please provide an example of this? I can't think of an instance in which I would want my validation to be messing around with my BO data. Maybe this is a case of where a separation of Form validation, and BO validation is needed. > > Finally let's consider flex. The validation logic that you have in the > controller will need to be duplicated. So rather than simply invoking > saveUser() and getting back a structure that has the validation errors and > the business object, you will have to send two, separate, nearly identical > and potentially heavy requests to your service to first validate() then > save(). What happens if your consumer forgets to validate? Basically there > is no real choice but to combine the validate() and save() into one neat > function and that requires a result object. Amazon, google and yahoo work > like that. I can see the case of wrapping something like this up for a remote proxy, for pragmatic reasons (tho I would probably keep my validation mimic'd in my Flex VO, for speed's sake... but hey, I'm relatively inexperienced with Flex, so who knows), but as a general usage pattern, it still feels funny, and I'm yet to see a real benefit. I'm happy to say it 'boils down to personal preference', which is totally a valid concern as well. Mark -- 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 -~----------~----~----~----~------~----~------~--~---
