OOP, Beans, Gateways, Services

Today - i went into a very old part of an application and revised some very old bus. logic. I am giving a facelift to part of a web site and while looking at a view page decided i would change a little logic. There was a call to the database in one of the view pages, since the beans being served up via the application to the view did not have all the data needed. This is a little lazy, to put a call to the db in a view, but understandable, especially if you do not have alot of background in MVC, Gateway, DAO, Front end controller design patterns, not to mention OOP.

After of a bit of consternation about what to do and finding another place in a related view file where i needed a bit more data, i decided to do it right. That meant going into the domain and finding the bean and dao responsible for getting and setting the data for the bean.

First, i needed to be sure i could add the little "bits" of data needed before adding them to the bean and dao. The data i wanted to add was from another database on the same server. No server linking needed! I spent a few minutes looking up how to do this and added the code to the read function of the dao that joined the existing table to a new one in onther db.

Next i added the getter and setter methods to the bean, reloaded the controller - since they cache my beans (since im using Coldspring and machii) - a couple MVC / oop frameworks.

Finally, i added the call to the new bit of data now being server up by the bean and whalla - im in busniess - logic all where it should be.

amen

object programming coldfusion

I just spend about 3 hrs trying to figure out where a piece of output was coming from. This is a bit of a rant against object oriented programming, at least in CF. First off, the resome i was looking for this piece of code is to analyze a program area in the application. For some users, who have alot of data, this list that is build and displayed to the user takes way too long to build. Sometimes in excess of 60 seconds. I think it has caused us to change the loop time out setting in the administrator.

This application is build in a framework called machii. Machii is capable enough framework, a bit heavy, meaning a lot of overhead and files that comprise the framework. Machii makes it easy enought to know where to begin looking for the problem. Follow the event, look for listeners that are calling into a service layer of some sort - follow the service layer into a gateway or DAO object - throw in another framework, coldSpring, and you can get pretty confused pretty fast. Thats a different story.

I traced down into the machii event and found the listener calls and the view files that appeared to be responsible for outputting this slowly developing content. The view files did not have much content in it - just a mysterious call to an XML function. My investigation then took me in another direction, until i found where the content was getting gathered, not displayed. The output is stored in a group of Objects and then xmlized by another function. Hmmmmm, is there a really compelling reason why this content was not simply being returned as a query object? Light, easy... But not object pure. I think this may be a case of the developer being a bit of a OOP purist and treating CF like Java. And why are we xmling the result? What is the gain here? More overhead and complexity. Perhaps its a case of "we may need this later in this portable format"...rather than YAGNI or KISS. Anyway, this feels like alot of overcooking to me. It took me way too long to find this class that was extending a base view event class - to just find about 15 lines of code responsible for actually outputting content.

Bottom line - private functions in cfcs should not be outputting anything. Let the cfcs do their job of getting data and making decisions about what to do - leave the view files to outputting the results.

OOP is good, in the right places, but not always in every situation.

OO birds eye view

OO - think in terms of objects

OO - think in terms of data and functions together in a single entity

OO - think in terms of reference, not value

OO - think in terms of encapsulation (self sufficiency)

OO - think in terms of

OO - think in terms of singleton -vs- transient

OO - think in terms of state of an object

OO - think in terms of security (accessors and modifyers) - getters / setters

Software Architecture (MVC)

think in terms of layers

think in terms of separation of concerns

think in terms of maintenance

think in terms of clarity

think in terms of sessions

Desing Patterns

think in terms of DAOs, Gateways, Beans

think in terms of anti pattern (3- 1) - not every entity needs its own service, gateway and DAO

a service should serve more than just a single DAO and Gateway.

think in terms of doctor - patient (a doctor has many patients)

think of singletons -vs- transients

singletons application wide, transients user wide

transients (have state)
singletons (no state)

*for the singletons (many users using a single instance) think in terms of varing
every variable in it. these are objects stored in application scope.

Frameworks

think in terms of maintenance

thinks of tradeoffs

think of consequences

think of payoff (work up front, payoff later)

think of overhead

think of consistency - predicatability

OO programming from domain to presentation layer

I am always trying to get a better handle on OO programming techniques. I come from that produral background and i think it is always influencing the way i see layer and communication.

If i can think of the objects as two types
singletons - only one copy exists per session per user - these have no state
(these are DOA's, Gateways, Services)

transient - have state and need to keep the state while living in memory
(these are beans or value objects)

In my main application that i support, this means

transient objects or beans that have state (specific data associated with them) are
assessments
standards (performance indicators)
resources

Each of these beans is updated when a new one is selected.

For each user a set of each is created (assesment, resourse, standard) value bean. They are created in the service that is used to communicate with them.

There is only a single service object (a singleton) that is created once when the application starts. The singleton is placed in a application scope and is then accessible to every user who comes to the site. They all share the same instance of the object or class. There is no race concerns because the application (coldFusion) takes care of the threading.

So - one instance of the services for all the users who come to the site. A collection of objects for each user when they initially hit a part of the site that uses the service for those objects.

Also in the service, besides the instantiating of the transient objects, are the rules for when to call the other singletons. The service is the big DOG. It knows about the other services and the other singleton and transient objects. If you looked into the init() of the service.

Again - think like this

- whenever you have data to persist for a value object
- ensure a copy of it exists in memory
- use the DAO to get the updated data (if reading from table)
- use the Form or URL parameters if updating to a table)
- update the current bean in memory
- pass a reference to the bean from the service into the DAO/Gateway when necessary
- pass a reference back to the presentation layer when feasible.

I dont think rules like this are always adviseable, some times it just makes sense to pass by value and not reference. But, in the spirit of OO - think like this by default and work from that position.

I did this in a couple view pages i was recently working on. The the user clicked on a resource or assessment or standard, if the request was to view something - then i would go to the service who who use the id and existing reference to the value object, and pass them both into the DAO gto get the details from the DB. If the request was a update, then i would use the updated values in the form fields and pass them along into the service and update the current bean using the arguments passed in and then pass back a reference to the value (bean) object. now in my presentation layer im referencing the bean that is in memory. Im not actually going back into the db (which is a no no from a MVC perspective) - but referencing the value bean via the object passed along. Encapsulationa and OO techniques!

Im not sure if this is really the smartest way to go about this, but it is my attemp to continue to push out OO concepts and challenge myself to learn to think in terms of Objects and encapsulation.

cheers
What i started to do recently, in the spirit of OO, is to return the pointer or reference to the presentation layer.

3rd party editors - usability

Ive build a utlility application that uses a 3rd party editor called Fckeditor. Its a popular editor, that is implemented in each of the major platforms, java, coldfusion, asp, etc..

I brought it into play originally for another utlitity application that i was working on. Each of the two utilities are about feeding data to a relational db.

Each of the two utilities needs to upload files as part of their jobs. Lots of text, with images needed as well as other upload types. the challenge is that each utility needs to store the uploads in different places. I could, i suppose use different implementations, meaning give each utility its own set of core files (thats about 400 total) - seems a little overkill. What im looking to do is dynamically inform the path where the editor will upload the images to.

Ive dug into the editor a bit and found the upload configuration file that is defining the path where the uploads are going. Now i need to figure out the smartest way to inform the editor where it being used from and pass that variable into the configuration file to dynamically set the userpath.

If this gets too hairy, i can always use plan A, each utility having its own implementation of the fckeditor core files.....but i really dont want to do that.

stay tuned

Im back - im thinking i may try to scale down the size of the fckeditor core files - since alot of them are for implementations that i am not using. Then each Utility could have its own version of the core files. Then, each would have its own

fckeditor.editor.filemanager.upload.cfm.config.cfm

and i could set one where it is now and the other where it needs to be, including the dynamic updating still needed.
Resources path = userfiles/image
assessments path = assessment/assessmentID/

perhaps...i need to continue my heavy lifting around this before moving into a implementation.

Im thinking about creating a utility helper CFC where i could set a session variable or application and use that to inform the assessments *dynamic portion. In the assessments app, im using a framework where i could use a build in plug in point to instantiate the helper object upon application startup. "bootstrapping".

Application.cfc and Frameworks

im working on a utility and am setting up a little session state management. I have a request from a customer like this "when we choose a question type of A, can it remember that for the next one record i add?". Of course, a common request, what i would referr to as state management. Keep the last answer provided by the user via the interface and use it to inform the state of the interface. Session variables come immediatly to mind.

I set off to implement this solution. I thought about it for a little while first, heavylifting, my biggest question was where to lookup and update the session variable. I did not want to do it on the view page, but rather somewhere in a *session object. My thinking brought me into the Application.cfc, which is a special *framework like component that Coldfusion provides that have built in plugin points. This means there are points in a request where the developer can interceed and do some kind of processing, testing etc. These built in functions include application start and end, session start and end, request state and end. This is pretty handy IF you ARE NOT ALLREADY using a framework.

I am using machii and so have a means already to interceed where i need to. Additionaly, the framework allows me to interceed in the event that i want, not all the events. That feels a little better than sticking the test in a OnRequest function. I could put logic in the OnRequest and have it only perform when needed - but even then, that wrapper logic would be read on EVERY request. My framework allows me to place the same test in a listener or service request that is ONLY read when i explicitly call for it.

The framework adds overhead, but pays for itself in many ways, including this one.

Bottom line - dont expect to use Application.cfc or the old school Application.cfm IF you are using a framework. This is a quote from mega smart Sean Corfield.

"It doesn't really. Frameworks generally provide their own plugin points and ignore Application.cfm - and they pretty much ignore Application.cfc as well. Perhaps future versions of the frameworks will support / integrate with Application.cfc? "

Application.cfc and Frameworks

im working on a utility and am setting up a little session state management. I have a request from a customer like this "when we choose a question type of A, can it remember that for the next one record i add?". Of course, a common request, what i would referr to as state management. Keep the last answer provided by the user via the interface and use it to inform the state of the interface. Session variables come immediatly to mind.

I set off to implement this solution. I thought about it for a little while first, heavylifting, my biggest question was where to lookup and update the session variable. I did not want to do it on the view page, but rather somewhere in a *session object. My thinking brought me into the Application.cfc, which is a special *framework like component that Coldfusion provides that have built in plugin points. This means there are points in a request where the developer can interceed and do some kind of processing, testing etc. These built in functions include application start and end, session start and end, request state and end. This is pretty handy IF you ARE NOT ALLREADY using a framework.

I am using machii and so have a means already to interceed where i need to. Additionaly, the framework allows me to interceed in the event that i want, not all the events. That feels a little better than sticking the test in a OnRequest function. I could put logic in the OnRequest and have it only perform when needed - but even then, that wrapper logic would be read on EVERY request. My framework allows me to place the same test in a listener or service request that is ONLY read when i explicitly call for it.

The framework adds overhead, but pays for itself in many ways, including this one.

Bottom line - dont expect to use Application.cfc or the old school Application.cfm IF you are using a framework. This is a quote from mega smart Sean Corfield.

"It doesn't really. Frameworks generally provide their own plugin points and ignore Application.cfm - and they pretty much ignore Application.cfc as well. Perhaps future versions of the frameworks will support / integrate with Application.cfc? "

Beans, DAOs, Services, applications

Im working on a Utility that does standard CRUD stuff. My brain got a little confused, again, in the area of relationships between services, beans and DAOs. Specifically, i could not decide the best way to implement the relationships between the three. In a SOA, we use the Service object as the laison between the application and the domain objects. Does the service also keep the responsibility of creating a persistence bean for a certain object? I think so, i added the instantiation of the resource persistence bean into the init() of the service. Now the service init() function instantiates DOA, Gateway and bean objects. I am using the variables scope in front of each and have tested the threading, which should not be a problem, since each user who instantiates their own service object gets there own copy of each of the other objects.



In my service, I have a set bean method, that updates the "empty" bean object, by passing a objectID into the set bean method - which then goes to the DAO, since thats the object that should have the SQL or whatever DB code you are using. The bean itself should not know about the database that is being used to get its data so it can do its job of persisting. So, the service calls a getRecord method in the DAO, the DAO sends back a 1 record query to the service. Teh service checks to be sure it has a valid result and then passes the query result to the set bean method in the bean itself.



This seems to make sense - following these good OO practices.

• Service creates objects needed to do the work requested by application
  
• Service asks the DAO to get a single record, passing in objectID
  
• DAO returns a single record
  
• Service ensure the record returned is valid (this could be done in DAO too)
  
• Service then calls the set bean method in the bean itself, passing in the record to update
  

In conclusion:

• The DOA does not know about the beans
• The beans do not know about the database
• The service knows about beans and DAOs and Gateways and other services.

new development

Im about to begin development on a medium sized project and wanted to document some of the things i know i should be thinking about before i begin.

Who is my customer - define this, have them in your mind. You should be able to say in a couple works who they are.

What do they want - get a requirements document nailed down. Thats happening now, my customer is detailing the requirements from our meeting, he will share those back with me for agreement before giving to his client. Be very specific about what the specs indicate will be done in the initial iteration. We could use a front to back design methodology that gets the product in front of the client sooner than later. We may still try to do this. I am following the Agile approach, not the water fall. In other words, create smaller more focused iterations of the product, rather than larger more consuming ones. This is a tenent of good design or process.

Getting down to business. I will follow a mature design pattern, MVC. This pattern will focus on the separation of functionality into three distinct pieces. Think usability in the view layer. Ensure the interface is easy to use, clean and reliable. Not too much clutter or needing to dig to see things. Provide immediate feedback in the interface. Perhaps use AJAX type functionality. This will be a data intensive application, so AJAX techniques would be valuable. At the same time, be sure the application works in both IE and FF. AJAX stuff sometimes is cross browser problematic. I could use the built in CF8 AJAX libraries, but this would require that the hosting server would also be using CF8, which is not quite true, yet. I should stay away from cf8 specific functionality for now.

The controller. I will probably use machii or some MVC framework. Other utilities and the main application all use machii. I *could be consistent or i could use as opportunity to try a different framework, like model glue or Tarten. I could forgo a framework all together, but i like what the framework provides and I know that this application is going to grow in complexity.

The model. This is the part that is most interesting to me. I do like the other layers, but the domain modeling and service, DAO, bean objects are of most interest. I have implemented these patterns a few times now and each new opportunity provides more insight and hopefully a tighter design. I could even try to use a ORM tool to stub out the intial domain objects. The domain design includes how to manage the relationships between the collaborating entities. I will probably use ColdSpring again, since i just think its a superb piece of engineering. Maybe i wont use CS, and show how the objects themselves could keep that knowledge, via init and constructors.

Ill return in a couple weeks when im done with the initial build of this Utility.

Reflection - training new developers

I have been helping a co-worker do some work that has really caused me to look at some high level principles. I like this, and wanted to capture some of the thoughts. first off, we are following the SOA design patterns in our development. this to me means - creating a service oriented architecture, where the service objects are the big dogs in the playground. they are at the conceptual front of the domain line. They are who is called when some application wants to get at some data.

In our application, we are using machii, so there are listeners that are registered as part of the application. Whenever the application does something - it is funneled through the controller (a xml file) in the form of an event. If the event needs to speak to the data layer - then is uses one of the registered listeners to do that.

The listener has lots of functions in it and has *knowledge of the event and the arguments or parameters *URL variables that are passed around (this is usually either URL or form data served up by a view page. The listeners job is primarily to pass things along - pieces of data that the service will need that determines what to do with it.

This is know as the bus. logic and should live downsteam from the application and listeners. The bus. logic should live in the service and in the persistance objects.

So, while helping my co-worked to understand all this abstraction of layers - i found myself using works like design patterns, service oriented architecture and persistence beans - including anemic -vs- rich beans. When you have to explain to someone why things are how they are, it makes you think very critically about the why portion - and you better have more than a "because thats how i found it" response.

I am also using coldSpring - so i talked about where the service gets its knowledge of things from. rather than the service objects creating its dependent objects itself - that knowledge is abstracted from the collaborating objects and into a *container xml file that does it for you. Brilliant!. I do like coldspring alot! I talked with her about where this new piece of bus. logic should go and where it should come from and why. It was a neat experience.

Im not saying that i have all the answers or that the answers that i have are perfect, im just saying it felt good to explain this stuff and to see her seem to get it.