At its core, an interactive application just does this:
- show data changing over time
- read controls that affect how data changes
Sri's Data Layers
The elements in this table are just for the pure data manipulated by the app, independent of any data structures related to the way this data is presented visually or converted into reports
The true source of data, in its most normalized form. This lives in a database somewhere, with access carefully managed to prevent corruption.
A straight copy of
DATA SRC. This is what is loaded into the interactive for local manipulation. I like this to be as close to the original form as possible for ease of debugging. I call the module that manages this a "datacore".
"Derived Data" that creates new structures around
DATA that convert the original data format into something easier for your code to use directly. Examples are lookup tables, filtered lists. This derived data structures are created when DATA0 is created, so it is part of datacore.
Up to now, these are all pure data that have not been adapted for use by a particular application need. These sets of data all correspond to the DATA API that is appropriate for a data service module.
From the pure data we create all sorts of glue data that we need to feed or cross reference to other code.
These are new data objects that are created based on values of
DDATA1, perhaps from multiple combined sources, creating a composite object that is still pure data. If either DATA or DDATA1 update, then DDATA2 must also update. This data may generated by a subscriber to datacore, creating specialized structures as needed as another type of datacore.
These are structure adapted for specific library APIs and used by that code. For example, your pure data source may contain a list of entity objects. Your GUI has to have a copy of that that it can filter and reorder, which then is converted into API-specific data structures for library calls. This glue data has to be converted to-and-from data defined in datacore.
A GUI makes use of all these layers, because it needs:
- data to process, after conversion into sprites, html elements, etc
- derived data which are the intermediate data structures used for GUI-related library use
- events to handle, which are fired asynchronously for one of many sources and handled
- visualization of data, which requires derivative data tailored for view components
- state for read/write component data, component state, and application state
- operations the non-GUI code that does the application work, results in an update of some kind
I try to model each of these layers as distinct from each other as possible using one-way binding.
INITIAL DATA SERVICE INIT DATA0 --> DDATA1 DDATA1 --> DDATA2 APP DERIVED DATA DDATA0 --> APPCORE (DDATA3) DDATA1 --> APPCORE (DDATA3) DDATA2 --> APPCORE (DDATA3) APP DRAW DERIVED DATA APPCORE --> VIEWMODEL VIEWMODEL --> VIEW STATE --> VIEW UI-INITIATED VIEW CHANGES VIEW --> EVENT --> APPCORE (HANDLER) --> VIEWMODEL --> APPSTATE APPCORE (OPERATION) --> DDATA0 CONTROL EVENT-INITIATED CHANGES EVENT --> APPCORE (HANDLER) --> VIEWMODEL EVENT --> APPCORE (HANDLER) --> APPSTATE EVENT --> APPCORE (HANDLER) --> APPCOMMAND