Flex Article

Developing Flex RIAs with Cairngorm microarchitecture – Part 1: Introducing Cairngorm

Clarifying the Definition of Frameworks

In software development, framework is among the most overloaded and overused terms. When developers write large pieces of code that they consider significant enough to leverage on other projects, they tend to supplement the code with this term. Thus there are many types of frameworks: persistence frameworks, transaction frameworks, logging frameworks, aspect-oriented frameworks, animation frameworks, unit-testing frameworks, and so on.

Before we delve into the discussion of the Cairngorm framework, it's important to note an important distinction that the Adobe Consulting team shares with customers and partners—specifically the distinction between application frameworks and architectural frameworks.

Application Frameworks

Flex is an excellent example of an application framework. The Flex 3 Framework provides a rich collection of class libraries with highly granular functionality that developers can use to create custom code. For instance, the Flex 3 Collections API provides application developers with all the base-level functionality needed to create managed data collections. Application developers then assemble these collections into higher-level objects that are relevant to their particular application. Furthermore, application frameworks such as Flex typically expose application-level services, including history management, layout management, cursor management, exception handling, internationalization, logging, and other services.

When a framework features highly granular class libraries that provide a high degree of flexibility to application developers, or when a framework provides application-level services that are useful across multiple developer projects, we call it an "application framework."

Architectural Frameworks

Architectural frameworks are different beasts entirely. Typically, the job of an architectural framework is not to provide any additional services to application developers beyond an infrastructure around which an application can hang. Architectural frameworks provide the skeleton or internal structure of moving parts, around which the flesh and muscle particular to a business domain can be layered.

In other words, an architectural framework provides a generic starting point for the technical architecture of your application.

Applying design patterns

It is hard to talk about technical architecture without paying attention to an important movement in software engineering called design patterns.

While we won’t go into detail here about software design patterns, we will say that the expression "there is nothing new under the sun" is never more true than in the discipline of software engineering. Developers often find themselves addressing engineering problems that appear with regularity in application development. Almost as consistent as their appearance is the repetition of similar solutions for these problems. Wherever such problems occur, you can identify the solution as a "pattern," indicated by identifying the design challenge and finding the appropriate design solution.

The lure of design patterns

Now a warning: When software engineers first encounter design patterns, the realization that there exists a catalog of solutions to their engineering problems can be powerful. Often developers recognize a subset of problems they have encountered and then seek to understand other design patterns and where they might apply them. The old adage "when all you have is a hammer, everything looks like a nail" can apply here. You can often find "pattern overload" in an application, where developers abdicate responsibility for classes and collaborations and, instead shoehorn everything into a Factory, Flyweight, Observer, or Decorator design pattern.

Used appropriately, however, design patterns can be a powerful tool in a developer's toolbox. Design patterns not only offer common solutions to problems, but they can also indicate the intention of the implementation. For instance, whenever you see a Singleton design pattern in a code base, you understand that this is a class for which there should be only one instance. Likewise, whenever you come across a Factory pattern, you recognize that there are a number of different objects that a manufacturing class can construct.

Rising through the technical architecture—from the ground-level detailed implementation towards the helicopter view of high-level system design—you begin to appreciate the design in other, recurring ways. Like the Mandelbrot set, you begin to recognize higher order structure as your lower level structure collaborates. Thus design patterns begin to coalesce in repeatable ways, offering higher level solutions to higher level design problems.

Microarchitecture as a composition of design patterns

While a design pattern offers a specific solution to a specific problem (for example, using the Singleton pattern for the problem of ensuring that only one instance of a class ever exists), a collection of patterns that regularly collaborate with one other can be assembled for the greater good of a greater aim. For example, such collections of patterns can be used to provide answers to questions such as, "How do I intercept user gestures and ensure that a worker class assumes responsibility?" or "How do I centralize the business logic that might be used in more than one context on the client, even though it is actually implemented as a collection of service calls to a number of different types of services on a collection of servers?"

When you start to assemble collections of design patterns into higher order but nonetheless highly generic systems, you communicate them as "microarchitectures."

Let's take this high-level discussion of application frameworks, architectural frameworks, design patterns, and microarchitectures and put it into context. When the Adobe Consulting team speaks about the Cairngorm framework, we are speaking about an architectural framework—a starting point for technical architecture that is generic enough to apply in most cases to medium-to-complex Flex RIAs.

Furthermore, when we speak about the Cairngorm framework, we do not mean some monolithic architecture that limits your freedom as a developer to solve problems. Rather, when we advocate the Cairngorm framework, we mean the following:

• A lightweight, prescriptive framework for some of the challenges consistent with the Flex RIAs we have encountered
• Using a small number of relevant design patterns, where the moving whole is slightly greater than the sum of its static parts
• A microarchitecture for RIA development—a starting point for your technical architecture that solves the problems as they have been solved successfully before

Page 2 of 4

Previous Page

Next Page