I will not bore everyone with all the details of my conundrum, but suffice it to say, even though I would like to, I cannot implement my DAOs and Gateways as shared CFC objects in the application scope in the existing systems that I am enhancing at work. The simple reason is that the production support team that I work with does not want to either bounce the server or have to run an extra script to re-init the application variables after deployment. I'm trying to get this changed, but for now I have to deal with it.
As a workaround, I have my bean store an instance of the related DAO and Gateway object. The bean methods do not use the DAO/Gateway objects, but rather, facade methods are used to call the corresponding methods of the DAO/Gateway. Other than the obvious issue, which is that this particular solution will generally require more memory than using shared objects, are there any other inherint design issues/flaws here? I figured at least this way, I will not have to manage 3 object instances every time I want to use a bean. Would it be better to instantiate the DAO and Gateway outside the context of the Bean? Would it be possible to use the server scope instead of the application scope? If so, would that be a bad idea? Any suggestions would be much appreciated. - Justin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:255306 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
