Question in regards to MVC

[StevenHowell_XOM]

Ok so I have a large application I am developing that I have decided to implement an MVC into the design.

A launcher VI will launch the root actor (Controller.lvclass)

Controller Actor will search project hierarchy looking for Modules Actors to launch with name nomenclature of ***_Module.lvclass.

Controller launches _Module actors and builds a look up table of enqueuers and class names via variant attributes.

If I understand this correctly, then to send messages from Actor A to Actor B, then I have to send a msg from Actor A to the Controller X, which then calls a method on Controller X (which is embedded with another send message) to call method on Actor B. Controller X is the mediator and handles the message traffic.

I am trying to come up with a simpler way to do this so that I dont have to create 2 message classes for each method that I want to call on any one Actor. I wrote a simple Msg Method in the controller that its inputs are a Target Actor and a Method to Invoke (Message Class).

It ends up being a pain in the neck because now I have to create additional VIs in the sender class that encapsulates the data to send with the target class and method to invoke. It just seems like alot of VIs in the hierarchy, wondering if it could be "leaner"?

I know its taboo to "cross the tree" and send messages between actors directly so I dont really want to go that route, unless it is the only way.

My gut tells me I am missing something here and trying to reach out and pick your brains to see what it is.

Feedback? Suggestions? Much appreciated!

Steven

Sending Actor with Message Encapsulated

Do Method (Generic Msg Class)

Generic Message Method in Controller Class

Receiving Actor Method called from Actor A

[Jed394]

Others here might have some more specific input.  But since you are doing an MVC structure, i don't think you want shortcut the message chain.  The whole point is that the view really only knows about the controller and the controller handles all work on the model.  Are you module actors part of the view, subcomponents of the controller or part of the model? 

I would think that abstract messages are probably going to be the missing link you are looking for as far as implementing the actual code.  Have you looked into those yet for the actor framework? 

If your modules are "sub-components of the controller" then as long as you know what your doing, and any other developers you working with do to, then you might be able to get away with passing messages directly to one another.  For example sub-component of your controller is a "logger" then I see no issue sending messages directly to it instead of actor->controller->logger.  However, you wouldn't want to send messages from your VIEW (GUI) directly to the controllers logger.  In that instance you would want to send message to the controller and then to the logger.  And in this case, you might be stuck making those extra messages. 

It really becomes about how much abstraction you want between each actor. 

[AristosQueue (NI)]

You do not *have* to pass messages up to the controller and back down.

You do not *have* to create two messages for each message.

But I do encourage you to do so.

> I know its taboo to "cross the tree" and send messages between actors directly

> so I dont really want to go that route, unless it is the only way.

That's how you do it. It isn't taboo (a word meaning "something you will be shunned for doing"). It is something that is marked as "use with caution; avoid unless needed". You have to decide whether this is a time when you think it is appropriate to use that facility.

> It ends up being a pain in the neck because now I have to create additional VIs in the

> sender class that encapsulates the data to send with the target class and method

> to invoke. It just seems like alot of VIs in the hierarchy, wondering if it could be "leaner"?

Yes, it can be leaner. That leanness comes at a price -- a price that some people are more than willing to pay but I, personally, no longer am in most cases, particularly the kind of mass module plug-in system that you are describing.

If you simply share the enqueuers for the other actors with each other, they can message each other directly. You can create the fully connected network of listeners if you want. The price is the traceability of messages; it becomes significantly harder to assert the order that you expect modules to react to a given event. And you have a strong tendency to code dependencies in one module on what should be encapsulated details of one of the other modules, that may impede your future feature development.

Your call. There is no wrong or right here, just tradeoffs.

[drjdpowell]

Your “Mass Spectrometer:Send Empty Chamber Data” VI seems strange to me.   It is hard linked to your Datalog actor via both having an instance of that class and having a message class constant meant for that class.   BUT, getting the Enqueuer of the Datalog actor requires a lookup table!?!   Why do you not just have a “Raw Counts Message" and an “Enqueuer to send Raw Count messages to”?  In fact, I would make it an Array of Enqueuers, since it’s not the Mass Spectrometer’s responsibility to who (if anyone) the “Raw Count” information is directed.    Mass Spectrometers have data such as Raw Counts to make available; DataLoggers log data as instructed.  But the glue that connects the two should be the Caller or Manager of both.  Unlike AQ, I see no reason why the actual messages can’t be sent directly from Spectrometer to Logger, but the instigation of this message flow should be “up-tree”, in the Caller.

[dsavir]

I also move things through the controller. I agree that it's a pain, but I wanted things to be as decoupled as possible.

I implemented a general ASCII message called router_parser with strings {source, target, commandname, commandparameter}. If Target==me, then I parse the command and call the appropriate message to myself. Otherwise I route to the controller. That way the only module who needs to send me messages (other than router_parser) is myself.

I also implemented loosely coupled actors in the heirarchy - the abstract parent of all modules has a dynamic dispatch VI and message "Handle Notification". This way a module just needs to override "Handle Notification" to change its reaction without implementing its own message class.

Good luck!

Danielle

[StevenHowell_XOM]

Thank you everyone for the feedback and information. I like idea of having a centralized "controller" in my designs so that it is the Root Actor that is launched, and it then looks through the hierarchy for the modules and launches them and therefore is the "mediator" for message transfer between actors. Makes it easier to debug and follow the message traffic. It involves alot of message classes however when passing messages from caller actor to the target actor.

[AristosQueue (NI)]

StevenHowell_XOM wrote:

It involves alot of message classes however when passing messages from caller actor to the target actor.

This is a known pain point that I would someday like to remove, but all the ideas I've seen for doing so thus far either remove type safety by going to strings or variants OR require additions to the LabVIEW language itself. You're more than welcome to build a single message class that handles flattened strings or variants in order to avoid creating many messages. Research on language improvements proceeds as I get time to work on it.