1

In writing a relatively simple app, I was considering making a class that handled all the database interaction. I was going to construct all the prepared statements in the class. That way, any DB changes would (probably) only result in changes to that one class. (Also, it puts the DB user ID & password in one class.) For example, I was planning to write a class with a method to register the DB driver, another to make a connection, another to read, another to write, and yet another method to update.
Besides ease of maintaining the code, does this offer any other benefit? Maybe under a multithreaded context? Also, I was planning to passing as arguments to the query methods the variables to bind to the prepared statements. I was going to return the result set as an argument as well. Am I over thinking this? TIA.

MaybeWeAreAllRobots
  • 1,105
  • 2
  • 9
  • 12

3 Answers3

0

This sounds "by definition" to be encapsulation of the DB and then a adapter/bridge/facade-'design pattern' variation (depending on your exact implementation)

So no, I don't think you are over-thinking this.

mawalker
  • 2,072
  • 2
  • 22
  • 34
0

I would say using ORM like hibernate is much better choice. It will reduce lot of boiler plate code. Plus much easier to read-write or write migrations (adding new fields or tables). I used similar approach for my college project which was purely java. I created a singleton class Database with all functions. Singleton class ensures only on copy of Database methods.

quazar
  • 570
  • 4
  • 14
0

You could use DBUtil which is library encapsulating DB access and operations (same as what you are trying to do).

You should not hardcode credentials in your class since that could be accessed by de-compiling your classes. See here.

Community
  • 1
  • 1
Fahim Farook
  • 1,482
  • 2
  • 14
  • 38