I'll soon be a developer on a good-sized PureMVC project, so I thought it'd be good to...well...learn PureMVC.  I've diddled with its sample code and read its documentation, but largely avoided it in the past.  My brain works more in the lighter-weight Spring/POJO mindset of Swiz, so that's largely where I've stayed.  To get myself up to speed, I decided I'd port the EmployeeAdmin example PureMVC app to Swiz.  This'll give me a bit of a Rosetta stone for figuring out what goes where, and it looks to be one of the more discussed examples on the PureMVC forums.

Conclusion

Conclusion first?  Well, I didn't want you to have to read all of this if you didn't want to.

After factoring the same model code between a few different architectures, I don't really have a "Yes, use framework X!" opinion.  Swiz is more "my style," but it's like a chainsaw:  very effective at both getting the job done and causing a bloody mess.  PureMVC is wordier and more prescriptive, but this rigidity could help larger teams of more varied experience.  I don't like the amount of boilerplate and interfaces-for-interfaces-sake in PureMVC, but it's certainly an appropriate tradeoff for giving a development team a common language.

In my typical style of overreaching metaphors that'd make Dr. Phil proud, it's power tools vs. hand tools.  I can build the same thing with the same fundamental architecture with either, but a lot of the end choice has to do with workers and materials.

Basic Architecture

Swiz and PureMVC both provide Model View Controller implementations.  Swiz encourages you to write vanilla AS3 classes sprinkled with Swiz-specific annotations, using a dependency injection container (similar to Spring) to resolve dependencies.  PureMVC encourages implementation of its interfaces (except for on the view tier), using a central concrete Facade with which dependencies are registered.

Event Mechanisms

Both rely on application-level (non-UI hierarchy) events for communications between model, view, and controller, with PureMVC implementing its own Observer implementation and Swiz relying on native Flash events.  The idea of notifications (events outside of the UI hierarchy) is the foundation of both frameworks.

Opinion:  If I were to be locked in a dungeon to write software for the rest of my life and could take one design pattern with me, it'd be the Observer pattern, so any framework that makes multi-observer notifications a core concept is peachy with me.  That does eliminate Cairngorm, which I don't consider a great loss.

View and Controller Communications Differences

Compared to Swiz, PureMVC architectural style recommends a higher level of decoupling between controllers and views via Mediators, which act as a traditional view controller in collaboration with a view.  In PureMVC, a Mediator knows about a UI component, manipulating its state and listening for events and re-dispatching application-level notifications as needed.  It's important to note that this collaboration is one way:  the Mediator knows about the view, but not vice-versa.  The UI component itself knows nothing of PureMVC.  The direction of coupling is from the Controller ("Mediator") to the View.

Nothing prevents identical architecture in Swiz, but Swiz developers typically couple views directly to controllers, a more coupled but traditional MVC decision.  In Swiz, a view generally dispatches application-level notifications directly.  Instead of a mediator maintaining a reference to a view, a Swiz view generally maintains a reference to a controller, using its exposed properties to maintain its data via bindings.   In Swiz, the Controller isn't highly coupled to its View.  Instead, the direction of coupling is from the View to the Controller.

Opinion:  In the Web world, I've tended towards frameworks that use a Controller tier that is less coupled to the view (Model-Glue, Mach-ii, Fusebox) instead of vice-versa (Coldbox, anything ending in "rails").  This lets me have more re-usable controller logic rather than more portable view code, so I prefer the Swiz approach.  It lets me work the way I want, but doesn't block me from using PureMVC-style architecture if so desired.  I can't recall ever moving views between frameworks anytime other than porting examples.

Command Implementations

Many RIA developers use Command pattern implementations to define complex business logic or state changes.  A command, simply put, is a stateless script.  PureMVC provides for this by allowing a developer to map Commands to notification names.  When the notification is dispatched, all mapped commands are executed.  

Swiz does not provide a specific way to write concrete Command implementations, instead favoring mapping of Controller methods to notification names.

Opinion:  Not much of one, because I don't like most uses of the Command pattern.  I understand the temptation of commands (one file of source code can contain all logic for a use case), but I think that's also their flaw.  I think they're great if they're kept small, but that they usually wind up being a library of scripts that contain most of the application's logic -  all too often domain logic that belongs in the model to begin with.  

Model Differences

One of the first problems in RIAs addressed by frameworks is that of model location.  As soon as you've written a RIA that's more than a few components large, you've probably realized that passing all needed data down the UI hierarchy tree through tag attributes is a fairly lousy and brittle way to maintain state.  Both PureMVC and Swiz solve this more elegantly than the classic ModelLocator idea.

In PureMVC, a Proxy class provides methods by which Controller-level classes (Mediators and Commands) may access and manipulate model state.  These proxies generally maintain the reference to the model, and the proxy is interrogated for state when needed.  For examples, a Proxy holding Users may have a "proxy.users" property that is an ArrayCollection.  A mediator may then update the list of users in a view named "userList" via "userList.users = proxy.users".

Because of the switch in coupling direction in Swiz-style programming, this obviously changes.  Typically, a Swiz application's Controllers maintain a reference to model data.  Views may then bind to the controller directly.  (Remember, Swiz favors coupling view components to controllers.)

In both frameworks, the idea of a "delegate" can be implemented.  A delegate typically acts as a surrogate for accessing remote APIs, such as RemoteObjects or other Web services.  A delegate serves to hide this implementation from the rest (pun intended) of the application.  In PureMVC, Proxies can act as delegates by defining (or acquiring references to) RemoteObjects and manually using Flex's native Responder, result, and fault mechanics to execute calls against remote services.  Swiz, rooted in Java and ColdFusion-focused Flex development, allows you to speak to simple services directly from a Controller, provided helper functions to simplify handling success and failure conditions.  Further, it provides helper classes (MockResultEvent) to allow developers to more easily simulate the presence of a server in prototyping and unit testing situations - a feature unique to Swiz (to my knowledge).

Opinion:  I prefer KISS approaches when possible, so I prefer Swiz.  I just don't quite see the need to develop and register framework-specific singletons that contain my model data in addition to singleton controllers.  Instead, I'd rather just have controllers that contain the data directly.  I'll admit it's a tighter coupling, but in neither case does the model know squat about the controller or view tiers, so "pure" MVC is maintained.