MVCS Design implementation in Flex and/or Parsley

Here are varioius approaches to implement MVCS design using Flex and Parsley. MVCS - Model View Controller and Service. MVCS contains one more layer, called as Service. Service is used to contain business logic. It can be on client side or at server side, depending upon the application architecture. (Refer for MVC definition) 

Here we are defining MVCS from Flex and Parsley perspective.Following MVCS, there can be various kind of layers and interaction.

Layers and Flow of control

• View
• MXML and View Logic
• Interacts with Presentation Model for data
• May Interact with Commands for action implementation
• Presentation Model
• Contains data state for view, may contains data transfer object from Service
• May interact directly with services for data related operations
• Or can have interaction channel with Commands to have update for data 
• Injected in View as stateless object
• Commands
• Contains view logic to act upon various user action from UI
• Helps to break the UI logic in various objects which acts based on the action
• Interact with Services for data related operations or Business Logic
• May update the presentation model for data state
• Can act as singleton stateless objects and linked with event mechanism 
• Or view can have their reference as per architecture preference
• Service
• Contains business logic and data related operations
• Can be on server side and may be implemented in various language like PHP or Java etc
• Can be on client side in case of desktop application, can use assql like MySQL connector to interact with database
• Service Delegates generally injected in Commands or Presentation Model using DI

Now there are many interaction models between these four layers depending upon overall application architecture or architect preference. 

Few interaction Models

• First and simple most model
• View have instance of Presentation Model
• Presentation model contains reference of Service
• View interacts with Presentation Model for any action
• Presentation Model use Service reference for any business logic or data operation and update its data states accordingly
• View is bound to Presentation model for data update (both way binding)
• Second model
• View interact with commands for various actions
• Commands interact with service for data or business logic
• Command updates the presentation model 
• View gets updated as it is bound with Presentation model

First approach is simple. However second approach is having various variants, like 

• How view will interact with the commands? Will it be through direct references of Commands or through events?
• How will Command update the Presentation Model? Will it be through some shared states or command will be having direct reference of model?
• Will there be a shared Presentation Model, singleton injected using DI, which will be used by view and command both? However the problem is that if we will have more than one instances of the UI, then the data will be shared among these.

Probable implementation of various models with their pros and cons:

• Coupling of View and Command without Events, i.e. view has the direct reference of commands

1. Steps
   
   
   1. No Singleton or shared model among the views. Rather every view will be having its own model.
   2. Command will be view specific, i.e. view will be having direct reference of Command by creating a new instance of command or we can use parsley DI to inject a new instance of specific command in view.
   3. Now with every operation, view will call the command for the relevant operation with model as parameter.
   4. Command can have reference of Model.
   5. Command will use the model instance while interacting with services or while getting the result from service
   6. Command will update the model on result callback
   7. View will be refreshed.
2. Pros
   
   
   1. No shared model among the views. Now we have single model for views, which earlier were having same shared model even if having different data.
   2. Avoid the problem of shared model and now each view will be working separately with no data mixing issue.
   3. Simple in implementation.
   4. Simple in debugging.
   5. As events are not playing any significant role between view and command. View knows that they need to call command and command knows that they need to update view for operations, so there is actually not much abstraction required at this level. Required abstraction can be achieved using some marker or required interfaces and using DI of commands in View.
   6. Events are making the implementation and debugging bit difficult, and also creating problem in some scenarios like singleton model problem, one we are discussing here.
   7. Specifically events are required, if there are more than one listener and which can be increased with time and we need a high level of abstraction.
   8. Simple MVC implementation, followed by many platforms like Swing.
3. Cons
   
   
   1. We may not be using the parsley event model and dependency injection for command and view interaction.

• Data movement through Data Transfer Objects between View and Command using Events
  
  
  1. Steps
     
     1. No Singleton or shared model among the views. Rather every view will be having its own model.
     2. View will pass the data to Command in form of VO (Data Transfer Objects).
     3. Command will perform the database operation through the service by using these VO.
     4. On Successful result from Service, command will update the view by event and will pass the updated data VO with event.
     5. View will capture the event and update its local Presentation Model with the data.
     6. UI will be refreshed with new data.
  2. Pros
     
     1. No shared model among the views. Now we have single model for views, which earlier were having same shared model even if having different data.
     2. Avoid the problem of shared model and now each view will be working separately with no data mixing issue.
  3. Cons
  1. Issue is that command will fire a single type of event for the view, then if there are multiple view opened of same type, event will be passed to everyone. And we can not really specify and unique key or event selector for any view instance, when there are multiple instances of same view mxml.
  2. We can use Object Id to put the check in event handler, and some special handling for new objects, but that is something which is not very generic design approach.
  3. This approach may handle the known scenario for now, however can stuck in future with some other requirement, then we will be ending up to make some more specific provision as per requirements.
  
  
• View interacts with Commands using Events, however pass model as arguments for data update

1. Steps
1. View fire the event for any action by placing presentation model in event as argument property
2. Command is singleton and is listening for the events
3. Command capture the event
4. Command extract the model
5. There is a class which can act as Service Response Handler (Asynchronous Result call back handler for service) and can contain model instance. 
6. Command make an instance of this Service Response Handler by handing it the model instance and pass it to service call as asynchronous result handler
7. Service return the result sometime later in separate call
8. Service result handler capture the result in result call back method, perform the required view logic to update the data from result, and update the model instance. It will also call the relevant method on model for notification, if required.
2. Pros
1. We have all the components of MVCS at place. 
2. Commands have logic for view action and in modular form
3. Commands are coupled loosely with view through events
3. Cons
1. A new instance of result handler will be created for every request
2. A new layer of classes is introduced as result handlers 

These are various approaches to implement MVC or MVCS using Flex and Parsley, and probably there can be more approaches based on application architecture and architect preference. Here the simple most is the first approach i.e. where view has the direct references of Commands. And third approach is the best suited to Parsley and MVCS model. 

Any approach can be picked up based on the requirements, application size, or overall application architecture.

People who read this post also read :