As part of an ongoing effort to make NCA easier to understand and maintain, we should separate everything that is strictly for database reading/writing from the rest of the app. The first step to doing this is making a data package under which our models live. Basic CRUD methods would live here, returning / modifying database-specific structs. Anything that transforms data from its raw DB presentation would be part of the app logic, and never live alongside the data package.
In addition, nothing outside of data would ever touch the database handler. The data package would have a method for connecting to the database and setting "debug" mode, but it would not expose the DB handler directly. All database operations would have to use some function within data.
Benefits:
All "serialize" and "deserialize" nonsense goes away. The business logic would do these transformations as part of communicating with the data package, so it would be clear instead of the semi-magic setup we have now.
Again, more easy to maintain
Significantly easier to see what the app does as opposed to how the data is stored and serialized
Centralizing all DB access should make it a lot easier to transition to something like sqlx
Might make it obvious where we have too much logic in the app that should shift to the database - complex transactions that are not terribly fault-tolerant, for instance, or roundabout data compilation that should be a view.
As part of an ongoing effort to make NCA easier to understand and maintain, we should separate everything that is strictly for database reading/writing from the rest of the app. The first step to doing this is making a
datapackage under which our models live. Basic CRUD methods would live here, returning / modifying database-specific structs. Anything that transforms data from its raw DB presentation would be part of the app logic, and never live alongside thedatapackage.In addition, nothing outside of
datawould ever touch the database handler. Thedatapackage would have a method for connecting to the database and setting "debug" mode, but it would not expose the DB handler directly. All database operations would have to use some function withindata.Benefits:
datapackage, so it would be clear instead of the semi-magic setup we have now.