I am seeking the right model for storing and retrieving data, when working with any specific class, while keeping in mind the bigger picture.
I have some SQL code in (one) of my classes and I would like to use Separation of Concerns (SoC) to remove dealing with direct-database-specific code in that class.
Simplest thing will be to create
DBCodeForOneSpecificClass class, but thinking globally, I may end up with too many classes - I think creating a DB handling class for each Business logic is wasteful.
So I need to find a way to consolidate those DB-access functions properly.
I recall there was an advice in a book on refactoring SQL specifically and it was "pull all SQL code in your entire codebase and consolidate it in a single space, away from all other non-direct-SQL-dealing classes". I do not recall specifics. I presume all SQL-code was to go into its own separate folder, where perhaps there was some kind of strategy or philosophy to keep a
happy medium between the extremes of
- create a single separate db-handling class for all classes in your entire codebase
- create a single separate db-handling class for each
My question is -- can you help fill some specifics into the space between the extremes -- what are some heuristics / models / ways I could use to make a decision on how to structure my DB-handling classes, so that I pretty much immediately know what to do, when handling a question of "Where do I place my db-handling code I currently find myself writing in this
Because right now I seem to solve this question on a case-by-case basis, either having SQL right inside the class, or in a separate class made just for one class, or grouping SQL by an aspect. In the end, ending up with various models mixed up, and that is not good. I am thinking that maybe may need help defining what an aspect is, or identifying clearer boundaries of what my domain objects are, which perhaps means identifying larger moving parts of the codebase, and then structuring my DB-interaction classes around those parts.
My satisfaction with the answers will depend on whether I am able to get closer to answering question of "Where do I put my d--n SQL while writing this specific new feature in this specif class...?", while supporting SoC principle, and without being wasteful (too specific) or creating a big ball of mud (too general).