Second Generation Micro-architectures

One of the primary reasons we have microarchitectures and design patterns in the first place is to maximize simplicity in application code. The problem is that not every architect understands this. Often we find architectures and design patterns being used in ways that do nothing more than increase complexity, which is counter-intuitive. This is why it is important to understand the framework that you are working with before you begin development on a production project that uses it, and Swiz is no exception.

A common characteristic among second-generation micro-architectures is that they are built to empower the developer, rather than over-power. One thing that all of these second-generation microarchitectures have in common, is that they use some form of Inversion of Control (IoC) and Dependency Injection, as defined by the great Martin Fowler in his book Patterns of Enterprise Application Architecture (Addison Wesley, 2002). With that in mind, you will first learn a bit about how these design patterns work from a conceptual standpoint before you get your hands dirty.

A Quick Background on Inversion of Control & Dependency Injection

Generally speaking, a good microarchitecture should allow the developer to decide how to implement an effective model based on the unique characteristics of the application. As previously stated, it should never force the developer into a specific model implementation. The Flex Framework is largely based on principles of Inversion of Control (IoC). In fact, this is true for most event-driven user interface development toolkits and frameworks such as Java Spring, EJB 3, Spring.NET, the ColdSpring framework for Coldfusion, Needle for Ruby, and FLOW3 for PHP 5.

The Inversion of Control pattern originally comes from another pattern described in a very important book published in 1995 that is often referred to as the “gang of four” or “gof” book, titled Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley). If you do not have this book already, I strongly suggest you add it to your collection as it considered a staple by every good developer I have ever met. One of the 22 design patterns described in this book is the Factory Method Design Pattern. IoC is a derivative of this pattern.

Why does ActionScript works well with IoC?

As you have learned, the ActionScript language is an object-oriented language in which objects are instantiated by declaring new instances, like so:

private var thisObject:ThisObject = new ThisObject(params...);

In contrast, IoC instantiates and registers a specific set of pre-defined objects at runtime, and injects them into each other using a concept known as Dependency Injection. By injecting these dependencies at runtime, the dependencies can be quickly and easily modified because the objects remain loosely coupled. The objects are loosely coupled because their dependencies are not “hard-coded” into the classes. This makes managing large code bases much easier.

Objects and object properties can then be wired up through binding. That means that all of your views and components can have what they need before anything ever even shows up on the stage!
With other implementations like Java Spring, an application’s objects and implementations can be declared in an XML document.  However, this particular method is not possible with Flex due to the order of operations that happen at application startup. More specifically, an application is not ready to parse an XML document until after it’s objects have already been instantiated.

Coding Flex Applications with Swiz

Swiz caters specifically to enterprise level Flex development by providing a solid architectural foundation derived from proven enterprise application development patterns. This includes:

1. Minimizing dependencies to promote loose coupling
2. Inverting the flow of control
3. Dynamic mediation

Swiz meta data: Autowire

The Autowire tag is used for component wiring, while the Mediate tag is used for dynamic mediation of events during the bubbling phase of the event cycle. Placing the Autowire meta data above the property of an object tells Swiz that it should inject a specified property from another class into this property. This is written as follows:

[Autowire]
[Bindable]
public var mainViewPModel:MainViewPresentationModel;

In the example above, the MainViewPresentationModel class is injected at runtime by Swiz as a result of the Autowire tag being placed above it. It is also made bindable in this instance so it can be referenced from properties of MXML components. Let’s say you have a Boolean property in MainViewPresentationModel called calendarVisible. Then, let’s say that when the application enters a certain state, calendarVisible gets set to true. (Note that calendarVisible should also be bindable in this case). In the MXML view that has the presentation model autowired into it, you could now state the following:

 <components:CustomCalendar id="calendar" visible="{mainViewPModel.calendarVisible}" />

Ok, so what’s so special about that? Well, now let’s say you have an event called mainStateChanged, which is mediated in the controller class (more on event mediating in a moment). When the event is fired, the controller that is mediating it picks it up during the bubbling phase, and initiates the setting of calendarVisible to true. Since we’re binding to that value in the visible property of the component, the calendar will immediately become visible! Ok, now that you’ve got that figured out, it’s time to learn about mediating events.

Using the Mediate Tag

The first and most important thing I should note in regard to using the Mediate tag, is that events should ONLY be mediated in controller classes. If you place Mediate tags all over the application, mediating events in the model and the view for example, your application will be seem just as much like spaghetti-code as it would if you used no framework at all. Remember that Swiz gives you much flexibility, but with that flexibility comes a responsibility to use best practices when writing your code.

If you are already familiar with the publish-subscribe design pattern, then understanding event mediation should come fairly easily. The following code demonstrates the use of the Mediate tag:

[Mediate( event="DataEvent.SHOW_DATATIP", properties="index,data" )]
public function showDataTip( index:int, data:ArrayCollection ):void {
   var itemData:String = data.getItemAtIndex(index).toString;
   var dataTip:DataTip = new DataTip(itemData);
   addChild(dataTip); }

In the example demonstrated above, Swiz will always be listening for the DataEvent.SHOW_DATATIP event during application runtime. When Swiz finds a Mediate tag, it binds the specified event to the method that appears on the next line. When the event is fired, Swiz automatically calls that method.

In order to declare events with the ClassName.CONSTANT syntax as it is in the example code, you must tell Swiz where your events are located using the eventPackages property of the SwizConfig object that you declared in your main application file. Otherwise, you will need to use the fully qualified path when specifying the event that should be mediated.

Possibly Related Posts:

• Using the Zend Framework to take some wind out of AIR
• Thinking Outside the IDE: Ideas for Flex Architects
• Micro-architectures for Flex Enterprise Development
• Understanding Flex Communication Protocols
• Enterprise Flex Model – v0.3

---

Posted by Dan Orlando on March 14th, 2010 :: Filed under Enterprise Flex
Tags :: microarchitecture, Swiz, Swiz framework

---

In the last entry on the Swiz framework architecture, we took a look into the use of the CentralDispatcher. More specifically, we looked at the middle section of the following architectural diagram that I designed to help Swiz make more sense for developers. In this entry, we will get into the upper portion of the diagram, the real meat of the framework – Autowire and Mediate.

In declarative languages such as ActionScript, an object is created by declaring it and assigning the instance of that object to a variable using the new keyword. This has proven to be problematic in larger applications because of it’s “top-down” approach to object instantiation, which results in “tight coupling” (dependencies between otherwise independent objects) among other things.

In contrast, the Inversion of Control pattern used by Swiz reverses this object instantiation process by creating and implementing objects at application runtime. This eliminates dependencies and increases loose coupling because the implementation is created dynamically, as you are about to see.

The Swiz framework solves this problem rather inventively, through the use of two primary facets: the Swiz BeanLoader object and custom meta data tags. The Autowire tag is used for component wiring, while the Mediate tag is used for dynamic mediation of events during the bubbling phase of the event life cycle. These meta data tags are added to the framework simply by adding the following to the compiler settings in the Flex project properties panel:

-keep-as3-metadata +=Autowire,Mediate

Promote Loose Coupling with Autowire

Placing the Autowire meta data above the property of an object tells Swiz that it should inject a specified property from another class into this property, as seen in Listing 1.

Code Listing 1. Using the Autowire meta data tag

[Autowire( bean="displayRoot", property="currentView", twoWay="true" )]
[Bindable]
public var currentView:String;

You may have noticed three additional properties that immediately follow the Autowire declaration: bean, property, and twoWay. A bean represents an object that has been declared within a Swiz BeanLoader object; which brings us to…

The Swiz BeanLoader Object

Swiz does a superb job of separating the view from business logic. The concept of Beans and BeanLoaders are well known in Java GUI development circles, but have never been used before in application development for the Flash Platform. The result is a noticeable improvement in code organization, as well as the realization of a simple and clearly defined application life cycle.

A Swiz BeanLoader is an MXML file that acts similar to an object registry. When you create a bean loader, you’re extending the Swiz BeanLoader class, which registers the objects that you want Swiz to manage, as seen in Code Listing 2.

Code Listing 2. Example of a Swiz BeanLoader

 <?xml version="1.0" encoding="utf-8"?>
<BeanLoader xmlns="org.swizframework.util.*" xmlns:view="com.danorlando.view.*">
 <view:DisplayRoot id="displayRoot"/>
 <view:StatsView id="statsView"/>
 <view:VideoView id="videoView"/>
</BeanLoader>

The property value that is declared after the Autowire meta data pertains to the currentView variable in the displayRoot bean. Since the currentView property in code listing 1 and the respective currentView property that is found in the displayRoot bean are both marked accordingly, Swiz will create a binding between them to ensure that changes that occur to currentView in DisplayRoot are also propogated to the currentView property found in the component that holds the code found in listing 1 above. If that seemed like a lot to swallow, go through it a few times, this time taking it in bite-size chunks. This is one of the most important parts of Swiz, and has allowed me to do things with Flex and ActionScript that would otherwise be impossible.

The last property that is available with the Autowire meta data, called twoWay, is capable of setting up a reverse propagation in the other direction when set to true. In other words, the currentView property in the displayRoot bean will be updated if the currentView property in the component changes.

Save Time and Eliminate Repetitive Code with Dynamic Mediation

If you are already familiar with what a publish-subscribe design pattern is, then understanding dynamic mediation should be a piece of cake. To initialize dynamic mediation, the second Swiz meta data is used, called Mediate. Code listing 3 demonstrates the use of the Mediate meta data key word.

Listing 3. Using dynamic mediation in Swiz with the Mediate meta data key word

[Mediate( event="DataEvent.SHOW_DATATIP", properties="index,data" )]
public function showDataTip( index:int, data:ArrayCollection ):void {
   var itemData:String = data.getItemAtIndex(index).toString;
   var dataTip:DataTip = new DataTip(itemData);
   addChild(dataTip);
}

In the example demonstrated in listing 3, Swiz is always listening for the DataEvent.SHOW_DATATIP event. This happens by binding the event to the method with Mediate. When the event is fired, Swiz automatically runs the method. It is noteworthy to point out however, that in order to declare the event class and type as shown in code listing 3, the respective package containing the event must be registered in the eventPackages configuration setting where <SwizConfig /> is declared in the main application file.

The greatest benefit of dynamic mediation is essentially the same as that which is gained from dependency injection and Autowire meta data. Objects do not have to have any knowledge about each other or the application for which they reside. Not only does this make unit testing ridiculously easy for the application, it takes the concept of “code reuse” to a whole new level.

To see the implementation of Swiz into an actual application, check out Ben Clinkinbeard’s post HERE.

Possibly Related Posts:

• Flash Camp Phoenix a Huge Success
• Best Drunk on Software Episode Ever
• “Flex 4 in Action” (Early Access Edition) Now Available!
• Designing (RED)Wire, Part 3: Advanced Styling Methods for Enhanced User Experience with Adobe Flex and AIR
• A Real-World Perspective into the Life of a Consultant

---

Posted by Dan Orlando on August 24th, 2009 :: Filed under General
Tags :: Enterprise Flex, Swiz, Swiz framework

---

In this segment, we will analyze how Swiz handles events, and how to utilize this feature of Swiz in an enterprise level application. Before moving any further however, here is the “more advanced version” of the Swiz architectural diagram I created for Linux magazine once again:

In the diagram, the Bean Factory represents a pool of MXML Beans that extend the Swiz BeanLoader class. As stated in Part 1 of this series, the purpose of Beans is simply to declare objects that will be used in the application and to assign IDs to them so they can be referenced by name later when they are autowired. The interesting thing about Swiz is that when it does its introspection on the BeanLoader, it instantiates all of the objects and creates a pool, or “factory”, where the objects are handed over on demand. For larger applications, this could potentially result in a very slightly extended load time, but the benefit is immeasurable because the result is that the application runs noticeably smoother and considerably faster.

In order to simulate a somewhat larger-scale application, the diagram displays four beans, which have only been separated as a matter of convenience. In essence, beans hold a strong resemblance to object registries, especially when you consider that you are essentially registering the objects declared in the beans to be managed by Swiz.

Swiz includes a class called the CentralDispatcher, which can be accessed directly through the Swiz.as class. The CentralDispatcher extends the Flex EventDispatcher and implements a Singleton pattern. I refer to this class as the “Event Bus” because it is a centralized place in which all events can be fired from.  This makes things nice and easy for managing the code base. Consider the following example:

1. In the main application MXML file, set an event handler on the applicationComplete event of <mx:Application/>, like so:

   applicationComplete="applicationCompleteHandler(event)"

2. Place the following code in the event handler function:

   protected function applicationCompleteHandler(event:FlexEvent):void {
        var del:XMLParserUtil = new XMLParserUtil();
        uiController.delegate = del;
        Swiz.addEventListener(DataReadyEvent.CORE_READY, setDataProviders);
   }

3. Create a controller class that extends the Swiz AbstractController. Here is an example:

   package com.danorlando.controller
   {
      import com.danorlando.controller.events.DataReadyEvent;
      import com.danorlando.model.Globals;
      import com.danorlando.model.MediaObject;
      import com.danorlando.model.ViewStackDataCollectionObject;
      import com.danorlando.util.XMLFactory;
      import com.danorlando.util.XMLParserUtil;
      import mx.collections.ArrayCollection;
      import org.swizframework.Swiz;
      import org.swizframework.controller.AbstractController;
   
      public class UIController extends AbstractController
      {
         public static const GLOBAL_SETTINGS:String = "config/globals.xml";
   
         private var _mediaDP1:ArrayCollection = new ArrayCollection();
         private var _mediaDP2:ArrayCollection = new ArrayCollection();
         private var _mediaDP3:ArrayCollection = new ArrayCollection();
         private var _globals:Globals;
         private var _delegate:XMLParserUtil;
   
         //getters
         public function get mediaDP1():ArrayCollection { return _mediaDP1 }
         public function get mediaDP2():ArrayCollection { return _mediaDP2 }
         public function get mediaDP3():ArrayCollection { return _mediaDP3 }
         public function get delegate():XMLParserUtil { return _delegate }
         public function get globals():Globals { return _globals }
   
         //setters
         public function set mediaDP1(ac:ArrayCollection):void { _mediaDP1 = ac }
         public function set mediaDP2(ac:ArrayCollection):void { _mediaDP2 = ac }
         public function set mediaDP3(ac:ArrayCollection):void { _mediaDP3 = ac } 
   
         [Autowire]
         public function set delegate(del:XMLParserUtil):void {
            _delegate = del
            XMLFactory.parseXML(GLOBAL_SETTINGS, _delegate.parseGlobalSettingsXML);
     // listening to the Swiz event bus for GLOBALS_READY, which informs the controller
            // that the global config file has been parsed and loaded...
            Swiz.addEventListener(DataReadyEvent.GLOBALS_READY, initGlobals);
         }
   
         public function UIController()
         {
            _globals = Globals.getInstance();
         }
   
         protected function initGlobals(event:DataReadyEvent):void {
            var dbpath:String = _globals.mediaDatabasePath + _globals.mediaDatabaseFile;
            XMLFactory.parseXML(dbpath, _delegate.parseMediaDatabaseXML);
            // listening for DATA_READY, which will be fired when the media database has been loaded
            Swiz.addEventListener(DataReadyEvent.DATA_READY, delegateData);
         }
   
         protected function delegateData(event:DataReadyEvent):void {
            if (event.collection == null) {
               throw new Error("NO MEDIA COLLECTION!"); return;
            }
            var data:ArrayCollection = event.collection;
            for each(var o:Object in data) {
            var obj:ViewStackDataCollectionObject = o as ViewStackDataCollectionObject;
            var name:String = obj.name;
            var coll:ArrayCollection = obj.collection;
            if (name == "Video Production") {
               for each(var ob1:Object in coll) {
                  var mo1:MediaObject = ob1 as MediaObject;
                  _mediaDP1.addItem(mo1);
               }
            }
            else if (name == "Video Art") {
               for each(var ob2:Object in coll) {
                  var mo2:MediaObject = ob2 as MediaObject;
                  _mediaDP2.addItem(mo2);
               }
            }
            else if (name == "Music Production") {
               for each(var ob3:Object in coll) {
                  var mo3:MediaObject = ob3 as MediaObject;
                  _mediaDP3.addItem(mo3);
               }
            }
         }
         // the main application class is listening for CORE_READY, which essentially
         // lets the application know that the data has been loaded and is ready to
         // be used. Again, the Swiz event bus is used as a way of keeping things
         // tidy and under control by ensuring that events aren't firing all over the place.
         Swiz.dispatchEvent(new DataReadyEvent(DataReadyEvent.CORE_READY));
       }
     }
   }

4. The final piece of the equation is the XMLParserUtil, which fires two events through the Swiz event bus, GLOBALS_READY and DATA_READY, as seen in the following code:

   package com.danorlando.util
   {
      import com.danorlando.controller.events.DataReadyEvent;
      import com.danorlando.model.Globals;
      import com.danorlando.model.MediaObject;
      import com.danorlando.model.ViewStackDataCollectionObject;
      import mx.collections.ArrayCollection;
      import mx.core.IUIComponent;
      import org.swizframework.Swiz;
   
      public class XMLParserUtil
      {
         public function XMLParserUtil() { }
   
         public function parseGlobalSettingsXML(xml:XML):void {
            var globals:Globals = Globals.getInstance();
            globals.mediaDatabasePath = xml.mediaDatabasePath;
            globals.mediaDatabaseFile = xml.mediaDatabaseFile;
            globals.mediaBaseUrl = xml.mediaBaseUrl;
            globals.contentPath = xml.contentPath;
            globals.thumbsPath = xml.thumbsPath;
           // firing the event through Swiz to let the controller know that
            // the global configuration info is ready
            Swiz.dispatchEvent(new DataReadyEvent(DataReadyEvent.GLOBALS_READY));
         }
   
         public function parseMediaDatabaseXML( db:XML ):void {
            var mediaCollection:ArrayCollection = new ArrayCollection();
            for each(var x:XML in db..view) {
               var collObj:ViewStackDataCollectionObject = new ViewStackDataCollectionObject();
               collObj.id = x..@id;
               collObj.name = x..@name;
   	    for(var i:Number = 0 ; i < x.children().length(); i++) {
                  var obj:MediaObject = new MediaObject()
                  obj.type = x..mimetype[i];
                  obj.file = x..file[i];
                  obj.thumb = x..thumb[i];
                  obj.title = x..title[i];
                  obj.description = x..description[i];
                  obj.credits = x..credits[i];
                  collObj.collection.addItem( obj );
               }
              mediaCollection.addItem(collObj);
            }
          // creating a DATA_READY event and firing it through the Swiz event bus;
            // the data collection is sent along with the event when it is dispatched.
            var evt:DataReadyEvent = new DataReadyEvent(DataReadyEvent.DATA_READY);
            evt.collection = mediaCollection;
            Swiz.dispatchEvent(evt);
         }
      }
   }

The important thing here is to pay attention to the event flow between the main application file, the controller class, and the business delegate. The advantage of structuring it like this is that by centralizing the event flow, you maintain a higher level of control over what is happening and when it happens within the application. It also keeps things a lot tidier, which becomes more noticeable as the application grows.

Stay tuned for the final part to my series on the Swiz framework, where we’ll discuss the best part of the framework – autowiring.

Additionally, my article on Swiz should be published shortly by Linux magazine, in which case I will post that link here as well.

Possibly Related Posts:

• Flash Camp Phoenix a Huge Success
• Best Drunk on Software Episode Ever
• Enterprise Flex and the Swiz Framework Architecture, Part 3: Using Autowire and Mediate
• “Flex 4 in Action” (Early Access Edition) Now Available!
• Designing (RED)Wire, Part 3: Advanced Styling Methods for Enhanced User Experience with Adobe Flex and AIR

---

Posted by Dan Orlando on May 16th, 2009 :: Filed under General
Tags :: Enterprise Flex, Swiz, Swiz framework

---

I’ve spent an incredible amount of time recently working with the new Swiz framework for my latest article, which will be published soon by Linux Magazine.  Since Swiz is so new, and in consideration of the fact that very few developers even know what it is, the article was more of an “introduction to Swiz” type of article. However, as a result of the immense amount of time that I’ve spent analyzing the code and speaking with the developers, Chris Scott and Soenke Rohde, I decided to provide a more advanced architectural analysis of the framework here. If you are new to Swiz, my suggestion is to first read the introductory materials that are provided, or this article might make your head spin. I do not expect Linux to publish the article I wrote for them for at least another week, so if you need a basic introduction to the Swiz framework, I suggest taking a look at the project’s wiki on Google Code. For an excellent tutorial on creating a project with the Swiz framework, I strongly suggest taking a look at this five-part series written by Brian Koteck.

Swiz Architecture

I wanted to create a diagram to support the content of the article I was writing for Linux Magazine. However, what I ended up with was much more complex than I had intended. As a result, I created a simplified diagram for the article as a way of visualizing the application life cycle, and decided to post my original diagram here, which provides a visual depiction of both the behavior of Swiz, as well as its architecture. The diagram is shown in Figure 1. Note that you may click on the image to bring up a much larger version in another window. Viewing it that way may make it easier to comprehend as your read the following description.

Go with the Flow

The main application file is identified by the purple shape in the diagram with the text “Default Application”. In most Flex applications, this is usually an MXML file that extends Application or WindowedApplication. Note that projects that are purely ActionScript will not be able to take complete advantage of the features of the Flex framework. You will see why in just a bit. Swiz is fired up on the preinitialize event during application initialization, which initiates what I refer to in the diagram as the “Life Cycle Manager”.  Currently, the Swiz.as class in the framework acts as both the life cycle manager and what I refer to as the “Event Bus” in the diagram. However, this will change soon, where Swiz.as will be used for global variables. The loadBeans method is what starts up the Swiz “introspection engine”, so the Life Cycle Manager can be identified by the class that the loadBeans method is called on. My guess is that this method will not move from Swiz.as, and if it does move to a separate “LifecycleManager” class, the method will still be accessible from Swiz.as.

See, the core methodology of Swiz is to maximize simplicity, and that is why we have microarchitectures and design patterns in the first place. The problem is that not every architect understands this. Often we find architectures and design patterns being used in ways that do nothing more than increase complexity, which is totally counter-intuitive. Initializing Swiz simply by calling Swiz.loadBeans is incredibly simple. That is why I suspect that even if the method is moved to a full-blown LifeCycleManager class, you will still be able to initialize Swiz by simply calling Swiz.loadBeans.

What is a Bean?

Beans in Swiz are MXML files that extend the Swiz BeanLoader class. Within the BeanLoader tags, you have a series of object declarations. Figure 2 demonstrates what this might look like for a delegates bean.

 <?xml version="1.0" encoding="utf-8"?>
<BeanLoader xmlns="org.swizframework.util.*" xmlns:del="com.danorlando.delegates.*">
   <del:UserCrudDelegate id="userCrudDelegate"/>
   <del:StatsCrudDelegate id="statsCrudDelegate"/>
   <del:VideoCrudDelegate id="videoCrudDelegate"/>
</BeanLoader>

Figure 2: In this hypothetical example, the delegates for basic CRUD operations on users, stats, and videos are registered in a file called DelegatesBean.mxml.

The Introspection Engine

Now that you have seen what a sample bean looks like, its easier to understand that when the introspection engine runs, it looks at all objects that have been registered within BeanLoader classes and the BeanFactory creates and holds instances of the objects to be wired up next. In the Figure 1 diagram, I am showing a hypthetical example where four BeanLoaders have been iterated and pooled in the BeanFactory in four categories: Services, Components, Data Model, and Commands.

In the next installment, we will go in depth in the upper half of the diagram and discuss autowiring and the Event model.

Possibly Related Posts:

• Flash Camp Phoenix a Huge Success
• Best Drunk on Software Episode Ever
• Enterprise Flex and the Swiz Framework Architecture, Part 3: Using Autowire and Mediate
• “Flex 4 in Action” (Early Access Edition) Now Available!
• Designing (RED)Wire, Part 3: Advanced Styling Methods for Enhanced User Experience with Adobe Flex and AIR

---

Posted by Dan Orlando on May 1st, 2009 :: Filed under General
Tags :: Enterprise Flex, Swiz

---

It has been four years since Adobe Flex 1.0 was released. Since then, many API’s, libraries, and frameworks have been released, most of which have been open source.  There is one key facet that is central to the evolution of any programming language, and when it comes to Adobe Flex, this important element required for mass adoption of the framework has been severely neglected; architectural frameworks for the enterprise. See, in order for a programming language to receive mass adoption, it must be capable of supporting enterprise grade applications, which by their very nature, often consist of millions of lines of code. For 4 years, enterprise Flex and AIR developers had only two choices of microarchitecture: Cairngorm and PureMVC; both of which fell far short of being viable solutions for the enterprise. It is for this reason that despite extensive efforts, Adobe has struggled – and in many cases failed – to effectively inject Flex into the enterprise space. The common response from enterprise executives has been that it is “unproven technology”.

A technology is usually characterized as “unproven” when it lacks the ability to fulfill the unique needs of enterprise application development. There has been a lot of talk about the number of enterprise application projects that have recently failed miserably, costing the company a lot of company (and some companies to go under) as a result of not having the right tools to meet the needs of application development in the enterprise.

Recently, a brilliant man by the name of Chris Scott released a framework on Google Code, which he developed to solve this problem. He called his framework “Swiz”.  Not surprisingly, very few people are aware that this architectural framework even exists. This framework advances RIA development by escalating the viability of Flex in the enterprise ten-fold.  It does so by taking a different approach than the alternatives. Instead of force-fitting J2EE design patterns into the event-driven Flex framework, Swiz uses the Inversion of Control pattern, which put very simply: reverses the “wiring” of dependent objects within the application.

After listening to podcast interviews and reading through Chris’ blog, he is clearly thinking along the same lines as a lot of us right now who have been unhappy with the set of choices available for Flex micro-architecture frameworks. It was refreshing to find Swiz, as I had taken on the endeavor of constructing my own micro-architecture which coincidentally modeled Swiz very closely. And yet, Swiz is a whole lot farther along than I was. What is amazing to me is how this just sort of popped up out of nowhere. I consider this a major advancement in Flex and AIR enterprise development.

Additional Information

The framework is open source on Google code here:
http://code.google.com/p/swizframework/

Additionally, a very useful article on Swiz was published on InsideRIA here:
http://www.insideria.com/2008/12/frameworkquest-2008-part-4-ioc.html

Chris’ blog can be found here:
http://cdscott.blogspot.com/

A podcast interview with Chris explaining the underlying concepts and why he created Swiz:
http://www.theflexshow.com/blog/index.cfm/2008/6/19/The-Flex-Show–Episode-45-Interview-with-Chris-Scott-talking-about-the-Swiz-Framework

Possibly Related Posts:

• Flash Camp Phoenix a Huge Success
• Best Drunk on Software Episode Ever
• Enterprise Flex and the Swiz Framework Architecture, Part 3: Using Autowire and Mediate
• “Flex 4 in Action” (Early Access Edition) Now Available!
• Designing (RED)Wire, Part 3: Advanced Styling Methods for Enhanced User Experience with Adobe Flex and AIR

---

Posted by Dan Orlando on April 27th, 2009 :: Filed under General
Tags :: Enterprise Flex, Enterprise RIA, frameworks, open source AS3, Swiz

---