Your idea to use a unique "Web service components" server might be
interesting.
But you might have some problems depending on how you build your CFCs, and
performances might be an issue.
For example, if you use "Entity" type CFC, you could do this :
Example :
<cfscript>
newsEntityInstance =
createObject("component","com.mycompany.news.NewsEntity");
newsEntityInstance.load(1011);
newsEntityInstance.title = "I have changed the title";
// or newsEntityInstance.setTitle("I have changed the title"); // if you
create setter/getter functions for each properties
newsEntityInstance.store();
</cfscript>
With a web service, each method call create a new instance of the CFC.
So you could not call the component as previously.
You'll have to write a Facade session that will handle those method calls
inside a single method...
(it is exactly the same problem with Flash Remoting, where it is recommanded
to build "Facade" CFCs for remote access)
Example :
<cfinvoke
webservice = "http://localhost/com/mycompany/news/NewsEntityFacade?wsdl"
method = "updateTitle"
id="1011"
title="I have changed the title"
returnVariable = "isOK">
Below are some other thoughts I have posted on cf-talk.
Have fun!
Benoit Hediard
www.benorama.com
- CF-TALK Message ----------------------------------------
The articles I've put online are a set of "Best practices" and general
design techniques that I daily used for advanced CFMX application
development (in our company, a collaborative plate-form).
They are certainly not perfect (it is not 100% MVC on the controller part)
but they work very well.
The idea is that you can take whatever you like and adapt them to your
needs.
I should add some more details on my use of CFCs, but I haven't updated the
site since august 2002...
For the moment, here it is on CF-Talk.
I usually create :
- Entity CFCs that correspond to physical persistent entity (usually a
single row in one or several database tables).
they inherits from a base Entity.cfc with "init" and "getProperties"
methods,
they usually have at least "load", "create", "store" and "remove" methods,
Ex. :
<cfscript>
newsEntityInstance =
createObject("component","com.mycompany.news.NewsEntity");
newsEntityInstance.load(1011);
newsEntityInstance.title = "I have changed the title";
// or newsEntityInstance.setTitle("I have changed the title"); // if you
create setter/getter functions for each properties
newsEntityInstance.store();
</cfscript>
- Utility CFCs that encapsulate generic business logic and are not
persistent and stateless.
Ex. :
<cfscript>
newsUtility = createObject("component","com.mycompany.news.NewsUtility");
lastNewsRecordSet = newsUtility.getLastNews();
</cfscript>
- Session CFCs that act as a facade to handle the client session
(statefull).
Ex. :
<!--- use the com.mycompany.member.MemberSession CFC put in session
scope --->
<cfif session.currentMember.hasTheRightToDoThat()>
...
</cfif>
This is how I use CFCs for a 100% ColdFusion-based application, but if you
have good J2EE skills in your team and if it is required, you might replace
those CFCs by EJBs (with all their pros and cons...).
Any feedbacks or suggestions on all those stuffs (ColdFusion or Flash) are
welcome!
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2003 12:33 PM
To: [EMAIL PROTECTED]
Subject: Re: [CFCDev] MVCF at benorama.com
I'm looking at it now for the same reasons. Actually, I've been looking at it for about six months, carrying it around in my briefcase, reading bits and pieces of it when I can... it is one of the most well-travelled pieces of documentation I own, having logged a few thousand air miles across three time zones. I think it and Sean's coding standards document have struck up a friendship, they've been in there so long.
The only thing so far has to do with his recommendation of adding a ColdFusion mapping for /com but even that is only an issue due to his recommendation that you map it to /WEB-INF/cfcomponents/com. I seem to remember there being a bug with CF mappings into the WEB-INF directory not working properly. Everything else looks to be excellent.
However, many people will also tell you that you should choose your architecture independently for each project. They may be right, but I'll be really happy if I can just get my team to adopt a standard architecture and methodology in the first place.
----------
The Other Eric
----------
No matter what stage of completion one reaches in a project, the cost of the remainder of the project remains constant.
-- Q's Law
"Davis, Eric" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]03/24/2003 01:55 PM
Please respond to cfcdev
To: [EMAIL PROTECTED]
cc:
Subject: [CFCDev] MVCF at benorama.com
Link: <http://www.benorama.com/coldfusion/>
Word ver.: <http://www.benorama.com/coldfusion/patterns/MVCF.doc>Has anyone looked really hard at this one? What are everybody's thoughts on this?
I'm looking for a replacement to Fusebox 3 for MX - FBMX is too slow coming, and probably won't make much sense anyway (I'm guessing it'll be quite obfuscatory and rather difficult to implement the first five to ten times).
He's put together quite a presentation, and he about has me convinced, if only I can simplify the structure a bit. I'm trying to find the right methodology for my team here to use, and they're NONE of them big methodology-users.
Anyway, just haven't seen any threads about this, and wondered if you folks had anything to say on the subject.
Which of course you must; you always do. ;)
Thanks,
ecd.--
Eric C. Davis
Programmer/Analyst I
Georgia Department of Transportation
Office of I.T. Applications
404.463.2860.158
[EMAIL PROTECTED]
