There was the "business logic" layer -- all of those components (data access, caching, etc.) had methods that took a blogID (equivalent to your company_id) and had reasonably verbose APIs. But, then there was a "gateway" layer that acted as the end-API for a developer. Each blog would get its own instance of the gateway, but all gateways would use the cached instances of the business logic layer. You could modify this concept slightly to make your session-based CFC merely a facade for interacting with your more complex business layer. The session-based CFC would be given a company_id when it is first created and hold that as an instance variable. It would then call down into your cached business services that all require a company_id on a per-method basis, but that would be hidden from the end-developer/page level and encapsulated inside the session-based facade. I'm not saying the facade would manage the session, but rather it might look like:
session.companyGateway.foo()
Where the "companyGateway" instance (or whatever you call it) already knows which company_id is relevant for itself, and it holds references to CFCs cached in your server scope (assuming you continue to use SERVER for your caching).
The data caching layer underneath all this could still hold things in a big struct based on company ID, but that would be hidden even from the facade/business logic (again, consider putting caching in its own CFC that your data access layer interacts with -- either directly or through an intermediary that manages them both).
As an aside, I agree that it would be nice if CFCs had some notion of "constants", but they don't -- to make assumptions about what parts of your THIS scope will be changed in the future sounds like a dangerous gamble, not to mention that if you rely on those variables internally, it doesn't change that the end developer could end up changing them, causing strange and hard to debug behaviors.
Barry L Beattie wrote:
----------------------------------------------------------Anything where the implementation may change, or have complex effects, get a getter/setter.
I haven't a problem modifying the existing get and set data methods to be bog-standard property getters and setters - each init() would wind up the properties with data and any property "set" would also pass the data back to the persist layer. nothing unusual there.
it's the implementation of multiple versions of properties for each CFC - one for each company - that I've not settled on yet. each version would have exactly the same structure but differ only in data, based on the company_id.
a typical site install would have between 1 and (say) 6 companies all using exactly the same codebase and db - that's why *company_id* is (currently) in every method call and query. Taken a step further, each company would use the same instance of each type of CFC, but would need to use company_id as it's "key" when refering to any properties of the CFC. it just strikes me that I won't have descrete properties per se, but one large struct with keys based on the company_id (which, I suppose, sums up a CFC's "variables" scope anyway - it just feels like a "wierd" idea, that's all...)
At least a third of the total db data could be held as CFC properties in server scope if I can change it over. Presently, none of it is - they're all disparate method calls and no properties as such. It could reduce database hits by up to 50% (it's a very chatty system ATM)
as an alternative, I've been thinking about multiple instances of each CFC (one for each company) but the idea of gettting a reference to the correct instance based on a users session.company_id doesn't "feel" right:
eg: <cfset bOK = server.setup#session.company_id#.setparms(argumentCollection="#args#") />
so, any thoughts on the nested struct properties that each CFC would have?
thanx barry.b
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
