Implement the Model-View-Controller (MVC) architecture with AF

[Jonzarwal]

I lately took interest in the MVC architecture and the way to implement it in LV.

I found this tutorial : https://decibel.ni.com/content/docs/DOC-21531 which is very nice (and even a very great demo of use case of several OOP patterns for beginners).

So I was wondering, how would I do this with AF?

To me, the most obvious would be to use only one actor :

-> use its private data to hold the model

-> use the core to be the controller

-> Override the core to add an event loop (which is then the view) and provide a user event ref to allow the controller to message the event loop and refresh the UI elements

Mainly I have two questions on this:

1. Providing the UI elements references to the core to allow refreshes whithin the methods directly (w/o using UE) would be in contradiction with the MVC paradigm ? What would be the cons of such an implementation ?

2. Is there an interest to use 2 actors, one for the view only, and one for the model and the controller ?

[CaseyLamers1]

I use MVC extensively with AF.

I would recommend the following:

1. The Model, the View, and the Controller should all be separate actors (probably).

2. Think long and hard about what the interface is between each MVC piece. In AF this will be the messages.

3. Start simple and add complexity as needed. Get your head around things at your current ability level, challenge yourself, grow, get your head around things at the next level, repeat.

4. Have FUN!

Casey

[drjdpowell]

There was some MVC diuscussion here on LAVA, generated after I made a short youtube video about what I called the Controller-View-Model Principle.  Personally, I think the principle, of Controller affecting the Model, and Model updating the View, is more important with actor-oriented programing than having a formal MVC architecture. 

[jlokanis]

I also prefer to break it up into at least 2 actors.  Possibly more if needed.

The View actor does use events to communicate between it's FP and the View core.  But the core's job is to recieve messages from other actors containing data and to send messages containing info about actions the user takes.

For example:

User presses a button.

View event loop sends a message-to-self to the View core containing info the user action.

When the View core executes that message, it then messages other actors that need to know about the action the user took.  They do not need to know that it was a button that was pressed.  This allows you to map many UI elements to the same action.  (Button, RC menu, Application menu, etc).

Data is changed in the Model.

Model/Controller core reacts to the data change by sending a message to the View core.

The View core then proceses the data and formats it into a user event that is passed to the View's event loop.

The user event fires and updates the appropriate FP indicators (and sometimes controls).

I also recommend isolating communication outside your application (to hardware or across the network to other applications) to their own 'View' actors.

This design allow you to replace your View with a differrent UI with minimal recoding.  It also supports adding a scripting 'View' to replace the UI when you want to drive your application using automation instead of a GUI.

Another benefit of this is you do not need to create references for your FP objects in the View.  You only need to share the user events with the core so it can talk to the event loop.

One drawback of this design is your View actor may need a lot of messages to support all the actions the user can take.  But that is a general issue with Actor programming.