jfroelich
commented
5 years ago It is conventional for a model to broadcast changes. The concern of tightly coupling the model to a browser-specific feature like BroadcastChannel can be alleviated in a smarter way. By defining a ModelChannel interface, and a ModelBroadcastChannel class that implements that interface. The model is coupled to only the ModelChannel interface.
Second, there is no need to stuff Feed, Entry, and Db into the same module. These can be three separate modules located within a folder named something like db or model.
Third, it is fine to define validation and sanitization in the respective model entity modules. After all, an entity module is the location most aware of its own fields.
Fourth, model should be separated out from core, and core should be re-envisioned as the controller layer. I almost had this right before, I was just took a few wrong turns. In order to accomplish this, however, I need to revisit the dependencies of db and cdb. Those need to not depend on any modules in the controller layer. If they do, I need to possibly introduce a fourth layer that exists below the model layer, something like a base app layer, that contains whatever modules that do not feel like they belong in the model layer, but the model layer depends on them, and because those modules are app specific, those modules do not belong in the even lower lib layer.
So, the dependency order essentially becomes:
- ext layer consisting of third party dependencies, none of which are in any way dependent on anything in the app
- the lib layer. nothing in the lib layer depends on anything in mvc. the lib may use third party.
- the base layer. hard to place modules upon which the model depends, but do not themselves belong in the model.
- the model layer
- the controller layer
- the view layer
If pretty much nothing uses db other than cdb, why separate? So what if the model is tightly coupled with the browser. I could get creative, create a custom channel object, and tie the model to this abstract channel concept, and have the broadcast channel just involve some kind of implementation or specialization of that channel interface. Then I could merge the two. The model broadcasts its events. I introduce a layer of indirection in a different place, so complexity does not exactly drop, but it feels like a better fit.