If you REALLY want to get confused, in the Flex and ColdFusion integration 101 talk right now at CF United, they are describing the façade to the flex application as a GATEWAY, and they're also suggesting that an ActiveRecord actually handles the SQL rather than the more common approach of an ActiveRecord simply replacing the Service as the interface either of which would rely on a DAO to encapsulate database access. Bizarre!
Still, Flex does look very cool. I've blogged on what I think of passive wizard generators (http://www.pbell.com/index.cfm/2006/6/24/active-vs-passive-application-gene ration), so I'm not a fan of them as a way of building applications (Flex builder has a bunch of cool wizards), but when I get some time to play with it, I'll try to put together an active generator based on the templates created by the passive generator so we could all generate this stuff using a database or XML file with metadata. To be fair, someone may beat me to this as I'm pretty backed up, but I'll see what I can do! Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Wednesday, June 28, 2006 3:38 PM To: [email protected] Subject: Re: [CFCDev] Service Layer? I always think of things like this: - gateways are encapsulated SELECT statements, typically that return queries, but sometimes return simple types (like a SELECT COUNT(*) query). - services are encapsulated behaviour that accept simple data (or transfer objects) and do something with them (create an entity; load, update, and save an entity; invoke some business logic; etc.). - domain objects (entities, workflows, etc.) are where business logic resides, and should be entirely hidden behind your services. Note that the service layer isn't necessarily where your business logic should reside. In fact, you generally want it to reside elsewhere. The services are really little more than adapters that turn raw data (i.e. form fields) into a message to pass to your business logic (a bean and DAO, for example). Almost all complex processing should exist as part of your domain model, and your services just provide a way for the UI to interact with the model through a simple API. cheers, barneyb On 6/28/06, Jeff D. Chastain <[EMAIL PROTECTED]> wrote: > I am working on a simple contact manager type application using MG > Unity and some other things I wanted to play with. I have built all > of my low level data objects (bean, dao, gateway) for a Contact, which > has one or more Addresses, which then has a State and a Country. > > Where I am getting stuck is on the "service" layer. In once case, I > am looking to create functionality where an entire contact could be > updated at once by passing in a struct (i.e. the form scope). So in > my mind this means a ContactService with a method to update the > contact and that method then utilizes the different contact, address, > state, and country beans and daos. > > Another requirement though is to obtain a list of the 5 most recently > updated contacts. Is this something that would go in the same > ContactService or where would this go? I have never had a good grasp > on what should go where in terms of a service layer, so I am looking > for any input on how service layers are really built and organized. > > Thanks > -- Jeff > > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
