Data Value Reference - Is there any value to this methodology?

[DailyDose]

---

@Mark_Yedinak wrote:

Now for a more philosophical perspective, unless the subVIs or asynchronous tasks are strictly for working with the UI you should never pass references around that your lower level code uses to update to the UI.  All this does is create coupling between your code which makes reuse much more difficult. For example, some lower level code processes some data via some algorithm or transformation. The code doing this should ONLY do that. It should have no concept nor should it care with how that resulting data will be used. If it also updates some control or indicators on the UI than this code is forever locked to a UI with that same control or indicator. If this same code were used and rather than display the data you wanted to simply log it somehow it would be difficult to reuse the code. You would have to create dummy controls/indicators so you could pass them into the subVI.

---

So then always go with Message Queues to allow reusability?

[Mark_Yedinak]

If you are developing a modestly complex application then the design should be very layered. Business logic (the code that does the important and cool stuff) should only do that. Your data acquisition or analysis should do nothing but that. It should not have references to the UI or message queues. Basically, your code should be structured such that everything has a very specific function and that is all it does. OOP helps you achieve this but it isn't the only way.

So at the lowest level of your code you will have classes/libraries that are very narrowly defined and perform a very specific function. For example, your data acquisition will only be concerned with collecting the data. It will not analyze it or be concerned with how the data is consumed or displayed. Next layer up would be the data acquisition task. This will use the preceding library to collect the data. This task is then concerned with the processing of the as well as passing it to the UI, log or DB. This task could also perform some of the analysis or transformation on the data.

The UI portion of the code should do nothing but handle the UI. It will collect input from the user and display data. It will get the data via queues or user events. By separating the functionality you will achieve much more reuse of your code.

[DailyDose]

So to sort of bring this full circle, from what I'm reading, a super simplified explanation of DVR is that DVR is just a replacement for a FGV/AE in the OOP world?

[Mark_Yedinak]

---

@DailyDose wrote:

So to sort of bring this full circle, from what I'm reading, a super simplified explanation of DVR is that DVR is just a replacement for a FGV/AE in the OOP world?

---

Basically yes except for the OOP part. DVRs can be used with or without OOP.

[mcduff]

---

@DailyDose wrote:

So to sort of bring this full circle, from what I'm reading, a super simplified explanation of DVR is that DVR is just a replacement for a FGV/AE in the OOP world?

---

I would say yes.

Expanding on what Mark said, if you are really worried about data copies, create/destroy the DVR in your low level code and send the DVR reference out of your message queue. So rather than receiving a potentially large array, you just receive a reference. Of course, you may need to copy this data to do analysis that may negate the benefit of a DVR. If the creation/destruction is in your low level code, there is no tie in to the other parts of the code; the other parts of the code just need to know what to do with the DVR reference.