06-05-2020 04:35 AM
Hi all.
I am still a bit new for buidling "big" applications from scratch (for now I'm mostly either building small ones or continuing the dev of "big" ones - What is big anyway?) so please bear with me if what I'm asking makes no sense 🙂
While struggling a little bit to find differences between Queue Message Handler, Master/Slave and Producer/Consumer, I've done a bit of reading already on those different threads "Difference between MS and PC" ; "Difference PC and QMH" ; "When is PC not suitable for separating UI/Logic" . Big thanks @crossrulz if you pass by here btw for your help in these threads.
I guess only experience will allow me to choose properly between them, but I was actually wondering: Why choosing?
I mean some applications can be quite complete (for some test beds for instance) where you have to do a lot of different things.
But even for a small applicatio, for instance: I have a test bed that needs to be physically prepared: precise postion of masses to adjust a center of gravity; once done, you can start the test-s which can be long and generate quite a lot of data to be analysed/stored.
Now for the precice position of the masses, you need a very responsive UI and I wouldn't go for a QMH as the user could be a stressed guy, hitting that button faster than the motor/hardware is moving/treating the info and once he is stopping, there is still a lot of "button clicked" messages in the queue and the motor won't stop when the user stopped cliking. A MS sounds more appropriate for this, no?
On the other hand once this is done, the test can be running and acquiring data, either in the background or directly showing the live results to the user and a PC could then be more appropriate?
So I would have different architectures for the same application?
What I'm thinking as well is that those two actions described could also be two separate VIs having their own architecture, and a Main VI/UI would then open specific windows for the user to interact with the test bed (this main VI would then be a QMH or even just an event driven vi as there wouldn't be a lot to do?)
Again, just trying to understand the logic behind these architectures.
Thanks in advance for your insights.
Vinny.
Solved! Go to Solution.
06-05-2020 09:53 AM
The first thing I'd say is that an architecture or design pattern shouldn't be seen as a recipe, a paint-by-numbers picture or a set of assembly instructions. Your code does not serve the architecture and you are not bound by it. There's a problem to be solved and common architectures and design patterns can help serve *you*.
So, certainly, yes, you can mix different architectures in an application. A lot of my code starts from a custom QMH project template. But in practice, some of my message handling loops are *mostly* like pure producers, or pure consumers, or pure slaves. Sometimes I make code that's primarily a state machine, but with a QMH wrapper around it to provide a little high-level control for startup, shutdown, mode changes, etc.
Most of my instrument communication gets a dedicated QMH loop. Internally I have normal driver-like functions inside that code module, but the external API for this "driver" is mediated via the supported QMH messages.
There's almost never a single right answer for how to code your app. I've found the QMH to be a very adaptable framework to start from because I can use it (abuse it?) to behave like other design patterns such as producer/consumer and master/slave.
But again, an architecture is not a rigid contract. You're still free to do what makes more sense in a particular situation.
-Kevin P
06-05-2020 11:53 AM
There's nothing stopping you from mixing and matching different design patterns and frameworks but I think you might want to proceed with caution because there are definite advantages to having a consistent approach in sending/receiving/handling messages and expressing interfaces between components.
If you just have a bunch of QMHs then people working on your code only really have to know how a QMH works. There is also a pretty standard way of adding functionality to a QMH so once someone learns that workflow once they should be able to repeat it even if they're working on a different QMH. If you go to one extreme and have every component use a different framework, the developer has to learn a lot more to make changes. A lack of consistency can also make reading code more difficult in my opinion.
On the other hand if you try to force every bit of functionality to play nicely with one design pattern you can end up trying to put a square peg in a round hole.
06-08-2020 06:13 AM
Hi.
Thanks for your answers.
It confirms what I thought: Architectures are more guidelines rather than rules... Which somehow makes it more difficult to choose between them!
I haven't seen a full description/comparison of them all (kindof like a chart with pros/cons/application for each of them (rather than reading the whole description on separate pages...), if ever you have one, I'd take it!
I will tryout some stuff and see how it goes, might upload it here if ever you wanna review/criticise it 😁
Best,
Vinny.
06-08-2020 06:50 AM
@VinnyAstro wrote:
I haven't seen a full description/comparison of them all (kindof like a chart with pros/cons/application for each of them (rather than reading the whole description on separate pages...), if ever you have one, I'd take it!
A good place for such a chart would be here: https://labviewwiki.org/wiki/Design_Patterns