Hi Steve,
I'm not sure if the WebORB/.NET code generation will be doing anything more than generating the PureMVC client side code.
But that question '
what does puremvc look like on the server side' is yet to be answered by a demo. Server platfom possibilities so far are Java, C#, PHP, (Python and ColdFusion are still being worked on, and I'm not sure how far along they are at the moment). But beyond porting, no one has made the leap to doing a server side demo yet.
It's really exciting, though, because there are so many things that can be done with it. An RIA app with a PureMVC SOA implementation might still do a plain old webapp ala Struts for administration, which would make things much easier, while still reusing much of the code in the Model region. Its just that the view region would be processing HTML templates instead of building soap responses.
Since you asked, I went ahead and added you to the Port to C# group. This is something we all have to figure out together. And the sooner people are noodling on sever-side mapping of these patterns the better. You'll find a few new forums on your list when you're logged in. If you want to get in touch with Matt Brailsford, he can get you everything you need to get started with it.
Essentially, my thinking is:
* The Facade is the front door to the system. Think about the way that (on the client) we usually have a startup method that is called from the app view hierarchy when its built, triggering a single 'StartupCommand'. On the server we would have the same kind of method, only we'd pass in the constant for the Command to run along with the parameter that becomes the notification body. For instance, we might make an RPC call like:
serviceFacade.invoke(ADD_USER, userVO) * The Controller Region is the same. Commands work on either side in the same way.
* The Model region is probably having the Proxy talking to (or sharing some of the responsibilities of a ValueObjectAssembler since it is similar). The Assembler or Proxy talk to a DAO (which has all the SQL slinging), and that DAO talking to the database. This is server side mirror of a Proxy having an http service and talking to it directly, or pushing that http service into a Business Delegate if multiple Proxies need to talk to the same service.
* The View region (from the perspective of a server side PureMVC app) is either a template/filter or logic for transforming model data into representations to send to the client. More than likely there is a read-only relationship between View and Model on the server, following the MVC2 approach taken by Struts 2: (see the attached diagram, and for more info see
http://www.ibm.com/developerworks/library/j-struts/)
By the way, and this is just an aside from here; this server side MVC2 pattern is the genesis of much of the '
View should only read the Model' talk that some folks have posited as being a bad collaboration in PureMVC.
If you see the attached diagram (from the Struts page) you can see that it makes perfect sense from the server perspective, because the Client must be sent a representation to render, (by the JSP) which leads to user interaction at the client followed by another request from the client. If the Model is to be written to, clearly the request side of the loop is the time for that. Its a matter of practicality. Writing to the Model from an outgoing JSP would be hard and silly.
However, inside of the client, the View has no other job in life than to represent the Model and allow the user to manipulate it. Once you've forged a collaboration between a View region object and a Model region object, (a Mediator and a Proxy), then to simply eschew use of some public methods on the Proxy and only use the read only ones, you find yourself writing extra Commands and sending of notifications to trigger them just to make a single method invocation with a piece of data you already had in hand. This rarely makes sense unless the same action needs to happen from multiple places within the view, in which case the DRY principle pushes it toward a Command. Or if the Command is going to do more than just call a method, at sometime that becomes 'Business logic' and over complicates the mediator, again pushing it toward a Command.
-=Cliff>