That's what your UI talks to in order to get a business operation done on it's behalf. The methods correspond to the actions your application can perform. Calling deleteUser(userId) in response to clicking a 'delete' button for a user would be an example. So would calling scheduleDocumentPosting(documentId, postDate, archiveDate) to post a given document with the specified params.
The service objects provide an API that your UI or UIs can use to make the application work. The entire business logic is behind the service objects so that it remains entirely UI neutral, very important in these days of web services and RIAs, because a large percentage of applications will have more than one UI they have to work with concurrently. (And yes, web services are UIs, the user is just a machine, not a person.) Theoretically, you should be able to devise the API from your business requirments, document it, and then have one team build a UI, and one team build the application itself (the business logic), and then stick them together using the API as the common connector. And keep asking. That's what the list is for. ; ) cheers, barneyb On 8/19/05, Peter Hardy <[EMAIL PROTECTED]> wrote: > I'm sure you've given an excellant explanation but erm ... what's a service > object? <blush> > > Cheers, Pete (aka lad4bear) > > Ps: I promise, that's my last question! :) > > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
