while redesigning a large scale app from an old non LVOOP code I thought about the next design for a quick upgrade that will include Model-View-Control architecture with an alternative to FGs.
Besides using frameworks like Hardware Abstraction Layer (HAL/DSSP) and the UI Framework along patterns like Factory and Singleton to allow abstraction and feature changes to my system I wanted to add the same abstraction to my inner modules so that the vi loaded into the UI Framework, for example, will be MVC and be used as a father for future versions without using external FG that can't be LVOOP.
The solution that I thought of and I need feedback for (since I never heard of anyone using it) was using the class control as the db (model) for the vis while the front panel is the GUI (view) and the block diagrams are the logic.
I'll try and explain through an example:
The old code used controls on the front panel as the state of the system while the block diagram used the front panel both as a db of states (some hidden from the user) and as a GUI (which is actually also a DB most of the time).
I created a vi that went over all the controls of the front panel (recursively looked inside each control) and created a typedef that contains all the controls names and refs. I then added this typedef into the class control and added to that class control all the front panel controls.
The next step was to automatically add member access read and write to all the elements in my control.
The result was about 90 vis of member access with the same names as the name of the front panel controls (LV currently can't handle property nodes for controls with label that contains two lines so I had to fix the names first).
By changing the template of the member access I was able to add to all the write member access vis the ability to update the front panel and even to signal value change or add request to a queue depending on any rule that I decide on while using the typedef that I previously described.
Now, all I had to do is to take the old code and remove all the references mess in it and replace it with a class wire that is actually my db. Any action on the db/class is handled through a property node (I like to set the option to no name to save space).
The result is a MVC since the logic doesn't interact directly with the GUI and update it only on request. Each user action triggers an event so the logic will update the model in the class control.
In this way I don't need FG since my class is the db and each member access implementation can contain protections like Singleton.
Many tasks become trivial this way like saving/loading the status of the system for each user or even documenting/logging an error and even recording operations to use later as a test vector with metrics above it not to mention the fact that using G# for example I can expand my class to implement another API/db.
I could go on and write the logic using the class wire, however, I might want to use the db in multiple loops and thus I converted the class wire into a DVR wire.
Besides that, if I would like one day to upgrade the system I simply have to inherit from this class, the child will have access to the same db and could override the member access vis.
The problem I have now is that I'm not protected from race conditions on my db and I wonder if the class control is fast enough and what will be the implications. For example, if I access the class db from a parallel loop or from a reentrant sub vi or if I pass the class dvr as a parameter for another class control or both a child wire and a parent wire try to access the same data etc...
The regular approach from the LVOOP examples (cars/bike/truck) along with FG, Factory and so on is also ok but I find it both less robust and harder to use for a system upgrade since the time it will take you to redesign an old non LVOOP program, so it will contain all the new standards, is unacceptable (just defining the classes and the inheritance takes months) while in my way most of the work is automatic, I simply recycle old code to be more expandable and user friendly.
To sum it all, I love the idea yet I'm afraid to use something that was never tested before and thus, I need feedback from you guys.
P.S. - thank for reading
Edited by 0_o, 29 December 2011 - 02:11 PM.