• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Object Oreinted Approach in Coldfusion
 

Object Oreinted Approach in Coldfusion

on

  • 1,776 views

introduces the OOPs in CF and mentions the advantages of OOPs.

introduces the OOPs in CF and mentions the advantages of OOPs.
Problems faced in OOPs and managing Components using Coldspring.

Statistics

Views

Total Views
1,776
Views on SlideShare
1,767
Embed Views
9

Actions

Likes
1
Downloads
22
Comments
0

1 Embed 9

http://www.slideshare.net 9

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Object Oreinted Approach in Coldfusion Object Oreinted Approach in Coldfusion Presentation Transcript

    •  
      • Procedural Code Vs Object Oriented CF code
      • Object Oriented approach in CF
      • Why OOPs?
      • Types of components
      • Complexities in Object Oriented approach
      • Introduce Factories.
      • Problems addressed and not addressed by factories
      • Introduce CodlSpring framework .
      • Initialization and dependency handled by Coldspring
      • Summary
      • Procedural
        • <CFINCLUDE> tags
        • Coldfusion Custom tags
        • User defined Function
        • Implemented using FuseBox 3.1 framework in VE
      • Object Oriented
        • CFC – ColdFusion Components
          • <CFCOMPONENT>, <CFINVOKE>, <CFOBJECT>
        • Implemented using FuseBox 4.1 framework in VE
      • Implementing OOPs in CF
      • CFC - <CFCOMPONENT>
      • Functions - <CFFUNCTION>, <CFARGUMENT>, <CFRETURN>
      • Object Instance - <CFINVOKE>, <CFINVOKEARGUMENT>, <CFOBJECT>, createObject(), init()
      • Properties - <CFPROPERTY>
      • Represents Real world objects and therefore gives a lot of meaning to the code.
      • High Reusability
      • Easy Maintenance
      • Isolation of different layers (User Interface, Business Logic, Data)
      • People, Place, Things
        • Represent real world stuff
        • Related objects are created as and when needed
        • Usually core to the business model
      • Services and Infrastructure
        • Represent concepts and processes
        • Related objects are often other services and infrastructure
          • Data Access Objects, Data source objects
        • Usually created at application startup
      • Problems in Object Creation:
      • createObject(), <cfobject>, <cfinvoke> all require “pathnames” to CFCs
      • Code is littered with hardcoded strings specifying locations of CFCs
      • Hard to move CFCs around or swap out one implementation (CFC) for another
      • Hard to unit test code because you can't easily substitute a “mock” CFC for the full object
      Inside your controller code: <cfset var dsn = createObject( “component”, “ cfcs.datasource” ).init( “testdb” ) > <cfset variables.dao = createObject( “component”, “ cfcs.mysql.dao” ).init( dsn ) >
      • Problems with Dependencies
      • If the controller needs the data access object and the data access object needs the datasource object, how do you create/ initialize them?
      • Create datasource object
      • Create data access object and initialize with datasource object
      • But whose responsibility should this be?
      • A factory “makes things”
      • A factory object makes objects
      • Move hardcoded paths into the factory object – only one place to make changes now.
      • Factory knows about dependencies
      • Rest of your code depends on the factory object
      • “ Factory Method”Pattern
      Inside your factory: <cffunction name=“getDatasource”> <cfreturn createObject( “component”, “ cfcs.datasource” ) .init( “testdb” ) > </cffunction> <cffunction name= “getDAO”> <cfreturn createObject( “component”, “ cfcs.mysql.dao” ) .init( getDatasource() ) </cffunction>
      • Inside your controller code:
      • <cfset variables.dao = myFactory.getDAO() >
      • Where does myFactory come from?
      • Passed into controller?
      • Created by controller?
      • Or use application.factory instead?
      • Factory created during application initialization:
      • <cfset application.factory = createObject( “component”,
      • “ cfcs.factory” ).init() >
      • Problems Addressed
      • No hardcoded paths in application code
      • Can move CFCs (or change implementation) by changing only
      • the factory code
      • Some initialization can be handled by the factory
      • But where does it get the initialization data?
      • Problems Not Addressed
      • Unit testing /mocks mean changing the factory code all the time
      • Factory needs to know dependencies
      • Initialization is still a pain:
      • -Factory can be passed the initialization data
      • -Factory can contain the initialization data
      • - Factory can load data fromsomewhere... (hmm, con!g !les!)
      • -Factory can pass back uninitialized objects (bad!)
      • A testing factory and a regular factory
      • Lots of duplicated code
      • Have to change code to test different parts of the application
      • Can also solve the multiple database support problem(a data
      • Access object factory for MS SQL,MySQL, Oracle...)
      • “ Abstract Factory”Pattern
      • Multiple factories with the same API
      Selecting factories at startup: <cfif dbType is “mysql”> <cfset application.factory =createObject( “component”,“cfcs.mysqlfactory” ) .init() > <cfelse> <cfset application.factory = createObject( “component”, “ cfcs.oraclefactory” ) .init() > </cfif>
      • Problems Addressed
      • Ability to create different sets of objects – swapping implementations, unit testing (sort of)
      • Problems Not Addressed
      • Initialization – partially solved but it's still ugly
      • Dependencies – still hardcoded, still has complex initialization issues
      • Instead of trying to handcode each factory and managing all of the dependencies and initializations, why not use a generic
      • factory?
      • ChiliBeans
      • - Included with Model-Glue
      • - Effectively deprecated
      • ColdSpring
      • - Muchmore than just a factory
      • A container to manage your CFCs
      • http://coldspringframework.org/
      • XML configuration file specifies:
        • CFC pathnames and type names
        • Initialization (via constructors or setters)
        • Dependencies
      • Ask ColdSpring for “foo”and get a fully initialized, resolved object of the appropriate type
      • Problems Addressed
      • No hardcoded paths in application code
      • Can move CFCs or change implementation just by changing XML declarations
      • All initialization handled
      • All dependencies managed
      • Create different objects
        • By swapping XML !le or just changing the XML declarations
    • Datasource CFC (abbreviated) 􀀀 <cfcomponent> <cffunction name=“init”> <cfargument name=“name”> <cfset variables.name = arguments.name> <cfreturn this> </cffunction> <cffunction name=“getName”> <cfreturn variables.name> </cffunction> </cfcomponent> DAO CFC (abbreviated) 􀀀 <cfcomponent> <cffunction name=“init”> <cfargument name=“dsn”> <cfset variables.dsn = arguments.dsn> <cfreturn this> </cffunction> <cffunction name=“getDSN”> <cfreturn variables.dsn> </cffunction> </cfcomponent> Application Initialization <cfset application.cs = createObject(“component”,“coldspring.beans.DefaultXmlFactory”).init() > <cfset application.cs.loadBeans(expandPath(“cs.xml”)) > Application Code <cfset dao = application.cs.getBean(“dao”) > Returns a fully initialized data access object <cfset dsn = dao.getDSN() > ColdSpring resolved the dependency and created (and initialized) the datasource bean first, then created the data access object bean and initialized it with the datasource bean.
      • XML Con!guration
      • <beans>
      • <bean id=“dao” type=“cfcs.mysql.dao”>
      • <constructor-arg name=“dsn”>
      • <bean type=“cfcs.datasource”>
      • <constructor-arg name=“name”>
      • <value>testdb</value>
      • </constructor-arg>
      • </bean>
      • </constructor-arg>
      • </bean>
      • </beans>
      XML Examined (1) <bean id=“dao” type=“cfcs.mysql.dao”> Specifies that “dao” resolves to cfcs.mysql.dao type – can easily change to cfcs.oracle.dao etc <constructor-arg name=“dsn”> Specifies a constructor argument – ColdSpring creates the argument value (a bean) and passes it into the constructor automatically Could use <property> instead and ColdSpring would call setXxx()method to set the property XML Examined (2) <bean type=“cfcs.datasource”> Unnamed object passed to“dao” constructor <constructor-arg name=“name”> Specifies constructor argument for this datasource bean <value>testdb</value> Specifies the (string) value passed to the constructor: obj.init(name=“testdb”)