Facebook: MVC does not scale, use Flux instead
-
Facebook's consistency requirements and data are pretty atypical cases I'd imagine. Also having an almost unlimited pot of fairy dubloons means they couldn't care less about developer productivity. All that said - quite an interesting article. The pity is that it will be used by those who know little as ammunition to reduce all formal process to "copy blocks from google and give it a try".
-
The view should never have direct access to the model. That's one of the things MVVM addresses. I like the simplified design of Flux they're talking about, but I'd still add a client-side VM layer on top of it for the extra layer of abstraction. Maybe something like FluxVM or FVM. Sounds nice.
Jeremy Falcon
-
-
The irony of that is sweet. I recently co-wrote a kiosk application. It never really looked MVC. We had a "Metastore" (heh, notice the similarity in names) that contained all the data, and our dispatcher was a very cool state manager that I wrote. The views were WPF. Now I have a name for that kind of architecture. Flux! Marc
-
The irony of that is sweet. I recently co-wrote a kiosk application. It never really looked MVC. We had a "Metastore" (heh, notice the similarity in names) that contained all the data, and our dispatcher was a very cool state manager that I wrote. The views were WPF. Now I have a name for that kind of architecture. Flux! Marc
Marc Clifton wrote:
and our dispatcher was a very cool state manager that I wrote.
Was it bidirectional? I'm putting together a design for a new site and right now I see the only way to pull it off is with the dispatcher / controller being bidirectional.
Jeremy Falcon
-
Marc Clifton wrote:
and our dispatcher was a very cool state manager that I wrote.
Was it bidirectional? I'm putting together a design for a new site and right now I see the only way to pull it off is with the dispatcher / controller being bidirectional.
Jeremy Falcon
Jeremy Falcon wrote:
Was it bidirectional?
Well, with WPF / MVC, things are a mess. The view can update the model because you want the property changed event to trigger, for example. The clarity that we achieved is that view has its view-model and can do anything within that limited scope -- it owns it's own domain, if you will. However, anything that affects the model that the rest of the world sees goes through the dispatcher (which can be property change events but is usually a button click event or some external thing like a card swipe, bill acceptor read, or some device erroring out.) That was the theory. In reality, it was simpler to allow the view to update the model and thus it was bidirectional. But that's because certain fields, like zipcode, seemed ridiculous to go through and action->dispatcher->store sequence to update something that was exclusively informational. Marc
-
Jeremy Falcon wrote:
Was it bidirectional?
Well, with WPF / MVC, things are a mess. The view can update the model because you want the property changed event to trigger, for example. The clarity that we achieved is that view has its view-model and can do anything within that limited scope -- it owns it's own domain, if you will. However, anything that affects the model that the rest of the world sees goes through the dispatcher (which can be property change events but is usually a button click event or some external thing like a card swipe, bill acceptor read, or some device erroring out.) That was the theory. In reality, it was simpler to allow the view to update the model and thus it was bidirectional. But that's because certain fields, like zipcode, seemed ridiculous to go through and action->dispatcher->store sequence to update something that was exclusively informational. Marc
Marc Clifton wrote:
The clarity that we achieved is that view has its view-model and can do anything within that limited scope -- it owns it's own domain, if you will. However, anything that affects the model that the rest of the world sees goes through the dispatcher (which can be property change events but is usually a button click event or some external thing like a card swipe, bill acceptor read, or some device erroring out.)
This is what I'm going with. At first I called it MVVMC, but now I'm not sure since it's a "controller" in MVC compared to a dispatcher, but whatever. I'm liking it this though, and I'm ok with having a VM update going requiring an action that filters through the dispatcher. Not sure what the hell to call it though, as I don't think "Flux" supports ViewModels.
Jeremy Falcon
-
Marc Clifton wrote:
The clarity that we achieved is that view has its view-model and can do anything within that limited scope -- it owns it's own domain, if you will. However, anything that affects the model that the rest of the world sees goes through the dispatcher (which can be property change events but is usually a button click event or some external thing like a card swipe, bill acceptor read, or some device erroring out.)
This is what I'm going with. At first I called it MVVMC, but now I'm not sure since it's a "controller" in MVC compared to a dispatcher, but whatever. I'm liking it this though, and I'm ok with having a VM update going requiring an action that filters through the dispatcher. Not sure what the hell to call it though, as I don't think "Flux" supports ViewModels.
Jeremy Falcon
Jeremy Falcon wrote:
Not sure what the hell to call it though, as I don't think "Flux" supports ViewModels.
Yeah, I know, we had the same issue. One of the things that we learned in this process is, if you think you're architecture is doing ok, stick with it. There were a few times we almost tossed out the state manager, but we stuck with it and it has evolved into a very useful thing. We do a lot of async/await stuff (there's a layer of complexity -- it sounds so easy but it's not) so we ended up with features like the ability to defer state changes until the async stuff completed, and so forth. Works well with the "wizard-like" nature of a kiosk. Marc
-
Jeremy Falcon wrote:
Not sure what the hell to call it though, as I don't think "Flux" supports ViewModels.
Yeah, I know, we had the same issue. One of the things that we learned in this process is, if you think you're architecture is doing ok, stick with it. There were a few times we almost tossed out the state manager, but we stuck with it and it has evolved into a very useful thing. We do a lot of async/await stuff (there's a layer of complexity -- it sounds so easy but it's not) so we ended up with features like the ability to defer state changes until the async stuff completed, and so forth. Works well with the "wizard-like" nature of a kiosk. Marc
Marc Clifton wrote:
We do a lot of async/await stuff
That's actually what I'll be doing too, it'll be required actually, since I'm making a full-fledged single-page application for the first time in my life, and I'll need to maintain a solid client state while the server is doing its thing. Being the rebels we are, we should just remove the
Land call itFux. :)Jeremy Falcon
-
Marc Clifton wrote:
We do a lot of async/await stuff
That's actually what I'll be doing too, it'll be required actually, since I'm making a full-fledged single-page application for the first time in my life, and I'll need to maintain a solid client state while the server is doing its thing. Being the rebels we are, we should just remove the
Land call itFux. :)Jeremy Falcon
Jeremy Falcon wrote:
and I'll need to maintain a solid client state while the server is doing its thing.
Have fun with this: http://msdn.microsoft.com/en-us/magazine/jj991977.aspx[^] When we started working with async/await, we were actually spitting out debug messages with the thread ID to see how it was behaving. One problem that took half a day to debug was that, on application startup, I was calling the "sign-in" webservice function to make sure the server was up and running, but I was doing so before WPF initialized, and so there was no magic context for the await, thus it returned on a non-UI thread. Oh the joys. Personally, both I and my cohort believe async/await made life a heck of a lot more complicated. Threading used to be easy!
Jeremy Falcon wrote:
and call it
Fux.Two great minds, a single thought between them! :-D Marc
-
Jeremy Falcon wrote:
and I'll need to maintain a solid client state while the server is doing its thing.
Have fun with this: http://msdn.microsoft.com/en-us/magazine/jj991977.aspx[^] When we started working with async/await, we were actually spitting out debug messages with the thread ID to see how it was behaving. One problem that took half a day to debug was that, on application startup, I was calling the "sign-in" webservice function to make sure the server was up and running, but I was doing so before WPF initialized, and so there was no magic context for the await, thus it returned on a non-UI thread. Oh the joys. Personally, both I and my cohort believe async/await made life a heck of a lot more complicated. Threading used to be easy!
Jeremy Falcon wrote:
and call it
Fux.Two great minds, a single thought between them! :-D Marc
Marc Clifton wrote:
I was calling the "sign-in" webservice function to make sure the server was up and running, but I was doing so before WPF initialized, and so there was no magic context for the await, thus it returned on a non-UI thread.
Oh, the joys of multi-threaded programming and asynchronous operations. Over the web, I at least did a two year stint in Silverlight (which is all async by default) so I should be good to go with the concepts at least. Except this time around it's gonna be more client-oriented and done in JavaScript, so I'm sure I'll run into some sorta IPC issue like this.
Marc Clifton wrote:
Oh the joys. Personally, both I and my cohort believe async/await made life a heck of a lot more complicated.
But I'll be able to implement real-time pie charts. Think of the pie charts!! :)
Marc Clifton wrote:
Two great minds, a single thought between them!
Aye.
Jeremy Falcon