Having them as singletons is a warning flag for me already.
Why?
If I proceed with DAOs, I'd modify Information first so that I would not touch the rest of the system and accidentally break anything. If I do break anything, at least I know where I screwed up.
Add some unit/integration tests instead. Given tests will be implemented properly, you'll have a guarantee that if anything breaks, your module is not the culprit.
Singletons tend to be misused so my warning flag goes up.
Add some unit/integration tests instead. Given tests will be implemented
properly, you'll have a guarantee that if anything breaks, your module is
not the culprit.
Singletons tend to be misused so my warning flag goes up.
Singleton is just a way to ensure that only one instance of some class is present at runtime. If the project you're working on has DI set up, then you probably can get rid of them without much trouble.
Since there is a text file with queries, maybe try JDBI. It's not exactly an ORM, but from the SQL code you posted I've got an impression that you may do fine without one.
Why?
Add some unit/integration tests instead. Given tests will be implemented properly, you'll have a guarantee that if anything breaks, your module is not the culprit.
Singletons tend to be misused so my warning flag goes up.
I'll be doing that in a bit.
Singleton is just a way to ensure that only one instance of some class is present at runtime. If the project you're working on has DI set up, then you probably can get rid of them without much trouble.
Since there is a text file with queries, maybe try JDBI. It's not exactly an ORM, but from the SQL code you posted I've got an impression that you may do fine without one.
I do am considering JDBI and utilize the data access object pattern. Thanks!