"I respectfully disagree. You think the interface layer should know about persistence?"
"interface layer" is a confusing term... let's call it the "controller" (for those trying to understand MVC. Does the contoller "know" about persistance? If by that you mean that it knows the user is trying to "save" or "fetch" an object, then yes. If you mean that it knows *how* persistance actually works in the model, then no. "So your issue is that doesnt have "service" in the name?" Yep. To me a CFC called "User" models a user. But after reading your email, I realize that you aren't talking about a typical OO model... your forms and controller logic don't know what a "User" is... they just pass raw data into a service layer. "It doesnt, its a facade, it passes the operation on to the appropriate layer. It certainly doesnt have any SQL in it if thats what you mean." I'd hope not. My response was based on the fact that I assumed you meant User.cfc *was* a "user". "Well, I have interface layer code a bit like this (and you're really not gonna like it!): <!--- lets say url.obj = "user" ---> obj = application.factory.new(url.object); result = obj.processinput(data=form,action=form.action); writeoutput(result.message); writeoutput(obj.generateform()); It handles all the form entry, create, update, delete for every object in an entire app. The interface layer only knows that: the factory makes objects, objects generate and accept forms. I have found it very maintainable, and large applications can be written in a day." I now realize we really are discussing procedural coding vs. OO. If a "large application" is a bunch of unrelated forms, then I agree. "So you would have: UserGateway UserService User(Model) And the interface layer needs to create, call, and pass these all into each other as needed? Is that what you are saying?" Of course not. They are typically assembled during application startup... there are many approaches to handling this (I use ColdSpring - surprise surprise). The controller layer would pull a service out of the factory, and use it. "If so, then it seems to me thats pretty intimate knowledge about the structure of your app, and you had better not ever change that or it will become difficult to maintain!" User and UserService are your public API. You want that to change as little as possible. "Calling code" needs to interact with that API and nothing else. Whatever is behind the UserService can change as much as you want. Use DAOs/Don't use DAOs. Use a database/use XML. etc etc. -Dave ----------------------------------------- CONFIDENTIALITY NOTICE: This email and any attachments may contain confidential information that is protected by law and is for the sole use of the individuals or entities to which it is addressed. If you are not the intended recipient, please notify the sender by replying to this email and destroying all copies of the communication and attachments. Further use, disclosure, copying, distribution of, or reliance upon the contents of this email and attachments is strictly prohibited. To contact Albany Medical Center, or for a copy of our privacy practices, please visit us on the Internet at www.amc.edu. ---------------------------------------------------------- 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]
