You can refer back to Sean's earlier statement: "Right, but that can still
be in the domain object rather than the
service." So can it be in the domain object? Yes, and I probably should
clarify my above story some now that I look back at it.
"but it really is the spouse's lawyer's duty to *inform *the spouse that the
documents are valid" I see it as the lawyers job to say yes this is valid
and give it to the spouse. That does not mean the service is Intelligent
enough to know whats valid, the model (probably through the same domain
object[package]) would generally provide the rules for valid/good. The
service is just intelligent enough to know where to go to get the answers.
I'm much more comfortable with doing 2 calls in my service, model.validate();
model.save(), instead of Model.save() and have the save do the validation.
Doing model.save makes my service not much more a facade which isn't what I
want. Additionally in our environment we have multiple validaters, some of
which should not, in my opinion, be part of the domain's concern. An example
of this would be Enterprise vs domain specific validation. Something like
name is 35 characters and does not have cross sit scripting is Enterprise
concerns and part of the validation across all applications irregardless of
domain. Where as address must be in the US is domain specific to Contest
entries. The converse is true too though if you put too much in the service
layer your domain model becomes anemic.
Adam Haskell
On Jan 15, 2008 8:31 AM, Alan Livie <[EMAIL PROTECTED]> wrote:
>
> Good anecdote but I am confused!
>
> You said '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. '
>
> Are you sure about this? Shouldn't the model be responsible for making
> sure things are valid - ie look after itself.
>
> I see the service more as a smart api that delegates to the model for
> all the business logic and also can provide 'application-specific'
> functionality like logging, email notifications etc
>
> But maybe I'm misunderstanding it or taking the anecdote too
> seriously! It's more accurate than the MVC song at least :-)
>
> Alan
>
> On Jan 15, 12:47 pm, "Adam Haskell" <[EMAIL PROTECTED]> wrote:
> > 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] > 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] >
> > > > > wrote:
> >
> > > > > > On Jan 14, 2008 1:19 PM, Brian Kotek < [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
-~----------~----~----~----~------~----~------~--~---
