Coupling Best Practices

[ihyd-zmay]

I've been working with LabVIEW for a while now, but this is my first project using DQMH and I want to make sure I'm following best practices as much as possible.

Say I have the following modules:

• User Authorization - Handles verifying a user's username and password against a database value to ensure they're authorized to use the application.
• Result Logger - Logs test results to a database. Pretty standard and common for a number of applications.
• Test Executive - Launches tests on a device that involve database interaction (i.e. the device interacts with the database, then the database is queried to see what the device returned).

In all of these instances, I'm interacting with a database (in one way or another). I'm struggling to determine what's the best method of handling the cross dependencies of these modules.

Is it best to:

1. Create a "Database Interaction" module which all of the other modules can call?
2. Create a "Database Interaction" module, but route all of the other modules calls through my main application so there's no cross dependencies between modules and it's more of a "tree" diagram?
3. Create a shared subVI like Execute Query.vi thats just called by multiple other modules but exists outside of any modules (in a shared library for example, one already exists for other items like shared classes for example)?
4. Create a unique subVI for each module that handles database interaction solely for that module?

It seems to me like B or C are the two best options, as then there's either no dependencies between modules or the modules just depend on the shared library (which they might for other items anyways). Right now, C is seeming like the best option since it requires the least complex design choice even though it does create a singular dependency, but I know that zero-coupling is always more ideal.

[Darren · Accepted solution]

If all the modules need to interact with the database, I see no reason why they can't all call your Database Interaction module, i.e. option A. There's nothing inherently wrong with a DQMH module depending on another DQMH module. It's a very common pattern that I describe briefly in Step 4 of my DQMH Quick Learning Path.

[ihyd-zmay]

That's honestly my preference as that makes the most sense to me logically, so I'm glad to hear that's not a "bad" solution! Thanks for the quick response.

[drjdpowell]

Option C or D are a lot simpler.  Note that databases are designed to handle multiple connections using ACID principles.  I've seen real-world cases where a "Database Interaction" component has added complexity while degrading capability (mostly by eliminating the ability to do parallel Transactions) and has produced no benefit whatsoever.

[joerg.hampel]

---

@drjdpowell wrote:

(mostly by eliminating the ability to do parallel Transactions) 

---

In our HSE toolbox, we have a stand-alone DB DQHM module that each and every other module that needs DB access will start a separate clone of. That way, like James says, each module can have separate transactions.

You can have a look at the DB Example module in our open-source HSE Application Template. Let me know if that is interesting to you, and we can continue this discussion on the HSE Discord.

[ihyd-zmay]

---

@drjdpowell wrote:

Option C or D are a lot simpler.  Note that databases are designed to handle multiple connections using ACID principles.  I've seen real-world cases where a "Database Interaction" component has added complexity while degrading capability (mostly by eliminating the ability to do parallel Transactions) and has produced no benefit whatsoever.

---

That is a really good consideration actually. I should note that I don't foresee this application being able to access the database from multiple modules simultaneously (since its pretty user driven), so that probably isn't a concern. Nevertheless, something to consider and does make options C or D a bit more viable like you mentioned.

As @joerg.hampel mentioned though, making it a Cloneable module would solve that and is a fantastic idea. I actually really like the thought of it being a Cloneable, since that would clean up the communication channels I'm visualizing since then each module can spin up their own instance instead of trying to all communication back to a single instance.

This does bring up another question I have though: if I create a subVI for a Cloneable module, does that subVI need to be made re-entrant? I would assume yes.

Now I need to see if I can convert a Singleton to a Cloneable...

[joerg.hampel]

---

@ihyd-zmay wrote: Now I need to see if I can convert a Singleton to a Cloneable...

---

🙈🙈🙈

[Darren]

I recently had to convert a Singleton module to a Cloneable. Unfortunately there isn't a scripting tool for this, so I had to do it manually. My module had a helper loop and roughly 6 requests/broadcasts. It took about an hour for me to re-create the module and copy the business logic over from the singleton to the cloneable.

[Taggart]

I would ask the question - does it even need to be a DQMH module? Not everything in your program does. Could you not just wrap the database connection in a class and pass that around?

[drjdpowell]

Having cloneable modules with separate database connections would solve the main problems, but I still don't see the point of the considerable added complexity.  The advantage of an module would be the ability to do asynchronous db queries, but none of your three primary modules need or want that.