Here¹s how I do this. I DO have the controller sometimes speak to business
objects and because it¹s all generalized patterns I have a very thin remote
proxy (200-300 lines of code) that allows for the wrapping of all of the
common types of methods so they can be called by Flex or a web service. I¹m
not sure that I¹d argue it as being better (or even as good as) calling the
service method, but for the amount of such code I actually have it¹s an
interesting experiment.
In my experience I have to just try out lots of different idioms before I
really get all of the implications. Luckily as I synthesize most of my code
and make heavy use of parameterized base classes, if I want to change my
approach to these things even across a number of projects, it¹s only
usually a mornings work!
Best Wishes,
Peter
On 1/15/08 11:34 AM, "Brian Kotek" <[EMAIL PROTECTED]> wrote:
> But that won't work if you call it from Flex, that's the point. Flex can't
> call a transient "User" object. It has no idea that such a thing exists. It
> can only talk to a service layer object (via a remote proxy).
>
> If you work this through as a thought experiment you'll see it is true. The
> same thing would apply to a web service call. The web service can't call your
> Order object.
>
> On Jan 15, 2008 11:26 AM, Phillip Senn < [EMAIL PROTECTED]> wrote:
>> But the spouse's lawyer (Controller) is simply relaying the information from
>> the other party (Model).
>>
>> It's the spouse (model) that determines whether something is valid.
>>
>>
>>
>> If (I keep the house)
>>
>> {
>>
>> She gets the dogs.
>>
>> }
>>
>> Else
>>
>> {
>>
>> Invalid transaction.
>>
>> };
>>
>>
>>
>> The transaction is validated whether it was presented from a ColdFusion
>> controller (the lawyer), a .net program or run as an ad-hoc in Management
>> Studio.
>>
>>
>>
>>
>>
>>
>>
>>
>> From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of
>> Adam Haskell
>> Sent: Tuesday, January 15, 2008 7:48 AM
>> To: [email protected]
>> Subject: [CFCDEV] Re: Do you VALIDATE in the SAVE method or keep 'em
>> separate?
>>
>>
>>
>> I've used this anecdote before, and I think it is amusing so I'll use it
>> again. The way I think about it is The model and View are going through a
>> divorce and the controller and service are the lawyers. Now thinking about it
>> in these terms, would it make sense for the Controller (the View's lawyer) to
>> be taking care of the Model's Affairs, in this case validating documents for
>> the model? That doesn't make much sense, in this case the Service should be
>> earning it's keep and making sure the documents are valid and ready for it's
>> client, the model. Sure the Controller might throw in some JS for the View to
>> do some preliminary checking so the always bitchy, soon-to-be ex, spouse
>> won't complain but it really is the spouses lawyer's duty to inform the
>> spouse that the documents are valid, or return the documents to some one
>> telling them to try again, no deal. That being said Brian's earlier statement
>> about calling something from Flex really has helped me clear up what should
>> go where. Anecdotes provide a means to getting over the hump but once you are
>> over the hump real life programming drives the point home and Brian's
>> example/thought process is spot on.
>>
>>
>> Adam Haskell
>>
>> On Jan 14, 2008 11:53 PM, Brian Kotek <[EMAIL PROTECTED]> wrote:
>>
>> It depends on what you mean by "appropriate methods", but if you're talking
>> about something similar to what Peter used an an example:
>>
>> If (Order.isValid())
>> {
>> Order.save();
>> }
>> Else
>> {
>> Screen = OrderForm;
>> Data = Order;
>> };
>>
>>
>> No, I wouldn't be doing that in the Controller (and I think we might be
>> getting some miscommunication here because I'm pretty sure Peter and Sean
>> wouldn't either). My Controllers are very dumb. The only thing they do is ask
>> the Model to perform some business logic (via the service layer), and then
>> invoke the appropriate views or execute a redirect. That covers 99% of what
>> my Controllers do.
>>
>> The problem with doing something like the above in the Controller means that
>> the model is no longer neutral and self-contained. I can't call the service
>> layer from Flex now, because the logic that checks validity and does saving
>> is executed by the Controller, not the Model. I would have a method in my
>> service named something like " orderService.saveOrder(orderData)", and
>> internally that service layer method might create an Order, validate it, save
>> it, and return a success or failure result that the Controller can then use
>> to determine how to proceed (cflocation or redisplay form with errors, for
>> example). I'm pretty sure that this is what Sean and Peter are also talking
>> about.
>>
>>
>>
>> On Jan 14, 2008 9:11 PM, Baz <[EMAIL PROTECTED]> wrote:
>>
>> Sean, Brian, it seems you are both on board with getting a newUserBean() from
>> the service in the controller then calling the appropriate methods on that
>> UserBean later on in the controller. Do you also handle queries or multiple
>> objects in the same way that Peter does? That is, do you code gateway-type
>> methods into your service that interact with a DAO/Gateway to return multiple
>> instances of your object?
>>
>> Baz
>>
>>
>>
>> On Jan 14, 2008 4:40 PM, Brian Kotek <[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]> > wrote:
>>
>> Absolutely, I didn't mean to imply that the service actually does everything
>> itself.
>>
>>
>>
>> On Jan 14, 2008 7:35 PM, Sean Corfield < [EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]> > wrote:
>>
>>
>> On Jan 14, 2008 1:19 PM, Brian Kotek < [EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]> > wrote:
>>> > I think he is saying that his controllers only interact with services. The
>>> > easy rule of thumb for me is: if this was called by Flex instead of my
>>> HTML
>>> > controller, would it still work? The answer should be "yes". Which means
>>> all
>>> > logic of any consequence (beyond doing something like a cflocation, which
>>> is
>>> > specific to the HTML view anyway) should be handled in the model.
>>
>> Right, but that can still be in the domain object rather than the
>> service. You just need to expose the API via the service for remote
>> interaction. It doesn't mean all the business logic is in the
>> *service* which is at the heart of Baz's question, I believe.
>> --
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
