3 ms·

There is a lot of truth in what the Author wrote, however he completely missed the MVVM pattern and confused it with MVC. The MVVM pattern, originally designed

by keyle 3y ago

There is a lot of truth in what the Author wrote, however he completely missed the MVVM pattern and confused it with MVC. The MVVM pattern, originally designed by MSFT for Silverlight, showed a way that basically cleaned up a lot of the issues with MVC. That is what SwiftUI uses today, MVVM, as you can compare with his diagram of what he calls "Apple's MVC" and this diagram from MSFT: [1]. In fact, I'd go out on a limb and say that no one really uses MVC today - in its pure original form. [1] https://learn.microsoft.com/en-us/dotnet/architecture/maui/mvvm https://learn.microsoft.com/en-us/dotnet/architecture/maui/m...

smackeyacky 3y ago
Funnily enough, the 1990s VisualWorks UI moved on from the original MVC implementation into a pile of complexity involving adaptor classes and automated event processing, so even the Smalltalk guys knew the original implementation wasn't enough for most GUI problems.
sparkie 3y ago
I like the Model-View-Adapter[1] architecture, which is basically what you get by reversing the arrows between the View and ViewModel in MVVM. The view and model are oblivious to each other and to the adaptor directly (but interact with it indirectly), and the adaptor depends on both the view and model. My use case for this a bit different than regular UIs though. I've used it in an MMO server, with the view representing the network protocol which clients interact with, and the model being the state of the game world. The adapter receives messages from game clients asynchronously and updates the world, then sends messages back to the clients affected by the change in the world state. IMO it makes sense to have the inverted dependency in this case. If the view depended on the adaptor, then changes to the game server behavior would impact the network protocol, which would also force changes to user clients each time the server gets updated. Ideally we want to be able to make regular updates to the server without impacting clients. [1]:https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93adapter https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93ada...

by keyle 3y ago

smackeyacky 3y ago

Funnily enough, the 1990s VisualWorks UI moved on from the original MVC implementation into a pile of complexity involving adaptor classes and automated event processing, so even the Smalltalk guys knew the original implementation wasn't enough for most GUI problems.

sparkie 3y ago

I like the Model-View-Adapter[1] architecture, which is basically what you get by reversing the arrows between the View and ViewModel in MVVM. The view and model are oblivious to each other and to the adaptor directly (but interact with it indirectly), and the adaptor depends on both the view and model. My use case for this a bit different than regular UIs though. I've used it in an MMO server, with the view representing the network protocol which clients interact with, and the model being the state of the game world. The adapter receives messages from game clients asynchronously and updates the world, then sends messages back to the clients affected by the change in the world state. IMO it makes sense to have the inverted dependency in this case. If the view depended on the adaptor, then changes to the game server behavior would impact the network protocol, which would also force changes to user clients each time the server gets updated. Ideally we want to be able to make regular updates to the server without impacting clients. [1]:https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93adapter https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93ada...