14 ms·

MVC is dead, it's time to MOVE on (2012)

267 points by pcr910303 7y ago

bilekas 7y ago
Maybe at 2012 to the title.. And I can say for sure it's not dead! Even in 2020 ! :) But I do like the extension with MOVE.
deleted 7y ago
[deleted]
adamnemecek 7y ago
I think that ecs is the thing that will kill oop. https://en.wikipedia.org/wiki/Entity_component_system https://en.wikipedia.org/wiki/Entity_component_system
- jcelerier 7y ago
  so we hear since 2008
- EamonnMR 7y ago
  I took a very dogmatic approach to ECS on a project[1][2] but I'm not sure it ended up easier to read or write as a result. [1] https://github.com/EamonnMR/Flythrough.Space/blob/master/src/ecs.js https://github.com/EamonnMR/Flythrough.Space/blob/master/src... [2] https://github.com/EamonnMR/Flythrough.Space/blob/master/src/gameplay.js https://github.com/EamonnMR/Flythrough.Space/blob/master/src...
  - adamnemecek 7y ago
    I think that js me not be the best language for it.
- bcrosby95 7y ago
  I like ECS when designing certain kinds of systems but I'm not sure how relevant it is here. I'm also not sure it would be particularly useful for your average webapp.
- 32gbsd 7y ago
  OOP is hanging on for dear life. ECS has its niche. But why do you want OOP to die?
  - ch1lang0 7y ago
    For many reasons: https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7 https://medium.com/better-programming/object-oriented-progra...
    - 32gbsd 7y ago
      I get it but some programmers are really productive in it.
- zelly 7y ago
  At the very least it proves you don't need OOP to do UIs. It is more difficult to implement ECS (there isn't a long tradition of it and libraries like MVC has) but well worth the effort. It's more suited to native UIs than webapps though.
danso 7y ago
Given that this article is 8 years old, did MOVE catch on?
- cbhl 7y ago
  I still see MVC in $dayjob, but it looks like React/Redux have helped a lot. A central module manages state and takes operations on that state. The desired view hierarchy is computed as a pure function of state. A library uses diffing to apply changes to the concrete implementation of the views (say, the DOM, or a native windowing framework).
  - k__ 7y ago
    Since React got hooks it could be interpreted as MOVE. Components being Views And Hooks being Operations
  - tyfon 7y ago
    MVC is still heavily used for instance in ruby on rails.
- chrisco255 7y ago
  I'm not sure this pattern as described is comprehensive, but the move away from MVC to other event-based patterns like React/Redux, Elm, etc, clearly did happen. MVC of course still exists in the world.
- wsc981 7y ago
  This article is the first one I’ve read on MOVE. On the other hand I’ve seen multiple in the past few years on MVVM and VIPER, just to name two MVC replacements. My guess is MOVE isn’t used much.
mlazos 7y ago
I feel like his answer to what goes in the controller is answered by his acronym MOVE. Operations and Events go in the controller. It initiates the state changes in the model and the view. As an aside it’s cool to see something like MVC staying relevant, it alludes to there being design patterns that are simple and fundamentally useful in some areas.
bcrosby95 7y ago
Events are how MVC was used before the web world came around. The whole point was your controller listens to model and view events so everything is updated real time as the model changes and the user interacts with the UI. The web is a bastardized version of MVC due to the lack of interactivity and state when compared to a desktop GUI application. That aside, lots of people in the web world have a sort of "Operation" layer in MVC but call them a "service". Deciding to use events is another architectural decision some people make even in web MVC. But you can take or leave any piece of this stuff and I feel like you don't need a new acronym for every combination of architectural decisions.
- rumanator 7y ago
  > Events are how MVC was used before the web world came around. The whole point was your controller listens to model and view events so everything is updated real time as the model changes and the user interacts with the UI. The web is a bastardized version of MVC due to the lack of interactivity and state when compared to a desktop GUI application. It seems you're mixing up implementation details with the actual design pattern. It makes no difference if you implement MVC with events or objects or imperative programming. The only thing that matters to a design pattern is the pattern, and the pattern is how three components interact to drive an user interface.
- daotoad 7y ago
  BILASM! But I Like Acronyms So Much. Web "MVC" rarely was really MVC. Except that it changed the meaning of the term. https://wiki.c2.com/?ModelViewControllerHistory https://wiki.c2.com/?ModelViewControllerHistory https://wiki.c2.com/?WhatsaControllerAnyway https://wiki.c2.com/?WhatsaControllerAnyway
- alexis_fr 7y ago
  Then the web came, and we have the MVCS+JS+REST mess. Explanation: Model: The Javabean View: The HTML Controller: Whatever Java code that calls the service layers, Service: The services in the lower layer, JS: Since you have js with your HTML, then the JS also acts kind of like a controller for complex parts of the UI, REST: Well that’s a second entry point to your service layer, to which the JS transmits Events (as in MOVE) that cannot be managed by a page reload. It’s a back channel unknown to the Controller. So perhaps React has a point ;)
threatofrain 7y ago
These are all minor variations of the same ideas.
post_below 7y ago
I don't see anything wrong with MOVE... but why does MVC need to be dead? It's such a perfect representation of the coder trope of loudly proclaiming that this new thing I found makes everything else obsolete. Eight years later, MVC is still miraculously not dead!
- deleted 7y ago
  [deleted]
- 0xdeadbeefbabe 7y ago
  What does this mean for waterfall? Is it alive again? It's kind of an insult to death.
  - barbecue_sauce 7y ago
    Waterfall is a myth.
    - Jtsummers 7y ago
      If only. I was surrounded by it for the last decade and it works as badly as expected.
      - moron4hire 7y ago
        I think what GP is saying is that what people call "Waterfall" is not what Waterfall was originally defined as. https://en.wikipedia.org/wiki/Waterfall_model#History https://en.wikipedia.org/wiki/Waterfall_model#History
    - logfromblammo 7y ago
      My cousin's boyfriend's sister went up to the waterfall, and when they found her body 12 months later--after delivery phase--she had been completely burned out from the inside. And there was this thing... that nobody wanted, that didn't work right, just sitting there next to her. Nobody wanted to touch it. So some guys from the federal government came and picked it up with tongs, and said they'd put it in the Source Control Repository facility out in New Mexico, so it couldn't hurt anybody else.
bugeats 7y ago
Turns out Conrad Irwin was right, but didn't take it far enough. Merge together "Events" and "Operations" into one thing, call "Models" just "state" and you've got Reactive Programming, which appears to have proven itself as the best known way to manage UI state complexity.
- coldcode 7y ago
  Proven in what way? After almost 4 decades in this business, nothing is ever proven. For anything one person says is beyond discussion obvious, another person does something completely different, and gets the same benefits. Every generation comes up with new ways to do things, but nothing has even been clearly better to everyone all the time in all circumstances. You constantly have to evaluate everything that comes along, and see if it's better for you, your team, project, company or industry. Silver bullets are for vampires and the Lone Ranger.
  - hyperpallium 7y ago
    It is "proven", not in a mathematical sense, nor a scientific sense, nor an engineering sense or even a legal sense. It is proven in a javascript sense.
  - real_eng_ 7y ago
    Aren't silver bullets for werewolves?
- goatlover 7y ago
  By "best" and "proven", you mean most popular way in the JS/TS world.
- marcosdumay 7y ago
  Reactive programming looks like a very good model for UIs, but I wouldn't claim anything is proven. I am not sure we even got any implementation that is more convenient than event based UIs from a couple of decades ago. It does certainly looks like such implementations exist, they feel just within grasp, but there is a long way into "proven".
tracer4201 7y ago
MVC certainly isn’t dead. My current team supports a system implementing MVC attributed over $65MM a year and is in still active feature development. Sensational title at best.
_bxg1 7y ago
Needs a (2012) label
deleted 7y ago
[deleted]
brobot182 7y ago
MOVE is dead, it’s time to JEJSNEBDIRKEBSBC on
riazrizvi 7y ago
MVC is understood to be the primary partition of an application's architecture. It does not obviate the need for further code organization, which is done in all parts, Model, View and Controller. When the author says "controllers are nice self-contained bit of...[what I don't know?]", and they use that as the justification to throw away the paradigm in favor of another with Model-View-Operations+Events they show they don't understand this. Worse the proposed paradigm does not then collect all the controller code in one place, so the overall lifecycle of the application would be harder to piece together from Operations+Events modules without an overarching Controller to govern the two of them.
- jkoudys 7y ago
  Yeah - build out a graphql service on top of existing models, and you'll get a pretty clear picture about what the C ought to represent. You can find plenty of situations where the implementation of any of those letters is extremely thin: lots of services where the View is almost nothing (often just a JSON serialization of some of the models), or where the models are very thin. It boils down to a weirdly common, but deeply flawed, view that all the letters in your abstraction's initialism should be of equal complexity. With Views, it seems to be easy for devs to understand that there is significant differences in the underlying approaches: are you organizing your views into page templates, serializing for some special client to consume, building components that compose one another, etc. I don't know why we can't wrap our heads around Controllers also having different approaches.
- gonational 7y ago
  +1 so much. In my opinion, the mistake the OP makes is in not realizing that the dogmatic application of a design pattern is the fundamental issue to begin with. So then the solution offered is another design pattern that can be dogmatically followed. If we know that you need a UI (view), and we know that you need to represent your data in an expressive manner (model), and you need something to pull those things together for a user, a router and controller does not automatically come to mean “put all your logic here!” Instead, it means something more like “here’s where you can tie things together in whatever way makes the most sense for your application”, which lets you e.g., use AOP to handle auth (like Django decorators or middleware), delegation to a service like a REST API (e.g., Django REST Framework), or basic one-off views for simple tasks. If something like this MOVE was to become the next big thing, I think there’s a good chance we’ll be rewriting a lot of projects to use MVC in 10 years. Don’t blame bad code on a proven and very flexible design pattern that solves a very real problem. Blame bad code on bad coders.
danielovichdk 7y ago
Everyone who has done MVC long enough would also know that the controller is the very thin layer where services are injected and models are passes to. The controller should have and only have logic which absolutely cannot be moved to a service layer. Too many developers use controllers as part of their logic layer, instead of simply using it as a router for where models should be directed on a service level.
- bryanlarsen 7y ago
  Every Rails app I've seen has been MV, not MVC. The app/views directory contains the template part of the view code and the app/controllers directory contains the meat of the view code. You can tell that this is happening because there is a 1:1 mapping between foos_controller and views/foo. There's nothing wrong with MV code and it's a great paradigm for a simple app. But lots of rails apps are no longer simple...
  - chao- 7y ago
    In a Rails context, there are a dozen pattern-esque buckets that folks advocate putting non-template, non-persistence, non-validation logic into. Yet as often as seeing benefits from "service objects" or similar generic, I have also seen benefit from adding an actual View layer. Rails has done so much to move application development forward, but if I had two nits to pick, they are the same today as they were in 2007: 1. Assuming/requiring a folder structure named after the pattern an object fits, rather than conceptual domains of an application. 2. Naming its templates "views", and not hinting to people that presentational logic should belongs in a full instance of a class, rather than in-line in template code. Partials help but insufficiently, and helpers have too many gotchas. The sprawl of gems that attempt to address #2 this is evidence of its impact. While I appreciate the "omakase" argument, it still leads a lot of smaller or less-experienced teams to make a big mess before realizing they have better options. Anyway, as often as I see "service objects" solutions helping a team tame their Model-View-Mess, just as often I see the solution lying in adding an actual View layer (or adding Presenters if that fits better). I like ActiveRecord, ActiveRecord::Relation, ActiveSupport, and all the other things people tend to gripe about in Rails-land, but the specific folder structure has always been a stick in my craw.
catpolice 7y ago
I like this a lot, not as an alternative to MVC but as a kind of conceptual refactoring of the same ideas behind good MVC implementations that's very easy to explain and doesn't have as much ambiguity. I've posted a version of this comment before, but my main problem with MVC isn't that it's a bad architecture, just that in practice there's a huge amount of disagreement about what MVC (or MV* more generally) actually _is_, which can lead to confusion or weird/bad hybrid implementations. I tend to use the "model" and "view" concepts a lot when discussing architecture, but in my experience it's almost always a mistake to try and reference any specific MV* pattern for explanatory purposes - it does not have the effect of making the discussion clearer. The issue is that there isn't actually a consensus about what constitutes the definitional features of these patterns, especially when it comes to how the concepts involved actually translate into code. For any sufficiently notable discussion of an MV* pattern, you're going to find an argument in the comments about whether the author actually understands the pattern or is talking about something else, and typically the commenters will be talking past one another. Note that I'm NOT claiming that there's anything wrong with MV* as an architecture, or your favorite explanation of MV* - it may be perfectly well defined and concrete and useful once you understand it. The issue is a feature of the community: lots of other people have a different (and possibly worse) understanding of what MV* means, so when you start talking about it and your understandings don't align, confusion arises. Getting those understandings back in alignment is more trouble than the acronyms are worth. I've seen enough conversations about concrete development issues suddenly turn into disagreements about the meaning of words to realize that nothing useful is conveyed by mentioning MV* and assuming anyone knows what you're talking about - it's better to spell out exactly what you mean in reference to the code you're actually talking about, even if you have to use more words. I like this MOVE scheme because it seems to me to divide up the conceptual space at the joints in a way that's relatively hard to misunderstand, and it seems a little easier to see how to directly relate those division back to code.
- mtzet 7y ago
  I feel the same way about most design patterns. They're useful to provide vocabulary, but too generic to provide any actual guidance.
arbuge 7y ago
> MVC is a phenomenal idea. 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? The implication is that what goes into controllers is not well-defined. But if what goes into models and views is well-defined, as the author agrees, then defining what goes into controllers as everything else is actually a precise definition.
- Marazan 7y ago
  Trouble is what goes into the models is not well defined at all.
omarhaneef 7y ago
Controller = Operations + Events Ben Jaffe of Udacity cally is MVO where O = Octopus. Basically, as the author points out, Models and Views are relatively well defined, but the Controller can be anything. Octopus, ViewModel, or in this case Operations and Events. I do think Operations and Events are clear, but 1. are they comprehensive and 2. do they organize the code more intuitively? It seems like you would want to put them in the same place since Events will trigger operations that operate on the model and the view. Sort of like a controller... oh, wait.
Digitalis33 7y ago
FIFY Operations ^H^H^H Functions A common function for applications is logging a user in. It’s actually two sub-functions 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. Functions are the doers of the MFVE world. They are responsible for making changes to your models, for showing the right views at the right time, and for responding to events triggered by user interactions. In a well factored application, each sub-function can be run independently of its parent; which is why in the diagram events flow upwards, and changes are pushed downwards. What’s exciting about using functions in this way is that your entire application can itself be treated as an function that starts when the program boots. It spawns as many sub-functions as it needs, where each concurrently existing sub-function is run in parallel, and exits the program when they are all complete.
- Digitalis33 7y ago
  "What’s exciting about using functions in this way is that your entire application can itself be treated as an function that starts when the program boots." HN, rediscovering main()
ninju 7y ago
A bit off-topic but I like out the page is responsive to browser width. It auto-magically creates columns as space available
- 2wrist 7y ago
  I really really like that part. Three columns on a widescreen monitor is really really comfortable! Nice site!
cfv 7y ago
My biggest issue with MVC is that in my experience it always ends up having the C being glue between fat Ms and fat Vs, with multiple views ocasionally growing tendrils between one another. As in, not the pattern, but the real-world usage of it. Development constraints always end up corrupting the pretty pattern in ways that make the current problem at hand easier to solve, and this de facto architecture IMO never ends up looking like proper MVC for me. I want to say I like Action-Domain-Responder better, but I haven't seen any real-world implementations of a ROA with it yet.
kazinator 7y ago
> the problem with MVC as given is that you end up stuffing too much code into your controllers > [Under MOVE, e]vents are used to join all these components together safely. The problem with events is that you put all interactions into events, creating a labyrinth of ad-hoc protocols. Events are messages, and messages are just methods in disguise: worse ones, that don't have a call stack you can inspect. Under this MOVE, someone will sooner or later hit the problem of wanting the V to manipulate the M in some way that O doesn't support, and will just end up creating some hack whereby a whole chunk of the M state (perhaps all of it) is downloaded via some stream of events, edited, and sent back via another stream of events.
ascendantlogic 7y ago
It's very rare to give any credence to any breathless "X is dead". Do what makes sense for you to solve the problem in front of you. There's anti-patterns but bike shedding over architecture patterns is a waste of time for a large majority of most CRUD webapps with low traffic requirements I'd wager.
zamfi 7y ago
(2012)
DubiousPusher 7y ago
I'll never understand the obsession to have one architecture to rule them all. mVC isn't dead. I set up MVC patterns all the time for small projects where I need CRUD with a sprinkling of custom code on top. It's a great pattern. If it's not meeting your needs that just means it's not a good abstraction of your problem. And yeah, you should probably look for something else.
choeger 7y ago
Now what are operations then? And how are they tied to events. Let us assume a concrete architecture where views are html documents and events are put into some distributed queue. Is an operation a process that consumes events from that queue or is it something more tangible? Are operations data? In other words, are they interpreted? By what interpreter? I think the idea of describing your business system as some giant, distributed, parallel DSL interpreter has some merits. But has it ever been implemented as such somewhere?
fermigier 7y ago
Previous discussion: https://news.ycombinator.com/item?id=4189811 https://news.ycombinator.com/item?id=4189811
tabtab 7y ago
I've found MVC annoying, but everyone goes "everyone else is doing it so we have to do it also". Lemming Syndrome. In team environments it's usually good to standardize "slots" for certain activities. But MVC doesn't fit our work-structure well (Conway's Law). What's good for websites is not necessarily good for data-centric CRUD. MVC tries to cater to both, and does neither well because it has to compromise to make both camps happy. I'd like to see, first, the file/folder location be flexible. If a team wants to store the view together with the model (or view-model) in entity folders, they can. Make the file look-up mechanism more flexible, or at least have a few templates to choose from. Our shop would prefer something like this: Models - model01.code // friendlier names not shown - model02.code - etc... AreaX - EntityY (folder) - - ViewModel.code - - View.code Second, navigation (menus, URL's, and breadcrumbs) should probably be table-lized in the RDBMS so analysts and project managers can change paths and titles and perhaps even role assignments without re-coding. The "path math" of controllers is confusing and hard to debug. Put the damned tree(s) in tables instead so we can do nice reports and analysis of them without digging through verbose code. There was an anti-DB movement in the early 2010's that was wrong-headed in my opinion, so everything was shoved into app code instead. It's time to embrace DB's and use them again for what they are good at. We then wouldn't need controllers, at least not in everyday work. Note: If I say something bad or wrong, please explain in a reply instead of give a hit-and-run negative score. I get better with clear feedback. Thank You.
- blattimwind 7y ago
  Pyramid's resource trees solve the "path math" problem quite nicely, there are some caveats to that kind of design as well, of course (mostly related to enumerability).
  - tabtab 7y ago
    What's wrong with them being in the database? Analysts and project managers can then re-arrange things with fewer coding changes, using CRUD editing screens. One may have to re-project some URL's for the end-user's sake, but that's doable. "Pretty" URL's are not that useful for CRUD anyhow, but since customers expect them (because everyone else has them), they can be managed as an aesthetic wrapper. I should note I'm a fan of the CASE idea of the 90's. It was just that the products were proprietary and too expensive. 90% of most CRUD apps can be attribute-driven. Menus, navigation, page titles, field attributes, etc. can largely be stored as meta-data in RDBMS where they are readily change-able and query-able. Buried in code makes them harder to work with. Over-focus on OOP killed the CASE dream, but I suspect it will come back. RDBMS are good at storing and managing masses of related attributes, code just isn't. (Dynamic Relational would help with attributes that are different or custom per UI widget etc. I wish it would take off.)
PaulRobinson 7y ago
Event sourcing should kill MVC, we just need better frameworks to make it easier to do.
goatlover 7y ago
> Since it was invented however, new programming techniques have become popular. Without closures (or anonymous blocks) event binding can be very tedious; and without deferrables (also known as deferreds or promises) the idea of treating individual operations as objects in their own right doesn’t make much sense. Didn't the Smalltalk team invent MVC? Because I believe Smalltalk in the 70s supported both.
cdcarter 7y ago
Action Domain Responder, anyone? https://en.wikipedia.org/wiki/Action%E2%80%93domain%E2%80%93responder https://en.wikipedia.org/wiki/Action%E2%80%93domain%E2%80%93...
ergothus 7y ago
I've always had a very loose view of MVC. It feels like all the MVC/MVVM/MV(whatever) concepts really are about separating the model from the view, and having something to connect the parts. I've never gotten hung up on the specifics beyond that, but it seems like framework after framework is built on exactly worrying about those details. It's been 20 years - have I been missing out on a crucial details?
Waterluvian 7y ago
I spent just enough time with MVC to experience that there's so many flavours and opinions and confusion and uncertainty. All of that was a smell that: 1. this is a complicated domain. 2. the lack of a very clear coherent "right answer" tells me not to dwell too much on it. I'll see more gains by getting my UIs into production and initiating the feedback loop than trying to get the architecture right. As for item 2, I have absolutely iterated on underlying architecture, non-stop. But I feel I've been immensely successful in never letting that get in the way of shipping early and often and learning the 90% of stuff you can't learn without shipping.
s_dev 7y ago
MVC implemented properly is actually fine. Sometimes it doesn't matter what the rules are just that there are rules because the rules bring order and consistency that allow for quick comprehension of the written code. Heres a modern iOS dev defending MVC: https://www.dotconferences.com/2020/02/guilherme-rambo-mvc-many-view-controllers https://www.dotconferences.com/2020/02/guilherme-rambo-mvc-m...
- marblar 7y ago
  Everything is fine if it's done properly.
dredmorbius 7y ago
MVC: Model View Controller https://en.wikipedia.org/wiki/Model–view–controller https://en.wikipedia.org/wiki/Model–view–controller
soulchild37 7y ago
Lol no
augbog 7y ago
It looks like he just clarified some of the smaller moving parts in MVC but hilariously, he still ends up drawing a triangle for his diagram. It looks like E (events) is simply to illustrate oh yeah some communication is happening between these layers. I think that is pretty obvious? I'm not necessarily putting down what he was saying, but I don't think this is something revolutionary. I think he just dove deeper and expanded.
dang 7y ago
A thread from 2013: https://news.ycombinator.com/item?id=6370343 https://news.ycombinator.com/item?id=6370343 Discussed at the time: https://news.ycombinator.com/item?id=4189811 https://news.ycombinator.com/item?id=4189811 (Links are for the curious; reposts are ok after a year or so: https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html)
GuB-42 7y ago
To be honest, the real pattern is MVW (Model View Whatever). The third thing can be a controller (true MVC), a presenter, a view-model, or, in the case of the article, operations and events. The big deal with all this is that we have a view, usually provided by a UI framework, a model, usually provided by the app developer, and some kind of loose coupling. That's it, the good old idea of separating data from its representation. What you stick between the model and the view is just an implementation detail of your particular framework, optimized for your particular use case.
- aikah 7y ago
  > To be honest, the real pattern is MVW (Model View Whatever). It's not a pattern if it's not clearly identifiable as a pattern, MVC (original) applied to GUI interfaces. ASP.net tried to apply MVC to the web and it resulted in Webforms, which is true MVC, ASP.net MVC ironically isn't true MVC. Like everything in IT MVC eventually became a buzzword thus lost all significance, that's why it doesn't really mean anything anymore since it doesn't describe anything specifically to most people who use the expression.
- bernawil 7y ago
  > The third thing can be a controller (true MVC), a presenter, a view-model, or, in the case of the article, operations and events. Well the article introduces weird new lingo which I don't think is all that great, but whatever. "operations+events" can be equaled to "business logic". Let's keep that separated from the controllers. I want to create a new user via an http request, but I also want to do the same via a console command and since I want to do both things with the same code but one of these shouldn't be returning http status codes, it makes sense this should live in a different layer. The whole events & operations separation in the article don't make sense to me. A "login attempt" as described in the article with a "login attempt" event being triggered by the view and that being picked by a decoupled "operation"? I don't see the value. If the operation needs to check privileges does it trigger an "check privileges" event, wait for another operation to complete? does that operation trigger another event to report the result? Wait a second... this sounds a lot like a convoluted Redux clone. Then you realize the only reason we are not doing Redux in the backend is because we are used to mutable state databases.
skohan 7y ago
MVC is fine. After years experience in mobile development, my main takeaway is that application architecture acronyms in general are over-rated. The most important thing is to separate concerns, and to agree on some sensible structure for managing views and state, and communicating between them. Usually the details of that should arise from the needs of the application, not come top-down from some idea about "the perfect application architecture". Aside from that, everything should just be kept as simple as possible. IMO it actually adds a lot of unnecessary pain and complication to a project when a team is too rigid about which letter of an acronym each piece of code must fit into. VIPER would be an extreme example of this. It should not take five+ separate code files to execute an HTTP request and display the results in a list view.
debug-desperado 7y ago
Hilariously, this is basically the pattern everyone figured out long ago with Windows Forms apps. Model View Presenter with decoupled events that are fired off to any subscribed listeners. Multiple screens and models can be updated as needed. Very easy to do in a C# app thanks to uncluttered syntax for events. Go check out the "Microsoft Patterns and Practices" frameworks from decades ago to see many examples of this.
mygo 7y ago
What’s the point of this? No way of architecting software is dead. Just use the model that works best for the task at hand, including the competencies and preferences of the development team. Everything has its place. Besides, software architecture is not a religion, just a technique.
pachico 7y ago
I have to confess it's the first time I read about MOVE but MVC seemed old news for almost a decade to me. MOVE seems to englobe concepts I work with like DDD, read/write segregation, event source, etc which can all live under its umbrella
interlocutor 7y ago
Nearly all UI frameworks use MVC. That includes iOS, ASP.NET Core, JSP and JSF (both Java), Ruby on Rails, and Django (Python). In fact, it is easier to list UI frameworks that are not MVC-based: WPF, which is based on MVVM and React+ReactRouter+Redux, which is based on Flux. MVVM was invented in order to support 2-way data binding. Inspired by WPF, many early JavaScript frameworks supported 2-way data binding. These days 2-way data binding is widely acknowledged as a poor design as it makes it hard to keep track of how data is flowing through your application. For more on that see [1]. React was originally introduced as the "V in MVC" [2]. Since then it drifted away from MVC in an ad-hoc manner. In part this is because of ReactRouter, which made router a view component (!), and in part this is because of Flux/Redux. The facebook engineer who came up with Flux famously declared that MVC doesn't scale (!!). This assertion was widely challenged, and later she acknowledged that it is bidirectional data flow that doesn't scale [3]. She had assumed that MVC automatically implies 2-way data binding. Redux, an implementation of the Flux architecture then became popular, and became closely associated to React, so much so that many developers believe using React implies using Redux. This is unfortunate because Redux requires tons of boilerplate ("so much throat clearing", as one developer put it), which MVC does not require. [1] https://changelog.com/131/ https://changelog.com/131/ (starting around 0:43) [2] https://github.com/facebook/react/tree/015833e5942ce55cf31aefd0a5c2be8a65ec2daa https://github.com/facebook/react/tree/015833e5942ce55cf31ae... [3] https://www.infoq.com/news/2014/05/facebook-mvc-flux/ https://www.infoq.com/news/2014/05/facebook-mvc-flux/
- acemarke 7y ago
  > Redux requires tons of boilerplate Not _required_. There's both "inherent" and "incidental" complexity around Redux [0]. We've created our new Redux Toolkit package [1] to specifically eliminate the "incidental" complexity and simplify common Redux usage patterns. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. We also just released the official Redux template for Create-React-App [2] to help speed up the process of setting up a new app. [0] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/#dealing-with-complexity https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-... [1] https://redux-toolkit.js.org https://redux-toolkit.js.org [2] https://github.com/reduxjs/cra-template-redux/releases/tag/v1.0.0 https://github.com/reduxjs/cra-template-redux/releases/tag/v...
anm89 7y ago
Step 1: Call thing that people use dead Step 2: ? Step 3: Profit
reggieband 7y ago
One thing seems true about MVC or any other similar pattern/acronym: people seem hostile-certain that their interpretation/implementation is correct and everyone else is doing it wrong. Even in this thread are a bunch of comments like "everyone knows" followed by a personal opinion and then a thread of confused support/dissent. People then insist their interpretation from Wikipedia, Smalltalk, Ruby or wherever is actually the one everyone agrees on as some well-defined thing despite clearly no one in this very thread agreeing. Every platform has it's own challenges to work around. Trying to take a pattern you used in Qt and applying it precisely the same way to a Javascript/HTML application would be unwise. Things like the DOM, CSS and even the quirks/strengths of Javascript mean you should approach the problem differently. This can mean you are forced to structure your code differently. The same is true if you are dealing with iOS and Swift. IMO, MVC should mean something different in a way that supports the context it is being applied within.
- cwbrandsma 7y ago
  The only implementation that I can outright say is "wrong" is the Apple's iOS ViewController, which people mistakenly call MVC...and then promptly throw the kitchen sink into that layer without a casual thought, growing that single file to thousands of lines of code, with state, business logic, display logic, and everything else all wound together...and thinking everything is well and good because they are following the MVC pattern. The ViewController isn't bad all by itself, but calling it MVC is just not it.
chrshawkes 7y ago
I prefer Django's Model View Template.
mekster 7y ago
Where can I find a good resource to learn these patterns well for web use? I've never gotten into any of these patterns in 20 years but can get the job done efficiently as I don't put codes all over the place but at where it's easy to find for easier debugging. Usually average people try to put their codes into these patterns without truly understanding and their logic is also not efficient, turning codes into very unreadable state instead of just dropping the pattern and write as you please (with at least minimal separation of views and consolidate identical codes). Have these patterns really helped you in the web?
- dsego 7y ago
  I would recommend Architecture of complex web applications https://leanpub.com/architecture-of-complex-web-applications https://leanpub.com/architecture-of-complex-web-applications
MuffinFlavored 7y ago
State (sometimes loaded externally through APIs/network calls) modified through events (typically user input) presented to the user (typically visually). How is MVC dead? That's the majority of coding I do when I do frontend...
- bob1029 7y ago
  I think the problem going on here is that the intent of what MVC means in theory is being conflated with its alleged implementations in practice. As you said here, this is the most pure and academic view of MVC. Few would disagree that the general flow of events and state is just as you described. The implementations of MVC are generally terrible, because the "C" is extremely subjective and you cannot find consistent patterns to follow universally. One developer's MVC app is going to look a lot different from another's unless they work on the same team or follow the same policies. MVC (in practice) ultimately says "ok here's 80% of the puzzle I cannot figure out, good luck dealing with it". We can mostly agree on what our various businesses need or want (models+views) as well as what the browser API standards are (mostly views). The tricky bit is synchronizing those worlds in the middle. I personally find that pulling as much of the front-end into the back-end as is feasible is the most productive path to go down. It might not be the most scalable, but there is something really magical about being able to inject a business service you wrote 5 years ago into a .NET Core 3.1 Blazor component, write a small in-line LINQ mapper, and have it directly populate a table marked-up with BS4 (which then updates in real time via basic CLR event subscription). Is that MVC? I don't know. I don't really care either. It gets the job done, is easy to maintain, and makes me look good when it "just works".
sarah180 7y ago
If you find this interesting, read up on event-sourced architecture.
epicgiga 7y ago
I'm a big fan of the "fire and motion" concept of dev social paradigm. The idea is that devs and large companies have a tendency to constantly move away from tried and tested concepts not because the juice is genuinely worth the squeeze, but because doing so forces the devs "in their dust" back into learning mode and out of productivity mode, thereby maintaining or creating leadership over them (i.e. you force them into playing catchup -- catchup to your new "hot" thing). Case in point with this article: an attempt to declare that a tried and tested and widely used concept is now outdated, and they know the "right way" we should be doing it. This paradigm is important from a dev management perspective, in that there must be an element of actively suppressing this in a dev organisation. E.g. having approved tech lists so you don't have another half dozen js frameworks inserted over the next 12 months, requiring permission to stray outside standard paradigms, and compartmentalizing experimental time from production time. Otherwise your dev output drops through the floor. MVC is fine. Its a basic concept that aligns with the underlying hardware: model - memory, view - screen, controller - cpu. It ain't broke, don't let your devs fix it.
rubyn00bie 7y ago
Ummm maybe folks are just using MVC when they shouldn't? I don't really think most people understand how to do MVC. A LOT of people mostly pick a framework that incidentally has it slapped on the side and that's about it... People seem to assume "view" has to mean template, "model" has to mean "database access," and controller means "anything else." When in reality, they're far simpler and more abstract and has nothing to do with the web or services: Model - Data View - Output Controller - Takes input, fetches data for input(s), gives output Do you have a part of your application that takes input and gives output? Well then MVC is probably great for that part of your application, maybe not. I have not ever had anyone say "the adapter pattern is dead, don't use dat shit, my dear, brometheus" because most people, quite accurately, don't think it's some sort of philosophical statement it's just way to organize some shit to make your life easier when it applies. /shrug Use the right tool for the job; you can waste a ton of time trying to use a screwdriver on nail, or you could just get a hammer...
mempko 7y ago
The creator of MVC (https://en.wikipedia.org/wiki/Trygve_Reenskaug https://en.wikipedia.org/wiki/Trygve_Reenskaug) has since supplemented it with DCI. (https://en.wikipedia.org/wiki/Data,_context_and_interaction https://en.wikipedia.org/wiki/Data,_context_and_interaction) DCI is better thought out than MOVE.
jakequade 7y ago
Ah, another "forget <framework>, use mine instead" shtpost. Nice job.
euske 7y ago
So it seems that anyone can make up their favorite "architecture" even if it's not well defined. (Is MVC actually well defined?) My favorite was MVPC (Model-View-Player-Controller) as I was mostly developing an app for blind users, where a good speech/audio interface is the top priority. The "Player" here is much like an OS scheduler where you can post various tasks (speeches/sound effects) in a queue and get a notification when it's finished. This greatly simplified the event handling part as it eliminates the needs of individual timers, counters and flags.
5cott0 7y ago
Massive View Controllers never say die.
RocketSyntax 7y ago
JupyterLab... with a model
finder83 7y ago
This is an interesting idea, particularly if you couple it with other ideas or tools. The one primary issue I have with event driven systems is that it is very difficult to look at code and intuitively know what's going on. If you're having to search your entire code base to see what happens when a user logs in, and then what happens if that user is marked as "blocked", it can get very complicated quickly. Even worse, trying to backtrack events can be more complicated. What caused the "add to cart" event that added this special product type that is actually a digital download, but that wasn't a UI event? It could have happened in one of 10 places, debugging is difficult because you have to start somewhere in the middle and work your way backwards. This is the issue I've had with wordpress development, actions and filters can make intuitively understanding what's going on under the hood very very difficult. Of course they give a lot of flexibility with plugins, extension points, etc, but when multiple plugins are interacting it can get very confusing. Compare that with a more imperative controller where you branch based on conditions and you can generally follow the logic flow. Of course, there are ways to make that complex too like Form classes, validation, ORMs, etc. But I still find the more imperative paradigm of MVC easier to follow, such as in a Django case. Where I say this can get interesting is in a use case like React. In a way, events are propagated through a tree and can be kicked off by data changes, such as in redux. If you design it right, there might be more promise in an event-based system, but introducing both server side and client side tends to complicate things.
axilmar 7y ago
Well, MOVE, as described in the article, is exactly the same as MVC, since views are notified for state changes via events, and controllers are notified by views via events as well.

267 points by pcr910303 7y ago

Maybe at 2012 to the title.. And I can say for sure it's not dead! Even in 2020 ! :) But I do like the extension with MOVE.

deleted 7y ago

[deleted]

adamnemecek 7y ago

I think that ecs is the thing that will kill oop. https://en.wikipedia.org/wiki/Entity_component_system https://en.wikipedia.org/wiki/Entity_component_system

jcelerier 7y ago
so we hear since 2008
EamonnMR 7y ago
I took a very dogmatic approach to ECS on a project[1][2] but I'm not sure it ended up easier to read or write as a result. [1] https://github.com/EamonnMR/Flythrough.Space/blob/master/src/ecs.js https://github.com/EamonnMR/Flythrough.Space/blob/master/src... [2] https://github.com/EamonnMR/Flythrough.Space/blob/master/src/gameplay.js https://github.com/EamonnMR/Flythrough.Space/blob/master/src...
- adamnemecek 7y ago
  I think that js me not be the best language for it.
bcrosby95 7y ago
I like ECS when designing certain kinds of systems but I'm not sure how relevant it is here. I'm also not sure it would be particularly useful for your average webapp.
32gbsd 7y ago
OOP is hanging on for dear life. ECS has its niche. But why do you want OOP to die?
- ch1lang0 7y ago
  For many reasons: https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7 https://medium.com/better-programming/object-oriented-progra...
  - 32gbsd 7y ago
    I get it but some programmers are really productive in it.
zelly 7y ago
At the very least it proves you don't need OOP to do UIs. It is more difficult to implement ECS (there isn't a long tradition of it and libraries like MVC has) but well worth the effort. It's more suited to native UIs than webapps though.

danso 7y ago

Given that this article is 8 years old, did MOVE catch on?

cbhl 7y ago
I still see MVC in $dayjob, but it looks like React/Redux have helped a lot. A central module manages state and takes operations on that state. The desired view hierarchy is computed as a pure function of state. A library uses diffing to apply changes to the concrete implementation of the views (say, the DOM, or a native windowing framework).
- k__ 7y ago
  Since React got hooks it could be interpreted as MOVE. Components being Views And Hooks being Operations
- tyfon 7y ago
  MVC is still heavily used for instance in ruby on rails.
chrisco255 7y ago
I'm not sure this pattern as described is comprehensive, but the move away from MVC to other event-based patterns like React/Redux, Elm, etc, clearly did happen. MVC of course still exists in the world.
wsc981 7y ago
This article is the first one I’ve read on MOVE. On the other hand I’ve seen multiple in the past few years on MVVM and VIPER, just to name two MVC replacements. My guess is MOVE isn’t used much.

mlazos 7y ago

I feel like his answer to what goes in the controller is answered by his acronym MOVE. Operations and Events go in the controller. It initiates the state changes in the model and the view. As an aside it’s cool to see something like MVC staying relevant, it alludes to there being design patterns that are simple and fundamentally useful in some areas.

bcrosby95 7y ago

Events are how MVC was used before the web world came around. The whole point was your controller listens to model and view events so everything is updated real time as the model changes and the user interacts with the UI. The web is a bastardized version of MVC due to the lack of interactivity and state when compared to a desktop GUI application. That aside, lots of people in the web world have a sort of "Operation" layer in MVC but call them a "service". Deciding to use events is another architectural decision some people make even in web MVC. But you can take or leave any piece of this stuff and I feel like you don't need a new acronym for every combination of architectural decisions.

rumanator 7y ago
> Events are how MVC was used before the web world came around. The whole point was your controller listens to model and view events so everything is updated real time as the model changes and the user interacts with the UI. The web is a bastardized version of MVC due to the lack of interactivity and state when compared to a desktop GUI application. It seems you're mixing up implementation details with the actual design pattern. It makes no difference if you implement MVC with events or objects or imperative programming. The only thing that matters to a design pattern is the pattern, and the pattern is how three components interact to drive an user interface.
daotoad 7y ago
BILASM! But I Like Acronyms So Much. Web "MVC" rarely was really MVC. Except that it changed the meaning of the term. https://wiki.c2.com/?ModelViewControllerHistory https://wiki.c2.com/?ModelViewControllerHistory https://wiki.c2.com/?WhatsaControllerAnyway https://wiki.c2.com/?WhatsaControllerAnyway
alexis_fr 7y ago
Then the web came, and we have the MVCS+JS+REST mess. Explanation: Model: The Javabean View: The HTML Controller: Whatever Java code that calls the service layers, Service: The services in the lower layer, JS: Since you have js with your HTML, then the JS also acts kind of like a controller for complex parts of the UI, REST: Well that’s a second entry point to your service layer, to which the JS transmits Events (as in MOVE) that cannot be managed by a page reload. It’s a back channel unknown to the Controller. So perhaps React has a point ;)

threatofrain 7y ago

These are all minor variations of the same ideas.

post_below 7y ago

I don't see anything wrong with MOVE... but why does MVC need to be dead? It's such a perfect representation of the coder trope of loudly proclaiming that this new thing I found makes everything else obsolete. Eight years later, MVC is still miraculously not dead!

deleted 7y ago
[deleted]
0xdeadbeefbabe 7y ago
What does this mean for waterfall? Is it alive again? It's kind of an insult to death.
- barbecue_sauce 7y ago
  Waterfall is a myth.
  - Jtsummers 7y ago
    If only. I was surrounded by it for the last decade and it works as badly as expected.
    - moron4hire 7y ago
      I think what GP is saying is that what people call "Waterfall" is not what Waterfall was originally defined as. https://en.wikipedia.org/wiki/Waterfall_model#History https://en.wikipedia.org/wiki/Waterfall_model#History
  - logfromblammo 7y ago
    My cousin's boyfriend's sister went up to the waterfall, and when they found her body 12 months later--after delivery phase--she had been completely burned out from the inside. And there was this thing... that nobody wanted, that didn't work right, just sitting there next to her. Nobody wanted to touch it. So some guys from the federal government came and picked it up with tongs, and said they'd put it in the Source Control Repository facility out in New Mexico, so it couldn't hurt anybody else.

bugeats 7y ago

Turns out Conrad Irwin was right, but didn't take it far enough. Merge together "Events" and "Operations" into one thing, call "Models" just "state" and you've got Reactive Programming, which appears to have proven itself as the best known way to manage UI state complexity.

coldcode 7y ago
Proven in what way? After almost 4 decades in this business, nothing is ever proven. For anything one person says is beyond discussion obvious, another person does something completely different, and gets the same benefits. Every generation comes up with new ways to do things, but nothing has even been clearly better to everyone all the time in all circumstances. You constantly have to evaluate everything that comes along, and see if it's better for you, your team, project, company or industry. Silver bullets are for vampires and the Lone Ranger.
- hyperpallium 7y ago
  It is "proven", not in a mathematical sense, nor a scientific sense, nor an engineering sense or even a legal sense. It is proven in a javascript sense.
- real_eng_ 7y ago
  Aren't silver bullets for werewolves?
goatlover 7y ago
By "best" and "proven", you mean most popular way in the JS/TS world.
marcosdumay 7y ago
Reactive programming looks like a very good model for UIs, but I wouldn't claim anything is proven. I am not sure we even got any implementation that is more convenient than event based UIs from a couple of decades ago. It does certainly looks like such implementations exist, they feel just within grasp, but there is a long way into "proven".

tracer4201 7y ago

MVC certainly isn’t dead. My current team supports a system implementing MVC attributed over $65MM a year and is in still active feature development. Sensational title at best.

_bxg1 7y ago

Needs a (2012) label

deleted 7y ago

[deleted]

brobot182 7y ago

MOVE is dead, it’s time to JEJSNEBDIRKEBSBC on

riazrizvi 7y ago

MVC is understood to be the primary partition of an application's architecture. It does not obviate the need for further code organization, which is done in all parts, Model, View and Controller. When the author says "controllers are nice self-contained bit of...[what I don't know?]", and they use that as the justification to throw away the paradigm in favor of another with Model-View-Operations+Events they show they don't understand this. Worse the proposed paradigm does not then collect all the controller code in one place, so the overall lifecycle of the application would be harder to piece together from Operations+Events modules without an overarching Controller to govern the two of them.

jkoudys 7y ago
Yeah - build out a graphql service on top of existing models, and you'll get a pretty clear picture about what the C ought to represent. You can find plenty of situations where the implementation of any of those letters is extremely thin: lots of services where the View is almost nothing (often just a JSON serialization of some of the models), or where the models are very thin. It boils down to a weirdly common, but deeply flawed, view that all the letters in your abstraction's initialism should be of equal complexity. With Views, it seems to be easy for devs to understand that there is significant differences in the underlying approaches: are you organizing your views into page templates, serializing for some special client to consume, building components that compose one another, etc. I don't know why we can't wrap our heads around Controllers also having different approaches.
gonational 7y ago
+1 so much. In my opinion, the mistake the OP makes is in not realizing that the dogmatic application of a design pattern is the fundamental issue to begin with. So then the solution offered is another design pattern that can be dogmatically followed. If we know that you need a UI (view), and we know that you need to represent your data in an expressive manner (model), and you need something to pull those things together for a user, a router and controller does not automatically come to mean “put all your logic here!” Instead, it means something more like “here’s where you can tie things together in whatever way makes the most sense for your application”, which lets you e.g., use AOP to handle auth (like Django decorators or middleware), delegation to a service like a REST API (e.g., Django REST Framework), or basic one-off views for simple tasks. If something like this MOVE was to become the next big thing, I think there’s a good chance we’ll be rewriting a lot of projects to use MVC in 10 years. Don’t blame bad code on a proven and very flexible design pattern that solves a very real problem. Blame bad code on bad coders.

danielovichdk 7y ago

Everyone who has done MVC long enough would also know that the controller is the very thin layer where services are injected and models are passes to. The controller should have and only have logic which absolutely cannot be moved to a service layer. Too many developers use controllers as part of their logic layer, instead of simply using it as a router for where models should be directed on a service level.

bryanlarsen 7y ago
Every Rails app I've seen has been MV, not MVC. The app/views directory contains the template part of the view code and the app/controllers directory contains the meat of the view code. You can tell that this is happening because there is a 1:1 mapping between foos_controller and views/foo. There's nothing wrong with MV code and it's a great paradigm for a simple app. But lots of rails apps are no longer simple...
- chao- 7y ago
  In a Rails context, there are a dozen pattern-esque buckets that folks advocate putting non-template, non-persistence, non-validation logic into. Yet as often as seeing benefits from "service objects" or similar generic, I have also seen benefit from adding an actual View layer. Rails has done so much to move application development forward, but if I had two nits to pick, they are the same today as they were in 2007: 1. Assuming/requiring a folder structure named after the pattern an object fits, rather than conceptual domains of an application. 2. Naming its templates "views", and not hinting to people that presentational logic should belongs in a full instance of a class, rather than in-line in template code. Partials help but insufficiently, and helpers have too many gotchas. The sprawl of gems that attempt to address #2 this is evidence of its impact. While I appreciate the "omakase" argument, it still leads a lot of smaller or less-experienced teams to make a big mess before realizing they have better options. Anyway, as often as I see "service objects" solutions helping a team tame their Model-View-Mess, just as often I see the solution lying in adding an actual View layer (or adding Presenters if that fits better). I like ActiveRecord, ActiveRecord::Relation, ActiveSupport, and all the other things people tend to gripe about in Rails-land, but the specific folder structure has always been a stick in my craw.

catpolice 7y ago

I like this a lot, not as an alternative to MVC but as a kind of conceptual refactoring of the same ideas behind good MVC implementations that's very easy to explain and doesn't have as much ambiguity. I've posted a version of this comment before, but my main problem with MVC isn't that it's a bad architecture, just that in practice there's a huge amount of disagreement about what MVC (or MV* more generally) actually _is_, which can lead to confusion or weird/bad hybrid implementations. I tend to use the "model" and "view" concepts a lot when discussing architecture, but in my experience it's almost always a mistake to try and reference any specific MV* pattern for explanatory purposes - it does not have the effect of making the discussion clearer. The issue is that there isn't actually a consensus about what constitutes the definitional features of these patterns, especially when it comes to how the concepts involved actually translate into code. For any sufficiently notable discussion of an MV* pattern, you're going to find an argument in the comments about whether the author actually understands the pattern or is talking about something else, and typically the commenters will be talking past one another. Note that I'm NOT claiming that there's anything wrong with MV* as an architecture, or your favorite explanation of MV* - it may be perfectly well defined and concrete and useful once you understand it. The issue is a feature of the community: lots of other people have a different (and possibly worse) understanding of what MV* means, so when you start talking about it and your understandings don't align, confusion arises. Getting those understandings back in alignment is more trouble than the acronyms are worth. I've seen enough conversations about concrete development issues suddenly turn into disagreements about the meaning of words to realize that nothing useful is conveyed by mentioning MV* and assuming anyone knows what you're talking about - it's better to spell out exactly what you mean in reference to the code you're actually talking about, even if you have to use more words. I like this MOVE scheme because it seems to me to divide up the conceptual space at the joints in a way that's relatively hard to misunderstand, and it seems a little easier to see how to directly relate those division back to code.

mtzet 7y ago
I feel the same way about most design patterns. They're useful to provide vocabulary, but too generic to provide any actual guidance.

arbuge 7y ago

> MVC is a phenomenal idea. 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? The implication is that what goes into controllers is not well-defined. But if what goes into models and views is well-defined, as the author agrees, then defining what goes into controllers as everything else is actually a precise definition.

Marazan 7y ago
Trouble is what goes into the models is not well defined at all.

omarhaneef 7y ago

Controller = Operations + Events Ben Jaffe of Udacity cally is MVO where O = Octopus. Basically, as the author points out, Models and Views are relatively well defined, but the Controller can be anything. Octopus, ViewModel, or in this case Operations and Events. I do think Operations and Events are clear, but 1. are they comprehensive and 2. do they organize the code more intuitively? It seems like you would want to put them in the same place since Events will trigger operations that operate on the model and the view. Sort of like a controller... oh, wait.

Digitalis33 7y ago

FIFY Operations ^H^H^H Functions A common function for applications is logging a user in. It’s actually two sub-functions 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. Functions are the doers of the MFVE world. They are responsible for making changes to your models, for showing the right views at the right time, and for responding to events triggered by user interactions. In a well factored application, each sub-function can be run independently of its parent; which is why in the diagram events flow upwards, and changes are pushed downwards. What’s exciting about using functions in this way is that your entire application can itself be treated as an function that starts when the program boots. It spawns as many sub-functions as it needs, where each concurrently existing sub-function is run in parallel, and exits the program when they are all complete.

Digitalis33 7y ago
"What’s exciting about using functions in this way is that your entire application can itself be treated as an function that starts when the program boots." HN, rediscovering main()

ninju 7y ago

A bit off-topic but I like out the page is responsive to browser width. It auto-magically creates columns as space available

2wrist 7y ago
I really really like that part. Three columns on a widescreen monitor is really really comfortable! Nice site!

cfv 7y ago

My biggest issue with MVC is that in my experience it always ends up having the C being glue between fat Ms and fat Vs, with multiple views ocasionally growing tendrils between one another. As in, not the pattern, but the real-world usage of it. Development constraints always end up corrupting the pretty pattern in ways that make the current problem at hand easier to solve, and this de facto architecture IMO never ends up looking like proper MVC for me. I want to say I like Action-Domain-Responder better, but I haven't seen any real-world implementations of a ROA with it yet.

kazinator 7y ago

> the problem with MVC as given is that you end up stuffing too much code into your controllers > [Under MOVE, e]vents are used to join all these components together safely. The problem with events is that you put all interactions into events, creating a labyrinth of ad-hoc protocols. Events are messages, and messages are just methods in disguise: worse ones, that don't have a call stack you can inspect. Under this MOVE, someone will sooner or later hit the problem of wanting the V to manipulate the M in some way that O doesn't support, and will just end up creating some hack whereby a whole chunk of the M state (perhaps all of it) is downloaded via some stream of events, edited, and sent back via another stream of events.

ascendantlogic 7y ago

It's very rare to give any credence to any breathless "X is dead". Do what makes sense for you to solve the problem in front of you. There's anti-patterns but bike shedding over architecture patterns is a waste of time for a large majority of most CRUD webapps with low traffic requirements I'd wager.

zamfi 7y ago

(2012)

DubiousPusher 7y ago

I'll never understand the obsession to have one architecture to rule them all. mVC isn't dead. I set up MVC patterns all the time for small projects where I need CRUD with a sprinkling of custom code on top. It's a great pattern. If it's not meeting your needs that just means it's not a good abstraction of your problem. And yeah, you should probably look for something else.

choeger 7y ago

Now what are operations then? And how are they tied to events. Let us assume a concrete architecture where views are html documents and events are put into some distributed queue. Is an operation a process that consumes events from that queue or is it something more tangible? Are operations data? In other words, are they interpreted? By what interpreter? I think the idea of describing your business system as some giant, distributed, parallel DSL interpreter has some merits. But has it ever been implemented as such somewhere?

fermigier 7y ago

Previous discussion: https://news.ycombinator.com/item?id=4189811 https://news.ycombinator.com/item?id=4189811

tabtab 7y ago

I've found MVC annoying, but everyone goes "everyone else is doing it so we have to do it also". Lemming Syndrome. In team environments it's usually good to standardize "slots" for certain activities. But MVC doesn't fit our work-structure well (Conway's Law). What's good for websites is not necessarily good for data-centric CRUD. MVC tries to cater to both, and does neither well because it has to compromise to make both camps happy. I'd like to see, first, the file/folder location be flexible. If a team wants to store the view together with the model (or view-model) in entity folders, they can. Make the file look-up mechanism more flexible, or at least have a few templates to choose from. Our shop would prefer something like this: Models - model01.code // friendlier names not shown - model02.code - etc... AreaX - EntityY (folder) - - ViewModel.code - - View.code Second, navigation (menus, URL's, and breadcrumbs) should probably be table-lized in the RDBMS so analysts and project managers can change paths and titles and perhaps even role assignments without re-coding. The "path math" of controllers is confusing and hard to debug. Put the damned tree(s) in tables instead so we can do nice reports and analysis of them without digging through verbose code. There was an anti-DB movement in the early 2010's that was wrong-headed in my opinion, so everything was shoved into app code instead. It's time to embrace DB's and use them again for what they are good at. We then wouldn't need controllers, at least not in everyday work. Note: If I say something bad or wrong, please explain in a reply instead of give a hit-and-run negative score. I get better with clear feedback. Thank You.

blattimwind 7y ago
Pyramid's resource trees solve the "path math" problem quite nicely, there are some caveats to that kind of design as well, of course (mostly related to enumerability).
- tabtab 7y ago
  What's wrong with them being in the database? Analysts and project managers can then re-arrange things with fewer coding changes, using CRUD editing screens. One may have to re-project some URL's for the end-user's sake, but that's doable. "Pretty" URL's are not that useful for CRUD anyhow, but since customers expect them (because everyone else has them), they can be managed as an aesthetic wrapper. I should note I'm a fan of the CASE idea of the 90's. It was just that the products were proprietary and too expensive. 90% of most CRUD apps can be attribute-driven. Menus, navigation, page titles, field attributes, etc. can largely be stored as meta-data in RDBMS where they are readily change-able and query-able. Buried in code makes them harder to work with. Over-focus on OOP killed the CASE dream, but I suspect it will come back. RDBMS are good at storing and managing masses of related attributes, code just isn't. (Dynamic Relational would help with attributes that are different or custom per UI widget etc. I wish it would take off.)

PaulRobinson 7y ago

Event sourcing should kill MVC, we just need better frameworks to make it easier to do.

goatlover 7y ago

> Since it was invented however, new programming techniques have become popular. Without closures (or anonymous blocks) event binding can be very tedious; and without deferrables (also known as deferreds or promises) the idea of treating individual operations as objects in their own right doesn’t make much sense. Didn't the Smalltalk team invent MVC? Because I believe Smalltalk in the 70s supported both.

cdcarter 7y ago

Action Domain Responder, anyone? https://en.wikipedia.org/wiki/Action%E2%80%93domain%E2%80%93responder https://en.wikipedia.org/wiki/Action%E2%80%93domain%E2%80%93...

ergothus 7y ago

I've always had a very loose view of MVC. It feels like all the MVC/MVVM/MV(whatever) concepts really are about separating the model from the view, and having something to connect the parts. I've never gotten hung up on the specifics beyond that, but it seems like framework after framework is built on exactly worrying about those details. It's been 20 years - have I been missing out on a crucial details?

Waterluvian 7y ago

I spent just enough time with MVC to experience that there's so many flavours and opinions and confusion and uncertainty. All of that was a smell that: 1. this is a complicated domain. 2. the lack of a very clear coherent "right answer" tells me not to dwell too much on it. I'll see more gains by getting my UIs into production and initiating the feedback loop than trying to get the architecture right. As for item 2, I have absolutely iterated on underlying architecture, non-stop. But I feel I've been immensely successful in never letting that get in the way of shipping early and often and learning the 90% of stuff you can't learn without shipping.

s_dev 7y ago

MVC implemented properly is actually fine. Sometimes it doesn't matter what the rules are just that there are rules because the rules bring order and consistency that allow for quick comprehension of the written code. Heres a modern iOS dev defending MVC: https://www.dotconferences.com/2020/02/guilherme-rambo-mvc-many-view-controllers https://www.dotconferences.com/2020/02/guilherme-rambo-mvc-m...

marblar 7y ago
Everything is fine if it's done properly.

dredmorbius 7y ago

MVC: Model View Controller https://en.wikipedia.org/wiki/Model–view–controller https://en.wikipedia.org/wiki/Model–view–controller

soulchild37 7y ago

Lol no

augbog 7y ago

It looks like he just clarified some of the smaller moving parts in MVC but hilariously, he still ends up drawing a triangle for his diagram. It looks like E (events) is simply to illustrate oh yeah some communication is happening between these layers. I think that is pretty obvious? I'm not necessarily putting down what he was saying, but I don't think this is something revolutionary. I think he just dove deeper and expanded.

dang 7y ago

A thread from 2013: https://news.ycombinator.com/item?id=6370343 https://news.ycombinator.com/item?id=6370343 Discussed at the time: https://news.ycombinator.com/item?id=4189811 https://news.ycombinator.com/item?id=4189811 (Links are for the curious; reposts are ok after a year or so: https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html)

GuB-42 7y ago

To be honest, the real pattern is MVW (Model View Whatever). The third thing can be a controller (true MVC), a presenter, a view-model, or, in the case of the article, operations and events. The big deal with all this is that we have a view, usually provided by a UI framework, a model, usually provided by the app developer, and some kind of loose coupling. That's it, the good old idea of separating data from its representation. What you stick between the model and the view is just an implementation detail of your particular framework, optimized for your particular use case.

aikah 7y ago
> To be honest, the real pattern is MVW (Model View Whatever). It's not a pattern if it's not clearly identifiable as a pattern, MVC (original) applied to GUI interfaces. ASP.net tried to apply MVC to the web and it resulted in Webforms, which is true MVC, ASP.net MVC ironically isn't true MVC. Like everything in IT MVC eventually became a buzzword thus lost all significance, that's why it doesn't really mean anything anymore since it doesn't describe anything specifically to most people who use the expression.
bernawil 7y ago
> The third thing can be a controller (true MVC), a presenter, a view-model, or, in the case of the article, operations and events. Well the article introduces weird new lingo which I don't think is all that great, but whatever. "operations+events" can be equaled to "business logic". Let's keep that separated from the controllers. I want to create a new user via an http request, but I also want to do the same via a console command and since I want to do both things with the same code but one of these shouldn't be returning http status codes, it makes sense this should live in a different layer. The whole events & operations separation in the article don't make sense to me. A "login attempt" as described in the article with a "login attempt" event being triggered by the view and that being picked by a decoupled "operation"? I don't see the value. If the operation needs to check privileges does it trigger an "check privileges" event, wait for another operation to complete? does that operation trigger another event to report the result? Wait a second... this sounds a lot like a convoluted Redux clone. Then you realize the only reason we are not doing Redux in the backend is because we are used to mutable state databases.

skohan 7y ago

MVC is fine. After years experience in mobile development, my main takeaway is that application architecture acronyms in general are over-rated. The most important thing is to separate concerns, and to agree on some sensible structure for managing views and state, and communicating between them. Usually the details of that should arise from the needs of the application, not come top-down from some idea about "the perfect application architecture". Aside from that, everything should just be kept as simple as possible. IMO it actually adds a lot of unnecessary pain and complication to a project when a team is too rigid about which letter of an acronym each piece of code must fit into. VIPER would be an extreme example of this. It should not take five+ separate code files to execute an HTTP request and display the results in a list view.

debug-desperado 7y ago

Hilariously, this is basically the pattern everyone figured out long ago with Windows Forms apps. Model View Presenter with decoupled events that are fired off to any subscribed listeners. Multiple screens and models can be updated as needed. Very easy to do in a C# app thanks to uncluttered syntax for events. Go check out the "Microsoft Patterns and Practices" frameworks from decades ago to see many examples of this.

mygo 7y ago

What’s the point of this? No way of architecting software is dead. Just use the model that works best for the task at hand, including the competencies and preferences of the development team. Everything has its place. Besides, software architecture is not a religion, just a technique.

pachico 7y ago

I have to confess it's the first time I read about MOVE but MVC seemed old news for almost a decade to me. MOVE seems to englobe concepts I work with like DDD, read/write segregation, event source, etc which can all live under its umbrella

interlocutor 7y ago

Nearly all UI frameworks use MVC. That includes iOS, ASP.NET Core, JSP and JSF (both Java), Ruby on Rails, and Django (Python). In fact, it is easier to list UI frameworks that are not MVC-based: WPF, which is based on MVVM and React+ReactRouter+Redux, which is based on Flux. MVVM was invented in order to support 2-way data binding. Inspired by WPF, many early JavaScript frameworks supported 2-way data binding. These days 2-way data binding is widely acknowledged as a poor design as it makes it hard to keep track of how data is flowing through your application. For more on that see [1]. React was originally introduced as the "V in MVC" [2]. Since then it drifted away from MVC in an ad-hoc manner. In part this is because of ReactRouter, which made router a view component (!), and in part this is because of Flux/Redux. The facebook engineer who came up with Flux famously declared that MVC doesn't scale (!!). This assertion was widely challenged, and later she acknowledged that it is bidirectional data flow that doesn't scale [3]. She had assumed that MVC automatically implies 2-way data binding. Redux, an implementation of the Flux architecture then became popular, and became closely associated to React, so much so that many developers believe using React implies using Redux. This is unfortunate because Redux requires tons of boilerplate ("so much throat clearing", as one developer put it), which MVC does not require. [1] https://changelog.com/131/ https://changelog.com/131/ (starting around 0:43) [2] https://github.com/facebook/react/tree/015833e5942ce55cf31aefd0a5c2be8a65ec2daa https://github.com/facebook/react/tree/015833e5942ce55cf31ae... [3] https://www.infoq.com/news/2014/05/facebook-mvc-flux/ https://www.infoq.com/news/2014/05/facebook-mvc-flux/

acemarke 7y ago
> Redux requires tons of boilerplate Not _required_. There's both "inherent" and "incidental" complexity around Redux [0]. We've created our new Redux Toolkit package [1] to specifically eliminate the "incidental" complexity and simplify common Redux usage patterns. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. We also just released the official Redux template for Create-React-App [2] to help speed up the process of setting up a new app. [0] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/#dealing-with-complexity https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-... [1] https://redux-toolkit.js.org https://redux-toolkit.js.org [2] https://github.com/reduxjs/cra-template-redux/releases/tag/v1.0.0 https://github.com/reduxjs/cra-template-redux/releases/tag/v...

anm89 7y ago

Step 1: Call thing that people use dead Step 2: ? Step 3: Profit

reggieband 7y ago

One thing seems true about MVC or any other similar pattern/acronym: people seem hostile-certain that their interpretation/implementation is correct and everyone else is doing it wrong. Even in this thread are a bunch of comments like "everyone knows" followed by a personal opinion and then a thread of confused support/dissent. People then insist their interpretation from Wikipedia, Smalltalk, Ruby or wherever is actually the one everyone agrees on as some well-defined thing despite clearly no one in this very thread agreeing. Every platform has it's own challenges to work around. Trying to take a pattern you used in Qt and applying it precisely the same way to a Javascript/HTML application would be unwise. Things like the DOM, CSS and even the quirks/strengths of Javascript mean you should approach the problem differently. This can mean you are forced to structure your code differently. The same is true if you are dealing with iOS and Swift. IMO, MVC should mean something different in a way that supports the context it is being applied within.

cwbrandsma 7y ago
The only implementation that I can outright say is "wrong" is the Apple's iOS ViewController, which people mistakenly call MVC...and then promptly throw the kitchen sink into that layer without a casual thought, growing that single file to thousands of lines of code, with state, business logic, display logic, and everything else all wound together...and thinking everything is well and good because they are following the MVC pattern. The ViewController isn't bad all by itself, but calling it MVC is just not it.

chrshawkes 7y ago

I prefer Django's Model View Template.

mekster 7y ago

Where can I find a good resource to learn these patterns well for web use? I've never gotten into any of these patterns in 20 years but can get the job done efficiently as I don't put codes all over the place but at where it's easy to find for easier debugging. Usually average people try to put their codes into these patterns without truly understanding and their logic is also not efficient, turning codes into very unreadable state instead of just dropping the pattern and write as you please (with at least minimal separation of views and consolidate identical codes). Have these patterns really helped you in the web?

dsego 7y ago
I would recommend Architecture of complex web applications https://leanpub.com/architecture-of-complex-web-applications https://leanpub.com/architecture-of-complex-web-applications

MuffinFlavored 7y ago

State (sometimes loaded externally through APIs/network calls) modified through events (typically user input) presented to the user (typically visually). How is MVC dead? That's the majority of coding I do when I do frontend...

bob1029 7y ago
I think the problem going on here is that the intent of what MVC means in theory is being conflated with its alleged implementations in practice. As you said here, this is the most pure and academic view of MVC. Few would disagree that the general flow of events and state is just as you described. The implementations of MVC are generally terrible, because the "C" is extremely subjective and you cannot find consistent patterns to follow universally. One developer's MVC app is going to look a lot different from another's unless they work on the same team or follow the same policies. MVC (in practice) ultimately says "ok here's 80% of the puzzle I cannot figure out, good luck dealing with it". We can mostly agree on what our various businesses need or want (models+views) as well as what the browser API standards are (mostly views). The tricky bit is synchronizing those worlds in the middle. I personally find that pulling as much of the front-end into the back-end as is feasible is the most productive path to go down. It might not be the most scalable, but there is something really magical about being able to inject a business service you wrote 5 years ago into a .NET Core 3.1 Blazor component, write a small in-line LINQ mapper, and have it directly populate a table marked-up with BS4 (which then updates in real time via basic CLR event subscription). Is that MVC? I don't know. I don't really care either. It gets the job done, is easy to maintain, and makes me look good when it "just works".

sarah180 7y ago

If you find this interesting, read up on event-sourced architecture.

epicgiga 7y ago

I'm a big fan of the "fire and motion" concept of dev social paradigm. The idea is that devs and large companies have a tendency to constantly move away from tried and tested concepts not because the juice is genuinely worth the squeeze, but because doing so forces the devs "in their dust" back into learning mode and out of productivity mode, thereby maintaining or creating leadership over them (i.e. you force them into playing catchup -- catchup to your new "hot" thing). Case in point with this article: an attempt to declare that a tried and tested and widely used concept is now outdated, and they know the "right way" we should be doing it. This paradigm is important from a dev management perspective, in that there must be an element of actively suppressing this in a dev organisation. E.g. having approved tech lists so you don't have another half dozen js frameworks inserted over the next 12 months, requiring permission to stray outside standard paradigms, and compartmentalizing experimental time from production time. Otherwise your dev output drops through the floor. MVC is fine. Its a basic concept that aligns with the underlying hardware: model - memory, view - screen, controller - cpu. It ain't broke, don't let your devs fix it.

rubyn00bie 7y ago

Ummm maybe folks are just using MVC when they shouldn't? I don't really think most people understand how to do MVC. A LOT of people mostly pick a framework that incidentally has it slapped on the side and that's about it... People seem to assume "view" has to mean template, "model" has to mean "database access," and controller means "anything else." When in reality, they're far simpler and more abstract and has nothing to do with the web or services: Model - Data View - Output Controller - Takes input, fetches data for input(s), gives output Do you have a part of your application that takes input and gives output? Well then MVC is probably great for that part of your application, maybe not. I have not ever had anyone say "the adapter pattern is dead, don't use dat shit, my dear, brometheus" because most people, quite accurately, don't think it's some sort of philosophical statement it's just way to organize some shit to make your life easier when it applies. /shrug Use the right tool for the job; you can waste a ton of time trying to use a screwdriver on nail, or you could just get a hammer...

mempko 7y ago

The creator of MVC (https://en.wikipedia.org/wiki/Trygve_Reenskaug https://en.wikipedia.org/wiki/Trygve_Reenskaug) has since supplemented it with DCI. (https://en.wikipedia.org/wiki/Data,_context_and_interaction https://en.wikipedia.org/wiki/Data,_context_and_interaction) DCI is better thought out than MOVE.

jakequade 7y ago

Ah, another "forget <framework>, use mine instead" shtpost. Nice job.

euske 7y ago

So it seems that anyone can make up their favorite "architecture" even if it's not well defined. (Is MVC actually well defined?) My favorite was MVPC (Model-View-Player-Controller) as I was mostly developing an app for blind users, where a good speech/audio interface is the top priority. The "Player" here is much like an OS scheduler where you can post various tasks (speeches/sound effects) in a queue and get a notification when it's finished. This greatly simplified the event handling part as it eliminates the needs of individual timers, counters and flags.

5cott0 7y ago

Massive View Controllers never say die.

RocketSyntax 7y ago

JupyterLab... with a model

finder83 7y ago

This is an interesting idea, particularly if you couple it with other ideas or tools. The one primary issue I have with event driven systems is that it is very difficult to look at code and intuitively know what's going on. If you're having to search your entire code base to see what happens when a user logs in, and then what happens if that user is marked as "blocked", it can get very complicated quickly. Even worse, trying to backtrack events can be more complicated. What caused the "add to cart" event that added this special product type that is actually a digital download, but that wasn't a UI event? It could have happened in one of 10 places, debugging is difficult because you have to start somewhere in the middle and work your way backwards. This is the issue I've had with wordpress development, actions and filters can make intuitively understanding what's going on under the hood very very difficult. Of course they give a lot of flexibility with plugins, extension points, etc, but when multiple plugins are interacting it can get very confusing. Compare that with a more imperative controller where you branch based on conditions and you can generally follow the logic flow. Of course, there are ways to make that complex too like Form classes, validation, ORMs, etc. But I still find the more imperative paradigm of MVC easier to follow, such as in a Django case. Where I say this can get interesting is in a use case like React. In a way, events are propagated through a tree and can be kicked off by data changes, such as in redux. If you design it right, there might be more promise in an event-based system, but introducing both server side and client side tends to complicate things.

axilmar 7y ago

Well, MOVE, as described in the article, is exactly the same as MVC, since views are notified for state changes via events, and controllers are notified by views via events as well.