10 ms·
MVC is dead, it's time to MOVE on (2012)
- hessenwolf 13y agoSshhh... I have just moved us on to this in the office.
- Guvante 13y agoI dunno, this and most the other complaints about MVC are about the ambiguity of the controller definition, not the fundamental concept.
- film42 13y agoThis is actually remarkably similar to Backbone.MarionetteJS, only, swap the O with C for Controller (but don't be fooled, even their docs say it's not the most fitting name). For those interested in learning more about Marionette, Amy Palamountain made a fantastic presentation you can check out at her site: http://amy.palamounta.in/2013/04/12/unsuck-your-backbone/ http://amy.palamounta.in/2013/04/12/unsuck-your-backbone/
- jonesetc 13y agoPrevious discussion from when it was posted(Very active): https://news.ycombinator.com/item?id=4189811 https://news.ycombinator.com/item?id=4189811
- jtreminio 13y agoI was never a fan of "strict" web MVC. It felt like you were jamming far too much into your models. Take Symfony2's architecture, for example. Controllers, Entities, Repositories, Views, Services, Listeners, Events, etc. Each layer has its own distinct purpose that do something very specific by themselves, but when brought together form a very cohesive whole.
- deleted 13y ago[deleted]
- dscrd 13y ago>Take Symfony2's architecture, for example. Controllers, Entities, Repositories, Views, Services, Listeners, Events, etc. Each layer has its own distinct purpose that do something very specific by themselves, but when brought together form a very cohesive whole. But the end result is so very complex and the benefits gained are doubtful at best.
- camus 13y agoYou obviously never worked with javaEE ... Symfony is a breeze compared to how the former works.
- spenczar5 13y agoShould be mentioned that this is from 2012.
- icebraining 13y agoI'm certainly not the first person to notice this, but the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don't know where else to put it. No, that's just with the bastardized version of MVC popularized by Rails et all, which treat the views as little more than templates. In the original MVC papers from Smalltalk, the views did actually send messages updating the model: A view is attached to its model (or model part) and gets the data necessary for the presentation from the model by asking questions. It may also update the model by sending appropriate messages. All these questions and messages have to be in the terminology of the model, the view will therefore have to know the semantics of the attributes of the model it represents. http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf
- bowlofpetunias 13y agoMost criticism of MVC and frameworks can be summarized as: "I don't understand MVC, this framework I'm using doesn't supply me with a one-size-fits-all architecture for my business logic and I'm incapable of designing my own. So I'll just stuff my spaghetti style code somewhere, and bitch about MVC and/or the framework being insufficient/dead/shit." It's the ultimate expression of a bad craftsman blaming his tools, and it's endemic in web development.
- hvidgaard 13y agoI've lost count of how many times I've had to argue that the View binds (loosely put, for View <-> Model interaction) directly to the Model. The Controller only enters the chain if the operation is more complex, i.e. it is a composite operation. That said - the Controller is the only place that is left if the code isn't interface or datastorage specific, so naturally it's the first place to get bloated. But that's fine, you just have to take care of that when you can, by abstracting common functionality and/or move it out in a library.
- gizzlon 13y ago"this framework I'm using doesn't supply me with a one-size-fits-all architecture for my business logic and I'm incapable of designing my own" Funny, because too me that seems like the whole point of MVC: To have a one-size-fits-all "architecture" to shoe-horn your business logic into. But then again I never really understood the point of MVC. It seems like a somewhat nice fit for GUI applications, but that doesn't mean you should use it for everything. The real takeaway is to decouple and abstract to the point that makes sense. Not too much and not too little.
- etler 13y agoI've been doing something similar to this with Backbone. Backbone has Models, Views, and Events. I put the "Operations" in the Model and Collection extended classes, so the login operation is performed by the User model. So I would call something like currentUser.login(credentials).
- tn13 13y agoI once presented Rails as an example of "MVC" in my software architecture class the the Prof. kind of ripped me apart saying either Rails it not MVC or I am misinformed. After a lot of research I realized that the true MVC architecture is not something that Rails implement. In MVC the views are updated when models change without the controller in between. Something like YUI App framework is true MVC in that sense, but not Rails.
- rubiquity 13y agoThe original MVC was invented in the context of a fat client which were desktop-esque applications back in the day. In the context of the Web and HTTP (which is a stateless protocol) MVC had to be adapted to fit this context. While your professor was right he's also a moron for being overly pedantic and ripping you apart.
- dhimes 13y agoHe thought about it deeply and learned something, though, so +1 for the prof.
- Chris_Newton 13y agoIn the context of the Web and HTTP (which is a stateless protocol) MVC had to be adapted to fit this context. Isn’t this a bit like saying that in the context of mountain rescue (which involves rough and steep terrain) cars have to be adapted to fit? Cars simply aren’t useful in that situation, and while helicopters are great, they aren’t cars any more. Moreover, the innocent belief of a five-year-old that a helicopter is just like a car but with some rotor blades on top does not mean that people with engineering degrees should start calling them cars because the meaning of the word “car” has been diluted.
- jcampbell1 13y agoEvents are an anti-pattern in my opinion. They allow the ultimate flexibility, but in essence are worse than global variables. With events, it is very hard to reason about behavior. Objects respond to messages from "god" at arbitrary times in an untestable way. Whenever I am tempted to use an event, I ask myself if there a way to solve this problem with delegation or data-binding or some other solution. I fall into the event trap all the time, but when I come across an event-free solution like Angular/Ember or using delegates in Obj-C, I am immediately sold. Any pattern that promotes events as first class ways to communicate are a recipe for hell. Every Backbone application I have seen is nothing but a messy event hub that mangles arbitrary DOM events with arbitrary Model events, and there is a metric shit ton of code that just re-invents data-binding and delegation.
- alttab 13y agoNot to mention people like to "refactor" event names, without telling other teams that hey, all the events you listen to are no longer going to fire. Add to that its all JS, and you're hosed. Good luck maintaining your selinium tests.
- vorporeal 13y agoThis is the fault of your implementation, not the pattern. Event types (names) should be enums, not arbitrary strings. This makes it very easy to change the way the code reads if the meaning of the event slightly changes, and equally easy to obfuscate the event key in a production build.
- alttab 13y agoYou would need a static js compiler to type check the enum. So that's an extra step. This doesn't happen in Java or C, but browser based event models (the topic of the post) are almost always strings. Most front end shops choose this implementation. You could add that step to your build, sure, but in. Lot of cases the app is already interpreted so there is no "build" per se. Who else has seen this?
- fleitz 13y agoInner-platform effect in the land of nouns. Most programming languages already have operations, you don't need to tack them on as objects, objects generally perform one of these operations when passed a message. 'events' are generally known as 'messages' and are again built into the language. So now we're left with MV, we just need some sort of object that can send/receive messages from views and models. I think I'll call this object a controller.
- SupremumLimit 13y agoI think you make a good point, but there seems to be more to the OP's events and operations than you suggest. The 'events' are implied to be broadcast versus 'messages' which are sent to a particular object (i.e. point-to-point) in languages that I know. The OP is also suggesting a hierarchy of 'operations', with sub-operations communicating with the parent operations. I don't think this maps directly onto language features (again, in languages I'm aware of). I'd be interested to hear which languages you had in mind, and some more detail on how you envisage the mapping to language features.
- fleitz 13y agoAs for operations communicating this is generally known as a return value. Parent operations and sub operations is just cleverly disguised procedural programming. It sounds like half procedural programming, half partial application. 'Events' sounds alot like [NSArray makeObjectsPerformSelector] / KVO/KVC / Multicast delegate. Honestly, the more I think about it the more MOVE sounds like functional reactive programming.
- SupremumLimit 13y agoThanks, I haven't heard about multicast delegates before, and I need to learn more about FRP.
- dustingetz 13y ago"You have models, which are nice self-contained bits of state, views which are nice self-contained bits of UI, and controllers which are nice self-contained bits of...What?" Business logic
- mgkimsal 13y agoAmen. Except... the current trend I'm seeing/hearing is "nothing in controllers". There seems to be some hatred of controllers controlling anything.
- neeleshs 13y agoThe reason is that the code in controllers tend to be view specific in practice, to the extent of projecting view specific models. If you wanted to expose your business logic as APIs, you are better off either writing controllers view agnostic, or pushing down the business logic to something else.
- TylerE 13y agoI think there is a certain amount of "those who do, do, those who can't, teach" going around in the framework space. To-Do List apps and Photo Galleries don't have business logic.
- dustingetz 13y agoTodo lists do have business logic, but the logic is so simple that one might not notice when it gets coupled to the views. so you can get away with coupling things like "MV-whatever" or MVVM for apps up to a certain threshold. Facebook is an example of an app well past that threshold, so we should probably listen to them when they talk about their new DOM management library, Facebook React.
- rgbrgb 13y agoOne of the big ideas for me was that the controller is the least reusable, most application specific piece. With that in mind, keeping the bulk of the business logic and view logic in highly testable and reconfigurable models and views makes a lot of sense. I think of a controller as a mapping between model and view -- it takes internal state and pipes it to some views then takes external stimuli and pipes it to some models.
- moneypenny 13y agoIsn't this just another "Problem Exists Between Keyboard And Chair"?
- volokoumphetico 13y agocan we see a node.js framework with MOVE principles?
- smoyer 13y agoI think there's an easy answer to the question of what the controller is - it's the business logic. My main problem with the MVC pattern is actually related to the model and view communicating directly. I started using the MVP pattern and then switched to passive view (http://martinfowler.com/eaaDev/PassiveScreen.html http://martinfowler.com/eaaDev/PassiveScreen.html) to eliminate as much code (and therefore testing) as possible from the view.
- tieTYT 13y agoNo that's what the model is for. The controller is just for handling framework specific input. It takes the framework specific part, puts it in a form that the business logic can understand (eg: business logic shouldn't even know what a mouseEvent is), and hands it off to the model's business logic to handle.
- rgbrgb 13y agoFor those interested in this stuff, Apple has some really nice docs on their version of MVC: https://developer.apple.com/library/ios/documentation/general/conceptual/CocoaEncyclopedia/Model-View-Controller/Model-View-Controller.html#//apple_ref/doc/uid/TP40010810-CH14 https://developer.apple.com/library/ios/documentation/genera...
- ffrryuu 13y agoAngularJS is the future.
- solox3 13y agoWe built a prototype app using AngularJS. For our specific usage of AngularJS, while we achieved our goal with the least LOC, its performance is so poor [on mobile] compared to Ember.js, CanJS and MarionetteJS that it was certain that AngularJS is indeed designed for the future, but not the present.
- SkyMarshal 13y agoIf you did any kind of systematic comparison of those, write a blog post and post it here. I bet it would get a lot of discussion. Angular's mobile performance is very interesting, but not something that seems to have gotten much attention yet.
- ffrryuu 13y agoThat's because you are doing it wrong. You need to understand the digest cycle and what triggers it. You're triggering digest unnecessarily + you most likely have full object comparisons. One of the thing with AngularJS is your team needs to have stronger CS fundamentals compared to other frameworks.
- creatrixcordis 13y agoWho cares what you call it? As long as it does what i need. Models, Workers, Controllers, Views, Events, Masks, Filters, Actions...
- ph4 13y agoCan someone provide a basic introduction to the concept of MVC, for a beginner?
- MereInterest 13y agoBasically, you have your program in three parts. Model, view, and controller. The model is the meat of everything. It knows the system, it interacts with other programs, it determines everything. The view is what gets shown to the user. The controller is what the user interacts with. Both the view and the controller should be as minimal as possible, only serving to relay information between the model and the user.
- e12e 13y agoAnd one place that is easy to trip up, is that you'll probably want to model your data, eg do normalization. That is your applications data model. But that is not the same as the model in MVC. The "MVC-model" of a bank account is an account number with a balance attached: the data model of an account is a series of credit/debit transactions that can be summed up to a current balance.
- sklivvz1971 13y agoTalking about an architectural pattern without specifying its applicability or limitations or context is just completely wrong. In architecture it's not optional to proceed as follows: 1. describe a problem, 2. describe a solution to the problem They don't do that. This is a classic mistake: describing a solution and looking for a problem to solve. Don't do that! Furthermore, MVC is used because it's widely applicable to a bunch of problems and contexts - with its pros and cons, clearly. It's actually a very rare thing for a pattern to have such a large sphere of applicability. So, no, you don't throw it away just like that. It doesn't make any sense. Sure, there are other patterns that work better in some very specific context. CQRS is an excellent pattern for building NoSQL databases for example. That doesn't mean it should be applied to any random problem!
- AznHisoka 13y agoI totally agree. Also sometimes I feel engineers spend WAY too much time worrying about architecture of CRUD. I mean, MvC, non-MvC.. who cares? Adopt one and run with it. Then spend the rest of your time about crucial technical problems(ie semantic analysis, machine learning, spam detection, whatever)
- darylteo 13y agoWhy is this new in 2012? The "event" component is generally implemented using the Observer/Listener pattern in Java and has been done like so for yonks. The most "modern" concept he alludes to in that section is the idea of everything being modelled as operations (and sub-operations) which is pretty much Command-Query-Responsibility-Segregation. This obviously is not convenient in terms of web facing applications. Don't forget that web pages are intrinsically static which means your model has no way of pushing events to your view. Unless we (in 2013) are suddenly advocating that every site now should be using WebSockets (Just as bad as using PostBacks in ASP WebForms... unless you are writing a client-side application)? And lets not forget that each web application endpoint (HTTP_METHOD + URL) is in itself already an intent/operation described here -> GET = Give Me Information. POST = Mutate Information. In any case, MVC isn't fully dead as it has evolved into MV(C)VM instead. Instead of the View getting the data from the Model, the Controller gives the required information to the View.
- sklivvz1971 13y agoMaybe you mean "devolved". MVC is alive and kicking where I sit. Instead I constantly see the passing corpses of MVVM and CQRS projects... Honestly, not trolling - this is what I have seen for many years.
- darylteo 13y agoWell it depends on how people are using it I guess? ;) just because there are plenty of MVVM/cqrs projects that have failed doesn't mean that mvc is more successful... One could propose that devs are more familiar with the steward of traditional architecture? Pretty much all iOS projects are MVVM - See UITableView. AngularJS is arguably MVVM: in this case the views are databound to the view model which is held by the controller, which is essentially the "Events" component. Additional Edit: All MVC Java Swing apps could arguably be classified as MVVM -> all your JComponents are all... MVC! Which really leads me to think that MVVM is really just nested MVCs... perhaps =)
- sklivvz1971 13y ago
- kapv89 13y agoYou know what its time for ? To go back bit, beyond the patterns, read "A Pattern language" by Christopher Alexander. Understand why those patterns become the way they are, and build software that makes as much sense as real world buildings. Things that are much more costly than software to tinker with. Given how much complex shit is becoming today, imposing any fixed label on how we devs build things would become very restraining very quickly.
- vegasje 13y agoThis is quite amusing, as it was one of the biggest complaints I had when coming to an RoR shop from a Java shop (please don't immediately take this to mean that I advocate Java over anything else). In my Java shop, we used the service pattern. We had our views, our controllers, our models (which were simply meant to hold data), our services, and our data access objects. Services performed the business logic, and data access objects interacted with the database. This pattern worked extremely well for every application we developed. Entering the RoR world, I quickly found that most developers forget about all the lessons we learned back when we used other languages, and are repeating the quick-and-dirty mistakes we already corrected.
- deleted 13y ago[deleted]
- knappador 13y agoHave definitely had an excellent experience using an experimental MVC setup in Kivy. Can't chip into any MVC death exclamations. First I should mention that Kivy uses data-binding liberally. It's not events, it's publisher-subscriber where bound functions receive the changes as their arguments. This fixes many things, but Kivy uses a widget tree. Trees are great for reasoning about context, scope, relationship etc between graphics elements in layouts. Trees are also an awful topology when something has a relationship to an element in another branch. The controllers as I'm using them are globally visible and thus don't need to be passed. This would pollute namespaces except that a minimal number of controllers will recreate the topology of the problem space and not in tree-space. The whole application can see "out" of the 2D tree into a graph that connects things with many fewer connections. These few controllers have tons of logic, but it's all program. There's very little related to how widgets display themselves, so this fat code is also very high-calorie, rich or whatever. Fat controllers make me happy. My program, the part that I think of as the program, exists all in one place and the bits that control how everything looks all belong in the tree. Widgets don't send events to my controllers often. Occasionally it's easier to reason through a problem using the property/data-binding system, but more often the data already exists in the on_press callback of the widget or whatever and there's no need to secondarily send it through more sub/pub plumbing when I can just call a function of my global controller on the data. I'm busy getting my code cleaned up and contributed. It has really saved me untold time even in it's nascent stages because of the fundamental topology conveniences.
- methodin 13y agoBlindly picking a design pattern before you develop your application will always be bad. Don't do it. If you do be prepared for tired legs because the chase to find a better one will be never-ending.
- Nekorosu 13y agoThe author's idea of moving events into the name suggests a poor understanding of OOP in general (with messages/events being the basis of object oriented approach). Ok, maybe he is talking about some special implementation of events but there are a lot of GUI oriented MVC interpretations which use some special events/signals implementation without trying to put it in the name of the pattern/framework because events are a common part of GUI domain then it suggest a lack of experience. Without the E in the MOVE we have just MOV. Let's talk about Operations now. There are several MVC frameworks which use different names for the classes related to controllers (for example Commands). Some implementations let you compose them. They usually live inside controllers _package_. Do the authors of those implementations rename the C into somethings else? No! There are some cases with different names (think MVP, MVVM) but they have a different form of relationship between the three parts of a pattern. Let's look at the MOVE's diagram. We actually have the original MVC diagram with a strange quirk: the controller (made from Operations) can directly affect the view. Now we have a problem. There are two places in this architecture where the view gets updated: the view can get events from the model and update itself (oh horror! it's active view!) or it can be directly updated by the Operation. This doesn't solve anything but makes programs built with this architecture harder to reason about and debug. There are two ways to fix it: 1. remove direct changes on view from controller then we have just MVC 2. stop sending events from model to view and send them to controller then we have MVP In the end I don't see enough justification for calling it something new and using a special name for this particular pattern. Also this pattern is broken. Talking about the article itself, it's neither academic, nor pragmatic and looks like a blatant attempt at self promotion. It's a bullshit which puts words over meaning and misleads beginning programmers.
- tikhonj 13y agoIf you want a nice alternative to MVC (or event-based systems in general), take a look at functional reactive programming (FRP). Instead of modelling time implicitly using mutable state and callbacks, FRP provides time-varying values as first-class citizens. I've found FRP to create much neater code for most of the UI tasks I've worked with.
- e12e 13y agoThanks for that, made me finally go and look up FRP, finding this (again, I think): http://elm-lang.org/learn/What-is-FRP.elm http://elm-lang.org/learn/What-is-FRP.elm It's a nice abstraction when(if) the alternative is to work with the DOM, javascript and browsers -- but the examples would be trivial in a smalltalk-like environment: The various labels would reference the mouse, and on redraw they'd use the current value. So I'm not sure it's so much an alternative to MVC as it is a fix for our broken environment (the browser+dom+i/o as a GUI system).
- eurekin 13y agoBookmarked, thank You. Mind sharing a bit about Your experiences? Are the initial investments cost high or low? Are there any drawbacks which inhibit any other functionality (what to do to avoid memory leaks)? Is the end-product really mantainable? Does compose easily? I'm eager to learn :)
- dep_b 13y agoSounds like my reaction on Apple's version MVC: "Do I have to stuff ALL of this stuff into a Controller???". But if I use something like LESS with a ORM or Microsoft MVC with EF and nice IOC and builder patterns all of a sudden the controller does nothing else but evaluating the request and giving the right kind of response.
- Aqueous 13y agoIndeed. Even if you are not using an ORM, controller functions should be short. Functions are just not supposed to be 30+ lines. If my controller function isn't less than 20 lines of code I look over it and figure out what code can be placed in a library or a model or a view. The controller function should do very little.
- tantaman 13y agolooking at the comments, few programmers even understand MVC yet. Maybe it's just a lack of understanding that causes people to think it's time to MOVE on...
- bdcravens 13y agoA problem is that a lot of developers equate MVC with magical framework that does a lot for me and just happens to have folders named "models", "views", and "controllers" where they put stuff. This can be Rails, but is common in other frameworks as well (even if the names change) I found working with a barebones MVC framework a bit enlightening. One is Framework One by Sean Corfield. It was originally written in ColdFusion, consisting of a single class (CF calls them "components") with very little magic. (it does do things like implicit views and queue up service/model calls with an event lifecycle, but in general, nothing happens that you don't have direct control over) He's also written a version for Clojure, though it's less mature https://github.com/framework-one/fw1 https://github.com/framework-one/fw1 https://github.com/framework-one/fw1-clj https://github.com/framework-one/fw1-clj
- mason240 13y ago>O: Operations encapsulate everything that your application does. >E: Events are used to join all these components together safely. So my controllers are just there to work with the repository/service layers. This is just the next logical step after straight MVC and is already a pretty well established pattern. My understanding of MVC is the context of web development.
- eurekin 13y agoI'm very pleased to see the GUI topic mentioned here. For all of those who seek a UI advise, I have a tip. I have done a lot of pondering about GUIs since I began programming. I ended up in mantaining a 12 year old project, with more than 400 individual forms (that's for a single client, we've got 4 more). Damn, I was lucky. The project really blew my mind! It crushed most of the assumptions which I made while reading articles or developing toy applications. And here's the thing: It uses most of the "bad practices", "anti-patterns", or however the internet calls today the "I was bitten once and didn't find the way out" thing, in it's codebase and still is ridiculously maintainable. With very much likelyhood it will survive another 12 years. Partly, because of the contract, but the point still holds. :) So, my bold advice: just ignore all the naysayers and make up your own mind. Event's are bad? It they solve a problem giving another one or two in exchange, there most probably is another solution fixing those two too. And while the problems never end, at one time you end up with a framework that covers 90% of needs, correctly. "Yeah, we can't notify the remote client about the update on the model, when it's in a form rollback phase and when it has at least one two-dimensionally time tracked attribute. It isn't possible, because it interferes with the data history stack. We should not have used events at the very beginning at all." Damn, that's a tough problem. Wait, what does your UI do !? At the project I'm working on it took a lot of work and at least one PhD thesis to get it where it is today. I can't give out all details, but if anyone's interested, there are few open sourced parts. But You will find plenty of good libraries already. I also made a simple JAVA Swing project on github using some of the gained knowledge. If anyone would find that interesting, just leave a comment. I hope such good UI articles come up more often in the HN feed. And please, do write as much technical details as possible.
- franze 13y agowhenever i read a headline like "X is dead" (whereby X is a technological concept or even a piece of technology) my first reaction is, that the author has probably a very limited understanding of the technology at hand (or about the underlying concepts of that technology) * vinyl records are dead, http://www.nytimes.com/2013/06/10/arts/music/vinyl-records-are-making-a-comeback.html?pagewanted=all * CDs are dead (yes, they are, optical data storage isn't) * flash is dead (but still, most videos are still streamed via flash and a gaming company i know prototypes all games in flash...) * SEO is dead * social media is dead * java is dead * progressive enhancement is dead * print is dead * native is dead * desktop is dead * ... * ... * mvc is dead lets call it "Franz's law of deadliness"
- peterhunt 13y agoI think the key takeaway is that your view is read-only. An abstraction that's great for reading isn't necessarily great for writing.
- ttty 13y ago"A common operation for applications is logging a user in. It's actually two sub-operations composed together: first get the email address and password from the user, second load the "user" model from the database and check whether the password matches." Why do you need to have Operations when that code could be into the model? The view tells the model: login(username, password); and the model just do that and saves the state in it's model. So there will be models that contains state and models that contains data... Why add another layer?
- zamalek 13y agoSounds very similar to CQRS, but from a UI perspective. Interesting. I wonder how this applies to stateless systems (HTTP) though. It seems like it's really geared toward thick client applications.
- Leander_B 13y agoNot talking about the content of the article, but this 2-column style of reading is not very pleasant for the web.
- hawleyal 13y agoMVC is dead, long live MVC.
- rhengles 13y agoThe reports of the death of MVC are greatly exaggerated.
- akrymski 13y agoActually that's what MVC is supposed to be. Whether you use events, callbacks, delegates, or dirty checking really doesn't matter. Views inform the controller, controller updates the model. Events and Operations are the Controller, but lets not shove MVC into some specific implementation based on events, it's an abstract pattern for software architecture, not a framework.
- asdasf 13y ago>Views inform the controller, controller updates the model No, that's not how it is supposed to work. The idea that everything has to pass through a controller for no reason, and that we need a controller per view, is the rails bastardization, not actual MVC.
- joeheyming 13y agoI like to think that its not model view controller, but instead model-view-behavior (or the strategy pattern) Events are a given. Models can fire/handle events, views can fire/handle events. The behavior/strategy pattern is just a bunch of singleton objects that know how to mediate between the view and the model. Sometimes the behavior pattern handles events (as a strategy), but it doesn't fire events (only the model and view can do that). The model knows how to generate the behavior. The View contains the behavior and asks the behavior questions with the model. This separates responsibilities nicely in my opinion.