@Peter
Hey Peter, like you my services very often map 1:1 to my business objects.
But I do have a real-world example where they don't. One of the applications
I am working on is responsible for providing authentication for all other
applications, as well as managing users, groups and roles for all other
applications. So I have the concept of an "Application" and a service that
goes along with it. And I also have the concept of "Logins" (to track
logins) and a service that goes along with that, and so on. Now I have to
provide complex authentication for all outside apps (non CF included), which
requires interaction with "Applications", "Logins" and "Users". So my
"Authentication" service is composed of those 3 other services, with no
business objects of its own. So this would be an example of 1:0 - or if you
factor out all the business objects a 1:3.
Was that in the neighbourhood of what you were asking?
Baz
On Dec 4, 2007 2:52 PM, Sean Corfield <[EMAIL PROTECTED]> wrote:
>
> On Dec 4, 2007 11:41 AM, Peter Bell <[EMAIL PROTECTED]> wrote:
> > Yes and no. It is my preferred approach, but let's say you have a Flex
> app
>
> I didn't mean in all cases. I prefer the service-based approach
> overall but if you read my entire post you'll see that I like to
> inject the service (or Transfer) into the bean so it can save itself.
>
> To answer Paul's question: why is it ugly to have service.saveBeanName()?
>
> I often find I ask a service for a bean (either newFoo() or
> getFooById(id)) and then do a bunch of stuff to it and then want to
> save it. I'm not always in a context where I directly have the service
> available to save the bean - and I don't want to have to write "stub"
> saveFoo(), saveBar() methods on the service just to have them turn
> round and call transfer.save(bean) (since they all do exactly the same
> thing and it doesn't matter what type the bean is!).
>
> > So I like the Bean.save() idiom, but I also wrap that with a
> Service.save()
> > method to complete my remote API.
>
> Well, since I use Transfer for all my persistence, I actually need VOs
> for interacting with Flex so I need a service for the mapping and
> therefore a service.save() method anyway (which takes a VO and maps it
> back into a Transfer object).
>
> My point was that I can inject Transfer into the beans it generates
> and then my beans can save themselves and it's more convenient when
> I'm not in the Flex space.
>
> Is that clearer?
>
> What I'm taking to doing on CF8 is to have a BaseService with an
> onMissingMethod() that implements most of the basic CRUD operations so
> I can call saveFoo() but never have to actually write the code :)
>
> My oMM approach implements:
> - getNew{Object}()
> - get{Object}ById(id)
> - save{Object}(bean)
> and a few others.
> --
> 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
-~----------~----~----~----~------~----~------~--~---
