My question is about how best to organize C++ classes around a database model, a
ID: 658917 • Letter: M
Question
My question is about how best to organize C++ classes around a database model, and I understand this may appear very elementary.
The software I propose to create will do the following. It is intended for small FMCG manufacturers and will use Qt.
The software will record non-conformance's, product complaints, corrective actions and serve as an electronic record keeping
There will be quite a bit of 'business logic', as the standout feature is intended to be comprehensive reporting, searching and analysis, as well as a flexible approach to entering data to smooth workflows (ie, a break away from the "one screen per process stage" paradigm)
The persistent store is an SQL database, with a table(s) for each type of record (some records will be broken into separate tables for investigations/solutions. This means that most work will be done on a single row).
Each customer who uses this software will require amendments, additional columns/fields or changes in column names and maybe business logic. Each customer may require updates which change the database structure. The idea is that anything that can be customized, any client specific requirements will live within these classes.
There will be reporting, mainly involving pulling records matching particular categories, word searches, etc.
I have the database schema done and laid out, and the logic of how tables relate is clear. I have used this very schema in another framework, but a web based app doesn't seem to offer the level of power to the user with regards to the GUI, which is essential to differentiate this product from the others.
My question is how to design classes around the database. It is important to get this right, so that the architecture of the software doesn't have to be redesigned later on. The classes will not be responsible for the persistent store, only for acting as an intermediary between the layer responsible for the persistent store and the controllers/views.
The most logical approach appears to be to have a class for non-conformances/complaints etc, which solely store the instance (ie, one object per non-conformance record), validate data and class specific business logic (ie, computations). One class per table seems logical in this case. What I'm struggling with, is whether it is standard practice to simply have data members for each column, define getters and setters, or whether I should create a class which isn't hard-coded to map to a table, but which populates a map based on the database schema or external file which defines the database and column properties. The former means that the coding for the class needs to be changed when columns are modified, the latter potentially not. Keep in mind, for the majority of the time, each user will be working with one record at at time.
In short, I can see example of how to do SQL queries, but I've struggled to find anything which shows me what the class should look like (or if this entire approach is wrong) and I'd like to compare what I'm doing, with what the industry would define as good practice (I'm not a programmer by trade).
Thank you,
Explanation / Answer
The first question is if you are okay with having to recompile the program every time the database schema changes. I'm not quite clear on your situation but for example:
You have a number of clients with slightly different needs (ie A needs to track Properties X, Y, Z, but B also needs to track Property W) but for a given client those needs are pretty constant. And you can work with and deploy a custom application to each client (aka you aren't selling this off the self). In that case, have a template that you can then inherit from and modify on a per client basis might be a pretty good business strategy, if the total number of clients is not high enough to make it worth creating a highly adaptable application right from the start. Having 5 different versions of the program is still maintainable, 100 is not.
On the other hand, if you have 100 clients you simply cannot be changing the code every time one of them wants to add a property (column) to something. Or even add a new type of object. So the program will need to be more dynamic, probably working off a relational map that is saved somewhere and that can be edited by the program as needed.
So lets assume what you have is more like the former. Having classes that represent the types of records you have is a good way to do it. Those classes can contain SQL queries directly. You should still however have things like table names as constants defined in a common .h file and then call them as constants in your actual code so any change needs to be made in only one place. Then if you need a slightly different object for a different client, you can inherit the classes you already have and make the necessary changes.
You could also put together an intermediary class that handles actual database interactions, so if you change the schema or even the type of database you are using, you just need to switch out or modify that class.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.