| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45
Back To Interview list
In this CFUN-04 interview, Michael Smith speaks with Sean Corfield, who will be presenting on "Mach II at Macromedia" at CFUN.
Michael Smith: Sean, What exactly is Mach and why is it version 2?
Sean Corfield: It's actually called "Mach II" as in "Eye-Eye" and it's currently version 1.0.9. It's an object-oriented application framework based on the Model- View-Controller design pattern. The name seems to cause quite a bit of confusion so I'll try to explain it: "Mach" is meant to make people think of breaking the sound barrier - breaking out of the procedural mold and taking the step up to object-oriented programming; "II" is a reference to the event-based implicit invocation architecture on which the framework is based.
MS: Aha, that makes more sense. But what is invocation and why would I want to do it implicitly and not explicitly?
SC: Invocation is really just a fancy word for calling a function. The implicit vs. explicit argument is tricky. Implicit invocation produces a lower coupling between components at the expense of a control flow that is slightly harder to follow. Fusebox is a good example of an explicit invocation system - you define exactly the steps that occur when a certain fuseaction request is received. Once those steps are complete -- in order -- the fuseaction has been completely processed. In Mach II, an event (request) may be partially processed and generate a number of subsequent events to be handled, or the flow of control might change based on input data to create a different set of events to be handled.
MS: That sounds like you can never tell what happens in a Mach II application?!
SC: Well, it certainly isn't as straightforward as reading a piece of procedural code from top to bottom! The big payback is that by breaking code down into small, independent pieces, you are more likely to be able to (a) reuse code in the future and (b) reorganize the application when requirements change. Note that I say *when*, not *if*. Requirements always change so we need to plan for that. Mach II helps protect you from such changes by supporting a very loosely coupled development style.
MS: Is Mach-II code hard to read? I have heard that XML is involved!
SC: Mach II applications are made up of three parts (in addition to the framework files): ColdFusion Components (.cfc files) containing all of the business logic, regular ColdFusion pages (.cfm files) containing all the HTML and (very simple) presentation logic and a single XML file that describes the structure and overall control flow of the application (mach-ii.xml). XML can be a bit daunting at first but really it's only a stricter version of HTML that requires you to nest and close tags properly. After all, we're fairly used to seeing this sort of thing:
<title>Web Page Title</title>
Web Page Content
That's valid XML and it's not hard to read. Mach II's configuration file uses XML to specify the elements of your application and how they communicate.
MS: You mentioned Model-Viewer-Controller as a design pattern earlier. Is that some kind of wall paper? What is MVC?
SC: The simplest way to think about MVC is as way of organizing your code into three piles: the Model contains all of your business logic and your database access (think act_* and qry_* files in Fusebox), the View contains all of the presentation code that generates your user interface (think dsp_* files in Fusebox) and the Controller contains the "glue" that holds the application together, processing requests, interacting with the Model to get data and the View to create the UI.
MS: Well that sounds a logical way to split up an application, but why is it called a design pattern? What does that mean?
SC: The term was coined originally by a bricks and mortar architect, Christopher Alexander, who recognized common solutions -- patterns -- to common problems in designing buildings and wrote prolifically on the subject. It passed into software engineering usage when the "Gang of Four" (Gamma, Helm, Johnson, Vlissides) published a catalog of "design patterns" - showing common solutions to common low-level problems that software developers encounter all the time while they're building applications. The idea is that, no matter what language you're using and no matter what your problem domain is, there are certain core problems that you have to solve and there are "best practice" ways to design your solution, depending on the context and constraints of the system you are building.
MS: So what is the problem that the MVC design pattern solves?
SC: The main problem that organizational patterns like MVC help solve is that of creating maintainable software systems. Without an organizational pattern, code can quickly deteriorate into a soup of business logic and presentation code all haphazardly mixed together. As more functionality is added, the application code quickly becomes complex and brittle and hard to maintain. MVC provides an organizational roadmap that helps ensure a clean separation between the presentation code, the business logic and the control logic that connects them.
MS: That sounds good for maintenance...
SC: It makes it easier to add functionality in a way that scales from a complexity point of view. Consider adding a new option to a page, perhaps to filter the data displayed on a page. The quick'n'dirty way would be to just hack the code on that page to add filtering into the display. If the client then decides they want the filtering options applied to another page, you have to duplicate all that logic into that page as well. Add a few more filtering options and that soon becomes a mess. With MVC, the filtering logic would be designed into the business logic that retrieves data; the presentation code simply displays the results it is given; the control logic passes the filtering options into the business logic. Each piece does its own job.
MS: So each piece does only one thing...
SC: Yes, the idea is that each piece is cohesive - it does just one job and does it well - and that coupling between the pieces is loose (e.g., the controller maps the button clicks and links from the views to method calls and arguments on the model so that the model is not tied to the view). The end result is a better structured application that is easier to maintain!
MS: Wow - I need to learn more about Mach-II and MVC - see you at your session.