Mach-Spring

 
Mar 01, 2006

by Judith Dinowitz

Mach-II and ColdSpring are two of ColdFusion's more complex frameworks. One would think that learning how to use either of them effectively would be enough of a challenge for your typical advanced ColdFusion developer. And many ColdFusion developers would never think of using them in tandem... After all, why learn two frameworks when one will do the job?

Kurt Wiersma disagrees. He says that Mach-II and ColdSpring are a powerful combination, and at cf.Objective(), he is going to show us how to combine them effectively in order to create more robust ColdFusion applications quickly and efficiently.

Mach-II: The Building Blocks, or Legos

Kurt said that he will not delve deeply into Mach-II in his presentation. He will not be showing his audience how to build a Mach-II application. To learn about Mach-II, he suggests that cf.Objective() attendees go to Matt Woodward's session, which is scheduled right before his.

Besides the Mach-II knowledge, Kurt is also assuming some familiarity with Object Oriented concepts. "You have to have some basic understanding of OO to get a lot out of this presentation. But you could really structure this conference like your own private course. A lot of the other presentations that are going to be before mine will be covering these topics. The way that Jared has set up the tracks is perfect for coming up to speed on developing OO applications." You'll find more of Kurt's ideas for making cf.Objective() like your own private seminar on his blog, http://jroller.com/page/kwiersma.

For the purposes of this article, I'm going to start by giving a short overview of Mach-II's structure. Mach-II uses events (things that happen in your application, such as a user clicking the submit button on a particular form) to call listeners (CFCs that are responsible for some form of action). The listeners, rather than an index.cfm template, serve as controllers for the application, making the choices about what to do based on the event that was called. All information about the different events and listeners are recorded in the Mach-II config file.

To show how this would work, let's give a very concrete example. Say you were building a website and needed a login form for an area of your site. When the login information was submitted, the application would call an event called Login (http://www.mysite.com/index.cfm?event=Login). This event would call on the Login listener, which would then call a User Service CFC.

What is a service? Services are CFCs that are responsible for a particular functionality that you might use many times in several applications. For example, this User Service would be responsible for getting information (or for updating information) about the users on your system. In our login example, the User Service would call a Gateway CFC, which would look up the user name and password provided by the user, and a database and query of users who match that criteria. The service CFC would then check to see that only one user matches, and if so, it would call a DAO (Data Access Object) to read the actual user object from the database . The User Service, having now authenticated the user, would return that user object to the listener, or, if the user name and password were incorrect, it would return a blank user object to the listener. The listener would then determine whether to allow the user access or not by announcing the appropriate event to Mach-II.

Don't worry too much if you didn't follow this example closely, because Kurt is going to be introducing AppBooster, a sample application that shows an example of user authentication. You can even use AppBooster to help get you started on your next Mach-II and ColdSpring project.

Kurt explained that Mach-II may sound very complex, but its purpose is to make it much easier for the developer to write and maintain his application. In our example, we have several small pieces, or objects, that are responsible for very specific and limited functionality. The User Service has a DAO whose sole job is to read or write from the User table. It also contains a Gateway whose function is simply to return a query to whatever calls it. While we used this service for a login form, which is part and parcel of most websites, it could be used for any application that might deal with user data.

"The reason [for using Mach-II] comes down to code reuse," Kurt said. "I can call that Service CFC from any application I want -- from a Mach-II application, from a ModelGlue application, or through flash remoting. I can even potentially use it as a web service. I can reuse that functionality all over the place."

Kurt compared the objects and services in an OO application to lego pieces. They are building blocks that we can take apart and put together again in many different forms. The problem is: How do we keep track of these lego pieces, and how do we set things up so that we can take them out and build them up, as needed, without having to constantly rewrite the code that will instantiate these objects? That's where ColdSpring comes in.

ColdSpring: The Toy Chest that Holds the Legos

ColdSpring, which is the brainchild of Dave Ross (with contributions by Chris Scott and Kurt Wiersma), was created to manage dependencies. In the Object Oriented world, objects work together and may depend on the information or methods contained in other objects. This is known as the object's dependencies. ColdSpring keeps a list of these dependencies in its own xml config file, and based on that information, it will create new objects by injecting an object that already exists with the dependencies that it needs. So ColdSpring will create a new object, complete with the information it needs, on the fly, and it will also keep track of all available services for an application. ColdSpring will even keep the objects that it manages in the application scope for you so that you don't take a performance hit by recreating an object each time it is requested, although you can configure ColdSpring to do that.

How does ColdSpring interface with Mach-II? ColdSpring has a Mach-II plugin that takes any of the services inside of ColdSpring and injects them into a Mach-II listener. So, in our example above, the Mach-II Login listener is trying to call the User Service. ColdSpring sees the Listener and consults its config file. It says: "Aha! The user service needs a User DAO and an User Gateway to get the information from the database." It then instantiates an instance of the User Service and injects that object into the Mach-II listener. This is all controlled by ColdSpring, so after the xml config files are set up for Mach-II and ColdSpring, the developer does not even have to think about it anymore, which makes the job of maintaining that application much easier. To make a change in the functionality of the user service, or to add a new listener or service to the application, the programmer simply has to add that information to the Mach-II and ColdSpring config files.

Why Go to All this Trouble?

At first, when I interviewed Kurt, I was skeptical. ColdFusion was built for doing rapid web development, and for doing complex applications in fewer lines than languages like Java or ASP.NET. Using one framework already adds a certain amount of overhead, in setup, planning and organization of code. Wouldn't two frameworks together make a ColdFusion application more heavy than it needs to be?

"It does matter what you're doing," Kurt said. "If you're putting together a simple website or a small application, this may not be the most efficient setup. Any small applications that will be built one time and then rarely touched might not need this type of architecture." So what kind of applications are good candidates for Mach-Spring (a term I've coined for the combined use of Mach-II and ColdSpring)?

"We're talking about Enterprise applications, medium- to large-sized projects. These are applications that are likely to grow, and to reuse components inside the same application or across several related applications," said Kurt. "The overhead here is not really in the application's performance, but in the lines of code and the number of files you might need for the application." Kurt stressed that the benefits in terms of maintaining your application are enormous. To illustrate these benefits, he will take his audience through the process of building a Mach-Spring application and maintaining it. The example application he will show, while simple, will showcase how developers can build applications quickly with Mach-Spring, and how the combination of frameworks will help them reuse their code and maintain it much more effectively than either framework will alone.

The Code Generator: The Final Piece

To make Kurt's life easier, he has developed a code generator for Mach-Spring applications. When provided with a datasource and table name, the generator will build a DAO, a Gateway, a Service, the XML lines to put in your ColdSpring config file, a Mach-II listener, and a really simple listing screen that takes a query, loops through it, and shows a list of users. Developers can then customize the generated code to their own needs, but this generator saves Kurt a lot of time when building his applications. He will be showing it off in his session, and providing a copy for all attendees.

"This is how I develop all of my applications. I've set up this OO architecture," said Kurt. "There are practices that I've refined, and that the community has, as well. You can use a big chunk of this with any application you build. It doesn't even have to be a Mach-II application." The ideas that he'll be highlighting in this presentation -- the reuse of code through the segmentation that Mach-II and ColdSpring provide, and the use of a code generator -- can be incorporated by anyone who is doing Object Oriented ColdFusion, even if they aren't using Mach-II.

The Future: Learning Object Oriented Programming

What is the best way for a ColdFusion programmer to learn Object Oriented programming? "Start by building your own little application, a 'proof of concept,' as it were. Make sure it's small and relatively simple. Then take a look at the examples online for OO techniques. Most of these examples are pretty simple. Then build on your application. For example, you might decide to build a DAO. Then you might build a Gateway." Kurt recommended Sean Corfield's blog (http://www.corfield.org) for many example applications that will help the beginner.

Kurt also suggested that ColdFusion developers consider learning a real OO language, like C# or Java. "It's something you'll get a lot of benefit out of, in terms of your understanding of CFCs and objects inside ColdFusion. It will also make you more employable." He said that his own background, which includes training in Java and C++, has helped him immensely.

Going to conferences like cf.Objective() is also a great way to broaden your skills, Kurt said. "Cf.Objective() is really great because it's getting at a lot of those topics that CF people need to know more. It will help you produce better applications."

You can find out more about Kurt's presentation, and about the rest of cf.Objective(), by visiting the conference website at http://www.cfobjective.com.
Judith Dinowitz is Editor-in-Chief of Fusion Authority, the House of Fusion Technical Magazine. She is well-known as the CFEditor, having worked on many articles and books for other publications.

name's Gravatar
# Posted By name | 29-Sep-08 10:30 PM
Add a Comment
(If you subscribe, any new posts to this thread will be sent to your email address.)
  
Privacy | FAQ | Site Map | About | Guidelines | Contact | Advertising | What is ColdFusion?
House of Fusion | ColdFusion Jobs | Blog of Fusion | AHP Hosting