Skip to main content
Inspiring
October 27, 2013
Question

Need help understanding what an OOP Gateway is

  • October 27, 2013
  • 1 reply
  • 1612 views

Slowly and surely I am learning OOP with CF, but I'm stuck at the concept of gateways.  In my custom framework, when I want data, I simply do the following:

<cfset myData = APPLICATION.coms.data.executeQuery(

     sql = 'get-open-tickets',

     data = {

       'firstName' = 'Aegis',

       'lastName' = 'Kleais'

     }

) />

Basically it calls a singleton 'data' component I have stored in APPLICATION.coms and runs an executeQuery method.  This takes 2 arguments, sql (the name of the SQL file to load from a repository that contains all the SQL) and data (A structure that allows the sql file in question to reference dynamic data; in the above, the SQL being executed has access to ARGUMENTS.data.firstName and ARGUMENTS.data.lastName.

The query is executed, SQL run, data returned, and I'm done.

But from what I've gathered about gateways, I'm supposed to create an object, make a method called getOpenTickets and then pass in data instead.  Since this has to do with tickets, I assume naming conventions would dicated I create ticketGateway.cfc and then build a 'getOpenTickets" function inside of that. 

Am I understanding this correctly?

    This topic has been closed for replies.

    1 reply

    Inspiring
    October 27, 2013

    Spoke with a friend of mine and I think he helped me understand more.

    userBean.cfc - A transient object, stored into a persistent scope (SESSION) which has properties as well as accessor methods (getters) and mutator methods (setters) for the properties.  If a userBean has 3 properties: lastName, firstName and age, then, if it is a read-only bean, it will have getFirstName(), getLastName() and getAge() accessors, but if it is a Read/Write bean, it will have those methods and setFirstName(), setLastName() and setAge().  The userBean object is only aware of itself, and if read-only, usually sets its properties when it is inited.

    userGateway.cfc - A singleton object, stored into a persistent scope (APPLICATION) which provides method functionality for a singular userBean objects.  userBeans are passed to the gateway as well, along with a method, such as: userGateway.getReverseName( userBeanObject ).  Since CF passes objects by reference, the getReverseName can pull getLastName() and getFirstName() from the userBean object passed in and return back a string to the caller of the name in reverse orded, (lastName, firstName).

    userService.cfc - A singleton object, stored into a persistent scope (APPLICATION), which provides method functionality for multiple userBean objects.  The userService could have a method like killNonAdminUserSessions() where it would coordinate with CF service objects in iterating over sessions for the current application, and since the userBean is stored into the session scope, it can get identifiers for those, and then use the gateway run a killUserSession() method over each userBean object the service found.

    So a userBean represents a single instance of data and its properties.  The userGateway represents functionality that can be performed on single data instances.  And the userService represents functionality that can be performed on multiple data instances, many times, sending userBean objects to a userGateway object iteratively.

    .....Did I get it right?

    Carl Von Stetten
    Legend
    October 28, 2013

    Aegis,

    The bean part I think you got mostly right.  The method getReverseName() would actually be on the bean not the gateway, and any other methods that would calculate values based on properties of the bean (e.g. a getBirthYear() method to subtract the age from the current year).

    Generally, gateways are singletons used to get data from an external store, be that a database, a web service, a file, or anything else.  It can return multiple records, so if you are populating beans with the data it returns, you might actually return an array of beans.  Related to gateways are Data Access Objects (DAOs), which are singletons that are used to perform CRUD operations (create, read, update, delete) on a single record (or bean).  Sometimes, developers will combine DAO and gateway methods into a single object.

    The service objects, as I understand them, are an abstraction layer that "hides" the gateways/DAOs/beans (your model) and provides a simpler layer of interaction with the rest of your application.

    I'm still trying to understand the OOP process myself, so if I've gotten any of this wrong, hopefully someone else will jump in and correct me.

    -Carl V.

    Inspiring
    October 28, 2013

    Thanks Carl!  You're always good for some clarification!

    So a bean is comprised of properties.  And aside from getting/setting those properties, they are also responsible for any functionality based on those properties.  That makes sense.  Might as well keep all property-related methods in the same object.  I hear people constantly talk about the singularity of a bean.  They keep saying "It is 1 record of data" (but this keeps putting me in the mindset of database tables/fields).  If I have a user bean, and he has a lastName, firstName and age property, he is simply contains data on a singular entity. Correct?

    And gateways are used to access external data, you say, right?  The most common of course is databases.  So I'm trying to formulate an example.  A userGateway object woud have methods that (if combined with the DAO functionality, would include CRUD-related taskes on the user, but aside from dealing with just 1 user bean, they support the ability to address multiple, right?  So for example, if I wanted to create a single user bean for all users, I would access this userGateway object, call a method like getAllUsers(), it would contain the data source and then it would create each user bean by sending data to their init() method, correct?

    And because this methodology inside a bean and gateway may include many functions, a lot of which are private and just used to encapsulate tasks and be called privately, a service layer is the "frontend" to the gateway/dao + bean "backend", providing methods that simplify the tasks.  For example.

    1. Call userService.getUserBean( 2 )

    2. The userService contacts the userGateway's readBean( id ) method which hits the databases and returns a query of 1 singular row of data.

    3. The userGateway then takes that data and inits a singular user bean based off the data by calling the user.cfc and passing in init() data.

    4. The userGateway then sends that user bean back to the userService which returns the bean back to the caller.

    Do I have that down?