[cfaussie] Re: CFC Concept Slinging .. You know you wanna be the CFC monkey!

[gary menzel]

I just want to make some comments on a few little slabs of Scott's original post and then some general observations we have tested out here since the post arrived......

> In CFMX, you could continue to this, but then the CFC's would rely on
> the presentation layer as its source for such variables (that or
> whatever you use as your root page context layer).

I was a little bit confused by the comment that the Application space is some how part of the "presentation layer".  It is not really part of any layer at all - but is just a place to store stuff that all parts of the application can get at.

> My question to the CFC gurus out there is, how do you separate the
> Database layer from the rest of the business logic? So that if the evil
> IT Dictator walks into your cubicle and demands you halt all SQL

Firstly, I dont think Barry would like being called an "IT Dictator" :)

Secondly, my call on this would be "If you make sure you do ALL your database calls in CFC's then you have separated your database layer from the rest of the business logic".  But also see my comments below on a suitable methodology for CFMX.  As soon as you put things like database logic into functions (or CFC's) you have isolated that portion so that you can make changed later.  What we have been doing here is we pass a "struct" over with the necessary data and then let the CFC pull out the data into the CFQUERY.  Similarly, when getting a specific record, the data is filled back into a struct that is passed over.  This also works very well with the FORM scope.  If multiple records are being returned, we return a query.  This is completely independent of any methodology being used.

I personally dont create "Is A" relationships between an object and it's storage (that is - I dont inherit to get persistence).  I separate the two.  Your datbase logic returns an appropriate object (or struct) or accepts the same.  At best, relationships between your "data" and the "manipulator" may be a "Has a" relationship.  If I want persistence in an object I create a specific class to hand persisting that object.

You can never completely remove interdependence between each of your layers.  The Presentation Layer (your VIEW) MUST rely on a known API to the Business Layer (your CONTROLLER) and the Business Layer must rely on a known API to the Database Layer (your MODEL).  But what you do achieve is that the VIEW does not need to know abotut eh MODEL.  That is handled by the CONTROLLER.

Where is all this leading?......

> It's a copout I know, but I'm wanting a tight/clean way of doing
> development.

We all want that.  I know sometimes we like to put on our cowboy hat and ride off into the sunset in search of development adventure, but when you have a job to do you want to have a consistent way of producing and performing.  This brings me to the MVCF Methodology (which has been mentioned on this list before cause that's where I found it)......

http://www.benorama.com/ColdFusion/

We have started using this methodology (with a few minor changes) here and are very impressed with the short period of time it too to understand how the model works, decide we wanted to use it, and then to also "adjust" it to suit what we are used to doing now.  The areas where we have changed it are in "self processing pages" and some of the CACHE and I18N facilities it has (which we dont intend using). It very clearly answers your questions, Scott, of "what do I do, how do I do it... wheres that firkin rule book and who what and when".

In addition, Ben Forta also talks about how to use CFC's correctly.  He says that CFC's should never access Application or Session (or any other global scopes) UNLESS IT HAS SET THEM SPECIFICALLY.  Thanks Ben, nice "get out" clause there.  This means that you can have a CFC that DOES set something like a DSN or whatever in the Application scope for your other CFC's to use, as long as you access that back through that CFC again (because then - if that nasty IT Dictator - sorry Barry - does tell you to change it - you only need to do it in one place).

NOW....

We have done a couple of tests here.

Firstly, a WebService DOES have the "this" scope available to it.  You can set "this.dsn" (for example) and it exists (even though you dont necessarily create a WebService object with

Hope this helps.



Gary Menzel
IT Operations Brisbane -+- ABN AMRO Morgans Limited
Level 29, 123 Eagle Street BRISBANE QLD 4000
PH: 07 333 44 828  FX:  07 3834 0828

****************************************************************************
If this communication is not intended for you and you are not an authorised
recipient of this email you are prohibited by law from dealing with or
relying on the email or any file attachments. This prohibition includes
reading, printing, copying, re-transmitting, disseminating, storing or in
any other way dealing or acting in reliance on the information. If you
have received this email in error, we request you contact ABN AMRO Morgans
Limited immediately by returning the email to [EMAIL PROTECTED]
and destroy the original. We will refund any reasonable costs associated
with notifying ABN AMRO Morgans. This email is confidential and may contain
privileged client information. ABN AMRO Morgans has taken reasonable steps
to ensure the accuracy and integrity of all its communications, including
electronic communications, but accepts no liability for materials
transmitted. Materials may also be transmitted without the knowledge of ABN
AMRO Morgans. ABN AMRO Morgans Limited its directors and employees do not
accept liability for the results of any actions taken or not on the basis
of the information in this report. ABN AMRO Morgans Limited and its
associates hold or may hold securities in the companies/trusts mentioned
herein. Any recommendation is made on the basis of our research of the
investment and may not suit the specific requirements of clients.
Assessments of suitability to an individual's portfolio can only be made
after an examination of the particular client's investments, financial
circumstances and requirements.
****************************************************************************
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/