2 ms·

Seems to me that what people usually think of as the "Model" layer actually has "Operations", but we usually call them "methods." And "Events" is essentially C

Seems to me that what people usually think of as the "Model" layer actually has "Operations", but we usually call them "methods." And "Events" is essentially Controller code. (There might be an argument that this describes a "fat" model vs some devs/frameworks choosing "thin" models that are just state rather than state + logic. )

samatman 7y ago
It's reifying Events that attracts me to this model. This would encourage a message-passing style, which has always been a big win for me when I adopt it. Operations is pretty much a rebranded Controller, here. But it's a good rebranding! I've seen Controllers turn into a "God class" too many times, where you end up with big lumps that do more-or-less everything. Or, what's closer to the original paradigm, you have one Controller per Model, but that's the thing: a given action will routinely involve two or more models. Do you put a bit of persistence logic in the User Controller or the Session Controller? Thinking in terms of Operations should encourage small classes that each do one thing, and follow their own logic, not View logic or Model logic. And having everything communicate through well-defined Events is great, this would make it much easier to add additional sources and sinks by reusing an already-established Event with a new Operation. The more I think about it the more I like it.