Coupling Best Practices

[Darren]

One reason it makes sense to be an async module is for database connection management. I've worked with a cloneable database module where each clone manages the database connection, which also gives you the ability to do more sophisticated behavior like automatically attempting reconnects if the connection is lost, transparent to the end user of the public API of the database module.

[ihyd-zmay]

I'm glad this stirred up so much conversion! I'm really enjoying the discussion.

Yeah, that was my thought as well. If I create it as a DQMH module, then I gain the flexibility of asynchronous calls if needed and then the module can do things like maintain the connection reference, handle errors, etc. all within the module itself so the caller doesn't have to manage all of that or even know how it works. Plus, then I can do some unit testing to verify my database connectivity is working as expected (which I could do with a class like @Taggart mentioned, but the DQMH API Tester is a nice bonus). Plus, then I have access to the other DQMH extra like the validation tool as well.

@drjdpowell - This is probably more complex than it really needs to be for this application, but most if not all of the applications I'm developing these days have database interaction in them, so the reusable module could come in handy for future development. While you're right that I don't need any asynchronous calls at the moment, future me might and I should really look out for him more!

[Taggart]

---

@Darren wrote:

One reason it makes sense to be an async module is for database connection management. I've worked with a cloneable database module where each clone manages the database connection, which also gives you the ability to do more sophisticated behavior like automatically attempting reconnects if the connection is lost, transparent to the end user of the public API of the database module.

---

That makes sense.

I mostly use SQLite (Thank you Dr. Powell!) so managing connections is generally not an issue.

[Taggart]

---

@Taggart wrote:

---

@Darren wrote:

One reason it makes sense to be an async module is for database connection management. I've worked with a cloneable database module where each clone manages the database connection, which also gives you the ability to do more sophisticated behavior like automatically attempting reconnects if the connection is lost, transparent to the end user of the public API of the database module.

---

That makes sense.

I mostly use SQLite (Thank you Dr. Powell!) so managing connections is generally not an issue.

---

Although as I am writing this I recall a project I did recently that used SQLite where I did have a database module - not for connection issues, just a general architecture decision I made and I can't even recall why. Singleton though, not cloneable. And I did wrap the database in a class, but instead of passing the class around to all the modules, I wrapped it in a DQMH module and sent requests - maybe to offload DB overhead to a parallel thread?

[drjdpowell]

YAGNI

[ChrisFarmerWIS]

---

---

Although as I am writing this I recall a project I did recently that used SQLite where I did have a database module - not for connection issues, just a general architecture decision I made and I can't even recall why. Singleton though, not cloneable. And I did wrap the database in a class, but instead of passing the class around to all the modules, I wrapped it in a DQMH module and sent requests - maybe to offload DB overhead to a parallel thread?

---

I find wrapping a class inside a module easier.

Because if you have a class available to multiple modules, then you're stuffing around with DVRs and breaking the dataflow.

[drjdpowell · Accepted solution]

---

@ChrisFarmerWIS wrote:

Because if you have a class available to multiple modules, then you're stuffing around with DVRs and breaking the dataflow.

---

My main suggestion is don't share database connections between modules, because databases are designed to work with parallel code running through independent connections.  My secondary suggestion is that more complicated solutions to support vague ideas of possible future advantages has a very high chance of turning out to be a negative.  Your DVRs don't sound any simpler than a module. 

I would just use a simple class with a DB connection inside it, with each code module making an independent connection to the DB.  No sharing.  

[ihyd-zmay]

After playing with the implementation some, you're absolutely correct. Making it a module and launching that module from every place I need to interact with a database became a bit cumbersome. I've wrapped the functionality into a class and am just creating a unique instance of the class anytime I need a database connection now.

The thing that really motivated the class creation is that if I do ever need a module, I'll just wrap the class into the module's private data and the core functionality remains the same. The module then just acts like an API for the class.

Thanks Dr. Powell!

[ChrisFarmerWIS]

---

@drjdpowell wrote:

---

---

My main suggestion is don't share database connections between modules, because databases are designed to work with parallel code running through independent connections.    

---

That's a good point.  I've always previously thought of a database as a single access point, much like we might treat a hardware device reference. But no, it's parallel.  

---

@drjdpowell wrote:

---

Your DVRs don't sound any simpler than a module. 

---

Agree.  That's what I was trying to say!

---

@drjdpowell wrote:

---

I would just use a simple class with a DB connection inside it, with each code module making an independent connection to the DB.  No sharing.  

---

I like this.