Rethinking This Whole MVC Thing
As time goes on, I find shifting one's mental model back to "simpler times" can be a handy trick for breaking out of self sustaining ruts. If you look at the current state of the art in web frameworks you'll see:
- a router which dispatches vhost+path -> some handler
- a magical object mapper which serializes and deserializes data from your data store
- a templating system which does elaborate string replace logic
And that's about it.
- get a request
- do some stuff
- get some data
- spit out a file
What is so telling here is that no thought goes to behavior, the system performs a set of functions and does it well for the limited use case of producing different sets of strings.
- CDN serves mostly static files
- jQuery generates DOM elements based on XHR to a data server
- User behavior generates new XHR requests w/ drive DOM manipulation
This model is slightly better in terms of it's caching characteristics, in that most commonly used resources are mostly static. The data requests using XHR always require additional engineering to scale and make performant. Partitioning, sharding, and replication strategies try to address the concurrency issues.
Beyond that we enter into a new world of actors and message passing. Anyone familiar with building applications in Erlang has this basic model in their head. Rather than treat the application as a client and a server, we have a tree of servers each of which is slaved to its parent in a supervisory tree. Communication between peers occurs through sending messages to a pid reference or proxy. Well named resources often broker communication to child processes who do the dirty work.
My current web framework work is based on this principle. Rather than an application code router which acts as a dynamic dispatch (or switch statement), I have a message router that routes messages to 0 or more recipients. Each component communicates with its parent in a supervisory tree of routers, with transparent proxies bridging the gaps between "client" and "server" code. In this model every button, every backend process, every data store is just an actor who responds to messages. Since the message is the medium of this program, state is the collection of inflight messages and the internal state of every object attached to the messaging system.
The details of implementation are pretty trivial, but the ramifications of the approach aren't. Using websockets and transparent bidirectional proxies like Onomatic, one can route communications between clients. Rather than building a backend infrastructure, the network serves to merely manage communications between peers (like the telephone). And this returns us to a simpler model from a simpler time.
The next trick is even simpler:
- Model = any object which represents data (hint most stuff is model)
- View = any object which displays data (hint your screen, your speakers, your flashing led)
- Controller = any object you use to operate a computer (hint mouse, keyboard, touchpad, microphone, camera)
If you look at Phos you will see the conceptual basis right there. Keyboard is an object which sends messages to all objects that respond to key events. Mouse and touchpad work the same way. In my new framework, these objects can pass messages to any object anywhere within the network including clients on other machines. These same messages are also sent to models which may or may not alter their state based on the messages. Likewise other behavior monitoring objects synthesize new messages based on the flow of messages which lass them. Beyond the world of MVC is a world of pure objects passing messages across the Ethernet.
It is a happy land.