I think this would cause many more problems than it would solve.
Firstly you would need to be able to specify whether any given CFC should be cached or not. If you can't do that then you are removing a massive chunk of usefulness from CFCs.
Assuming you can specify on a per CFC basis whether it should be cached, the question then arises of whether the control of caching should be done in the cfcomponent tag, or in the call that creates the instance. If you do it in the cfcomponent tag it adds a nasty level of uncertainty to code that creates an instance of the object.
Say I create an instance of a CFC like this:
<cfset dao = createObject('component','userDAO')>
<cfset dao.setDSN('somedsn')>I have set the datasource for the DAO, but I don't know if I just changed the DAO for some pre-existing instance of the DAO that is being used by some other part of the application. That can lead to very nasty and hard to track bugs and requires a lot more thought about the application architecture.
If you specify whether to cache the object in the object creation call, you get a minor benefit, but you don't get to see whether the CFC was created or whether you got back a cached instance. That could lead to the same sort of caching problems as you can get with cflogin. The CFC is cached, but you want to forcibly remove it from the cache for some reason.
Another problem is that by adding the automatic caching you're requiring that the user understands more about how the internals of the CFML engine works. If they don't understand that, they may very well be confused when they decide to cache for performance reasons, but are now getting data corruption issues because they don't realize that they're actually always operating on the same object.
With all that in mind I think it's much better to leave it as it is. If you need to shave off those few milliseconds for performance you can easily solve the problem by caching CFC instances in a shared scope. If you don't need that performance boost, you don't have to worry about the issues I mentioned.
Spike
Alan Williamson wrote:
Morning,
My biggest gripe with CFC's is the fact that for every request i am creating a new object, an object that is identical in nature to every other request to that page. So for example if i take one of the sample CFC's found on CFCDEV (http://www.cfczone.org/cfcs/) then if i have 100 concurrent requests to a page that uses a given CFC, then thats 100 objects i have created, where the 1 would have done.
Yes, I could cache them in SESSION/APPLICATION etc but thats overhead and placing the responsibility on me, the CFML developer. I might not even have a [session/application] scope available to me at that time.
If somehow we could 'pool' object instances then this would reduce memory/speed greatly. For the applications i am working on it would increase the overall performance significantly.
So for example, one could create pooled versions of a CFC:
<cfset myCFC = CreateCFC("my.mycfc")>
Where this object would not be created every time, but a reference passed back to the one object passed back to it. The majority of the CFC's are not holding data per-se but operating on data passed in; very much how we use to work with custom-tags in their hey day. Custom-tags only had one instance in the 100concurrent page scenario.
Let the underlying engine worry about the object instances; if I create an object using CreateObject() then its business as usual. But I create it with CreateCFC() then its a pool object, that will be shared. It may not exist, as the underlying engine would be allowed to only keep the last x number of used CFCs and create new ones on demand.
Love to hear your thoughts on this topic.
thx
-- -- -------------------------------------------- Stephen Milligan Code poet for hire http://www.spike.org.uk
Do you cfeclipse? http://cfeclipse.tigris.org
---------------------------------------------------------- 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]
