Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: How will PureMVC ported C# effect backend-only developers?  (Read 11401 times)
justSteve
Courseware Beta
Sr. Member
***
Posts: 55


View Profile Email
« on: February 25, 2008, 08:30:02 »

WebORB from http://www.themidnightcoders.com/ is releasing a new version for .NET this week that includes PureMVC generation for .NET projects. That means some degree of code gen for Server-side to Flex stuff...it'll be interesting to see exactly how that works.

My question here is wondering what PureMVC for C# is going to look for those of use not producing browser pages. Is the definition of 'View' going to be broad enough to include SOAP or WDSL output?

thx
--steve...
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: February 25, 2008, 10:18:02 »

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>
« Last Edit: May 01, 2011, 11:53:59 by puremvc » Logged
justSteve
Courseware Beta
Sr. Member
***
Posts: 55


View Profile Email
« Reply #2 on: March 12, 2008, 06:51:15 »


I'm not sure if the WebORB/.NET code generation will be doing anything more than generating
the PureMVC client side code.



At this point (the way i understand it) there's only basic service connection code in the PureMVC idiom.  But the WDLM tool is producing some fairly verbose C# CRUD stubs. At risk of suggesting yet another code-branch, it might be worth thinking about targeting the newly released WebORB .net version (newly free-to-use as well) as a discrete port in the same manner as AS2 and Rails.

Seems to me that WebORB represents a really unique creature in the scheme of things by it's very 'MVC-ness'. It can process Object Models for both Flash client-side stuff and server-side code, be it Java, .NET, PHP, and so on  - allowing any of the supported backends platforms interact with Flash/AIR clients via AMF3 - in either direction via messaging no less.

I suspect PureMVC's current developer community is mostly Flash-based folks who have significant interplay with database-based applications - we have to integrate client-side Flash media with enterprise or mashed-up server-side stuff. WebORB's developer community even more so. The overlapping interests to a tighter integration seems possibly powerful.


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.
.
.
.

Have you had a chance to explore the new capabilities of IIS 7. The ability to create IIS extensions that are native at the server/os level with .net code should produce some interesting possibilities.

Logged
sulletf
Newbie
*
Posts: 3


View Profile Email
« Reply #3 on: May 04, 2011, 03:40:03 »

Hello,

when I started writting PureMVC Perl implementation, i used a bank use-case to validate my dev and quickly realised server-side version missed the ability (compared to client-side version) to have its Commands-Mediators-Proxies registrations changed between 2 user-requests.

In an AS3 PureMVC app, a user interaction can lead to a Command execution that will register/remove another Command for instance, making app business behaviour evolve depending on the way the client (the outer world) interacts with the app.

In a Perl (or PHP, Python, Ruby, ...) PureMVC app, 2 separate app invokations will rerun the PureMVC structure "from scratch", not allowing the registration/removal of Commands-Mediators-Proxies between the 2 runs.

In one sentence, server-side PureMVC lacks "business statefulness" compared to client-side PureMVC.

To give a simple example related to my bank experience, it would be convenient for a server-side app administrator to send a request saying "please stop SWIFT files integration until further notice". This request would unsubscribe SwiftFileCommand for the next app invokations.

FRED
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: May 06, 2011, 08:12:22 »

In one sentence, server-side PureMVC lacks "business statefulness" compared to client-side PureMVC.

That is only the case for a CGI application, which is invoked from scratch with each call to the server. However if your application is running as a daemon process listening on one or more ports, then of course it can be stateful. And with the StateMachine utility, massively so.

Consider a MultiCore PureMVC server-side app that isn't invoked each time, but is running as a service. Lets imagine this app is a massively multi-player online game app.

The main server app does things like authenticate, give the user a list of currently running games to join and, forking new game processes with the actual game app and tell the client what port it is listening on.

The game app is very stateful. It represents the world all the players are moving around in. So it's probably going to have the PureMVC StateMachine at the heart of it. And the players and NPCs may be represented as their own PureMVC cores with their own StateMachines.

The client app talks to the main server app, authenticates, gets a list of games, and the user starts or joins one. At that point the client receives the endpoint for the running app and connects to it. The game world is of course set to some default to begin but as users interact with it, taking things, blowing things up, etc, that stateful serverside world representation changes. It continues to run until all players have either disconnected or the game is over.

-=Cliff>
Logged
Pages: [1]
Print