Flex/Flash Architectural Challenge (part 2)

In the previous part of this challenge, I was asking the question of whether model/view separation was enough for most RIAs, or whether MVC was required. As a concrete exercise, I thought it would be good to imagine building a specific small app, so I picked Ta-da List.

I took some time to sketch out what I think a model/view version of this app might look like in Flex pseudocode. How would an MVC version be structured differently?



<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml" xmlns="*" initialize="onInitialize()">
	<mx:Script source="ListApp.as" />
	<mx:HDividedBox width="100%" height="100%">
		<mx:Panel title="My Lists" width="200" height="100%">
			<mx:List id="listOfListsView" width="100%" height="100%" dataProvider="{listOfLists}" cellrenderer="ListOfListsRenderer" change="onSelectedListChanged()" />
				<mx:Button label="new list" click="onNewList()" />
		<mx:Panel title="{selectedList.title}" width="100%" height="100%">
			<TodoListView id="todoListView" width="100%" height="100%" dataProvider="{selectedList}" />
				<mx:Button label="add item" click="onAddItem()" />
				<mx:Button label="edit"     click="onEdit()"    />
				<mx:Button label="share"    click="onShare()"   />


// included from ListApp.mxml

// Magic session state variable which I will imagine is already populated.
var session : ListAppSession; 

var user : ListAppUser;
var listOfLists : ListOfLists;
var selectedList : TodoList;

function onInitialize()
	// Ask the static factory methods of ListAppUser and ListOfLists classes to fetch
	// data from the server and create instances of my client side representations.

	user = ListAppUser.getInstance(session.userId);
	listOfLists = ListOfLists.getInstance(user);
	// Once these get filled in, data binding will take care of view updates.

function onNewList()
	// When a new list is requested, pop up a dialog, and call the model to ask
	// it to add a new list.

	var dialog : NewListDialog = PopUpManager.createPopUp(this, NewListDialog);
	var handler = function() { 
		listOfLists.newList(dialog.fields.title, dialog.fields.description) 
	dialog.addEventListener("ok", handler);

function onSelectedListChanged()
	// Query the listOfLists object for the contents of the selected list.
	// Data binding ensures that the view is updated.

	selectedList = listOfLists.getItemAt( listOfListsView.selectedIndex );

function onAddItem()
	// Adding an item works differently than creating a new list, because the
	// TodoListView handles it. It already knows which list to add to, because
	// its data provider is data bound to selectedList.


function onEdit()
	// Similiarly, going into the "edit state" is handled by todoListView.

	todoListView.editable = true;

function onShare()
	// Sending email is handled by the todoList object, which ultimately sends a web service request.


5 Responses to “Flex/Flash Architectural Challenge (part 2)”

  1. Steven Webster

    Sho; just to play devil’s advocate for a while here. I don’t think the app you’re asking for here, is necessary of the complexity, scale, number of use-cases, number of developers, etc, that would necessary require the infrastructure of an MVC microarchitecture.

    We could discuss how we’d implement the above using an MVC microarchitecture (I’d happily discuss how to do this in Cairngorm) but it’d be an academic exercise in understanding the framework, not a justification of where the framework brings in significant benefits. There’d be a leap of faith in accepting how this would scale, but it’d be very easy to argue that we were “making the simple complex”.

    When I introduce MVC microarchitecture to development teams, I want to enable them to successfully build applications like online self-service banking applications, not todo lists.

    Appreciate your thoughts.

  2. Sho

    Well, I leave it to you. I understand that this is a small app, and that the design constraints may be different, but it would be hard for us to deconstruct a large app, so I was hoping it would still be illustrative. Perhaps not, from your response?

  3. Steven Webster

    Sho … I’m concerned first of all of advocating that microarchitecture is required for the building of such a trivial application. I’m concerned that we’ll draw fire for appearing to produce an overcomplicated solution to an application, and this will be taken at face-value as evidence that microarchitecture such as Cairngorm imposes unnecessary overhead.

    The Cairngorm Store application, as Romain discussed, is an exemplification I feel of how an MVC application with domain model objects can be reimplemented with Controllers, Commands, Business Delegate, Value Objects and ModelLocators.

    If I can find the time, I’m certainly willing to blog as to how we’d address implementing the todo application with Cairngorm, but if your metric of “best architecture” is fewest lines of code or fewest architectural tiers, then you win already.

    So what are the criteria for success here ?

  4. Sho

    Hi there Steven.

    For starters, I’m going to take you and Romain up on his excellent suggestion of looking at the work that you have already done to rework FlexStore using Cairngorm.

    Second, this is not really a competition or anything (t-shirt aside), and I don’t think it makes sense to come up with predefined metrics. Rather, the metrics are what you, I, and others individually want to express in terms of what we consider to be good architecture. This is just a different way of having the conversation.

    For example, if your point is that real world applications have complexities which are well served by having a controller layer and you can think of a way of illustrating that through this example, that would be great.

    If you need to make the scenario more complex to illustrate this, that would work as well. For example, in a real world list product, it might grow to let you move list items to other people, track percentage complete and dependencies between tasks, watch for database access collisions, or any number of other complexities. You could describe the more complex app, and sketch out how you would architect a portion of the application.

    In any case, I think we all agree that there is no definition of “best architecture”. I just thought it would be helpful to get concrete in order for us to talk about how different architectures get you different benefits.

  5. Zdravko


    I would like to encourage you to go ahead with this Ta-Da List.

    While it is a poor example in support of a need for an MVC implementation (Steven’s point) it is a good example of a simple MVC implementation (Sho’s point?) that would be educationally valuable to us numerous non-purists.

    When done, perhaps you can use it to illustrate the simplicity of adding another use case and through it the need for MVC itself.

Leave a Reply