@Baz, Yep that was exactly the kind of thing I was looking for. However, I have something similar in my generator. I treat Application as a business object (I also happen to persist data about each application in a db, so that works out really well), and while I don¹t use it to handle authentication, if I did, I¹d just associate Logins and Users (both also business objects) to Applications in the same way as I associate Addresses to Users and Articles to Pages. So I¹d model that as a system with three interrelated business objects Applications, Logins and Users, and would call the ApplicationService, LoginService and UserService respectively to do everything I might want. This that also means I can auto generate (or dynamically interpret) most of my code as I¹m just using standard ORM¹y CRUD functions such as getUsersinApplication() and the like.
What I¹m having a hard time coming up with is something that couldn¹t be modeled elegantly simply through the concept of interacting business objects and that requires a service layer that doesn¹t map to the BO¹s directly. I¹m sure it¹s out there, but I¹m still searching . . . :-> Best Wishes, Peter On 12/4/07 8:14 PM, "Baz" <[EMAIL PROTECTED]> wrote: > @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] >> <mailto:[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 -~----------~----~----~----~------~----~------~--~---
