Canoo's Web 2.0 Technology Blog on Java, AJAX and Flex

Rich Internet Applications pick up the ball where plain Web applications dropped it: they promise to bring the power of desktop applications to the Web. Desktop applications almost went out of fashion with the advent of Web applications. But most people still prefer the rich user interface (UI) and interactivity of desktop applications such as Outlook compared to their Web-based siblings such as GMail and Yahoo! Mail. In many cases the convenience of ubiquity compensates for the inferior or cumbersome user interface.

Client-server applications with rich user interfaces first emerged at the beginning of the nineties. Usually implemented in C++ or Smalltalk, they followed a fat-client approach, the predominant client-server architecture at this time. The principal way to organize the presentation layer of such applications was the MVC model. The concept was first proposed by Trygve Reenskaug (see http://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf) for the Smalltalk environment. As with any proven object-oriented design, MVC splits up the responsibilities of a user interface component into domain data (Model), rendering (View), and event handling (Controller). Quite often, view and controller are merged together, though.

Today’s GUI component libraries still make use of MVC. For example, most non-trivial UI components in Swing employ some sort of MVC. However, if one tries to apply MVC to complex (form-based) applications, which is typical for desktop or Rich Internet Applications, experience shows that criteria such as clean design, maintainability, or reusability cannot be met. There are several reasons:

1. What is the model of a form based application with a rich UI? Most developers point to the business object to be rendered in the form as the model. A form-based RIA has more model states than just the business object, though. This additional state is usually kept in the view class and increases the complexity of the view.
   
   
2. The presentation logic of a Rich Internet Application is vastly more complex compared to a traditional Web application. The presentation logic has to deal with more events caused by extended interactivity. Another feature of RIAs is an up-to-date rendering of the presentation state. For example, UI components may be enabled/disabled or visible/invisible depending on the state of the application. This is also part of the additional model state as mentioned above. On top of that, RIAs feature instant validation (without interrupting a user’s flow of work by throwing a modal dialog into their face). This “silent” validation has to be handled (at least partly) by the presentation logic as well. Naïve design puts all of these aspects into the view class. As a result, the view class becomes overly complex, hardly reusable, and difficult to maintain.
   
   
3. Automated testing of such view classes can only be accomplished by running the user interface. Tests are executed by triggering user events through a test tool or accessing the components through a library (e.g. Jemmy for Swing component library). This way of testing is slow and fragile: running hundreds or thousands of UI tests takes quite some time and changes to the user interface are likely to break the tests resulting in false negatives.

As a company specializing in RIA, we at Canoo have witnessed quite a few transitions from plain ugly Web applications to the brave new world of RIA. Some of our observations:

• Typical Web developers have not heard of MVC and try to design RIAs like they would design a typical HTML application.
  
  
• Seasoned developers who may have had some experience with fat client-server applications try to apply MVC concepts in the same way that they did in the nineties, without adapting to the new scenario.

Both approaches have their weaknesses and lead to poor results. In part two of this blog post series - “The world needs more models” - we will discuss possible remedies to this situation.