
MVC is dead, it's time to MOVE on (2012) - pcr910303
https://cirw.in/blog/time-to-move-on
======
danielovichdk
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.

~~~
jerf
"Everyone who has done MVC long enough... The controller should have and only
have logic which absolutely cannot be moved to a service layer."

Sorry, which letter in MVC is the "service layer"?

One of the reasons I don't buy into MVC is that MVC doesn't mean _anything_
any more, and hasn't ever since the web people got their hands on it. If you
ask ten developers what MVC is and get 13 different answers (see half the
sibling replies to this comment), well, that's not itself a problem, but it
does mean that running around telling people that they should or should not do
"MVC" has been pointless for a long time.

I still like MVC for its original purpose: Multiple views in a CAD/CAM
program. Makes perfect sense there. I don't think I've yet seen a place where
it belongs other than that, though.

~~~
rumanator
> Sorry, which letter in MVC is the "service layer"?

Your question, sarcasm and all, makes no sense and either reflects bad faith
or ignorance. The model in MVC is the model, even if it depends on the service
layer or not. Design patterns describe components with respect to their roles,
and the fact that the concept of service is not necessary to explain the
design pattern that does not mean it should be in the acronym. In fact, models
are quite obviously wrappers around repositories/gateways/services/etc etc
etc. The reason behind this, obviously, is that if your goal is to simply
provide a UI then it makes absolutely no sense to drag or leak the application
or service layer into the interface. You just add an adapter to the
repositories/gateways/services and then use that adapter to input and output
the data you need to be in the UI.

> One of the reasons I don't buy into MVC is that MVC doesn't mean anything
> any more,

That cop-out doesn't cut it. MVC is well documented, and objectively defined.
Just because some people either ignore its meaning or get a bit "creative"
with their personal definition (I'm looking at you, Qt) it doesn't mean there
is no concrete definition, or that you have any excuse to criticise something
you don't know.

~~~
tabtab
Re: _MVC is well documented, and objectively defined._

I'm skeptical. Do you have a link or quote of the "official" definition so we
can critique it?

~~~
rumanator
For example:

[http://www.math.sfedu.ru/smalltalk/gui/mvc.pdf](http://www.math.sfedu.ru/smalltalk/gui/mvc.pdf)

The pattern is known for having been made popular by Smalltalk. In the 1980s.
It makes no sense to assume that a design pattern that has been widely used
for, say, 40 years is somehow not described.

~~~
tabtab
I still haven't found anything that makes a clear distinction between
"controller" and "model". The best explanation I've ever heard is that a
controller's job is to map UI activity to the proper model and view. That's a
start, but there is a lot of grey area there also as determining such can
sometimes be complex in itself, which leaves the door open to "fat"
controllers.

~~~
johnmaguire2013
I think the biggest distinction to me is that the controller is the entry-
point into an action/routine. It takes external inputs and returns an output
to be sent back downstream.

~~~
tabtab
That's pretty much true of any function or method.

~~~
johnmaguire2013
Yes, but I'm talking about into the overall system, not into a method.

~~~
justanotherc
In many frameworks the controller isn't even the entrypoint anymore though.
Laravel for example has a separate router layer, which is the entrypoint that
then passes things into a controller.

------
skohan
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.

------
GuB-42
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.

~~~
bernawil
> 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.

------
riazrizvi
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.

~~~
gonational
+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.

~~~
riazrizvi
Personally I see this design pattern simply as an application of Dijkstra’s
Separation Of Concerns. That MVC is the best (most orthogonal and balanced)
division of concerns in a gui based app.

------
bcrosby95
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.

~~~
daotoad
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)

------
bugeats
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
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
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.

------
interlocutor
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/015833e5942ce55cf31ae...](https://github.com/facebook/react/tree/015833e5942ce55cf31aefd0a5c2be8a65ec2daa)

[3] [https://www.infoq.com/news/2014/05/facebook-mvc-
flux/](https://www.infoq.com/news/2014/05/facebook-mvc-flux/)

~~~
jimbokun
"That includes iOS, ASP.NET Core, JSP and JSF (both Java), Ruby on Rails, and
Django (Python)."

If all of those are MVC, does MVC even mean anything?

What are the core commonalities across all those development frameworks that
make them "MVC"?

~~~
ncphillips
The Models are all the code that define your business logic. They have no idea
how they get represented in the UI, and they have no idea what calls their
operations.

The Views accept data and generate a UI of some kind. They have no idea where
the data comes from, or what their requests actually do.

The Controller knows about both the Model and the View. It maps request from
the View to operations in the Model, and then uses data from the Model to
update the View.

M <= C => V

That is the broad structure behind how all those things works. They aren't all
the same, but that's not the point of a design pattern.

------
bilekas
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.

------
post_below
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!

~~~
0xdeadbeefbabe
What does this mean for waterfall? Is it alive again?

It's kind of an insult to death.

~~~
barbecue_sauce
Waterfall is a myth.

~~~
logfromblammo
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.

~~~
i_am_nomad
Nice to get some commentary from GPT-2.

~~~
DyslexicAtheist
Wouldn't gpt-2 be much harder to detect. This could just be markov chains
which were trained with all their comments from the past. Still pretty cool

~~~
logfromblammo
You mentioned markov chains which were trained earlier. Tell me more about
that.

------
mekster
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
I would recommend Architecture of complex web applications
[https://leanpub.com/architecture-of-complex-web-
applications](https://leanpub.com/architecture-of-complex-web-applications)

------
dang
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))

------
threatofrain
These are all minor variations of the same ideas.

------
ergothus
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?

------
rubyn00bie
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...

------
catpolice
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
I feel the same way about most design patterns. They're useful to provide
vocabulary, but too generic to provide any actual guidance.

------
reggieband
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
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.

------
_bxg1
Needs a (2012) label

------
omarhaneef
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.

------
epicgiga
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.

------
finder83
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.

------
arbuge
> 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
Trouble is what goes into the models is not well defined at all.

------
augbog
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.

------
mlazos
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.

------
Digitalis33
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
"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
A bit off-topic but I like out the page is responsive to browser width. It
auto-magically creates columns as space available

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

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

~~~
cbhl
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).

~~~
tyfon
MVC is still heavily used for instance in ruby on rails.

------
kazinator
> _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.

------
Waterluvian
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.

------
euske
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.

------
cfv
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.

------
choeger
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?

------
mempko
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.

------
s_dev
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-m...](https://www.dotconferences.com/2020/02/guilherme-rambo-mvc-many-
view-controllers)

~~~
marblar
Everything is fine if it's done properly.

------
tracer4201
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.

------
debug-desperado
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.

------
goatlover
> 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.

------
DubiousPusher
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.

------
ascendantlogic
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.

------
mygo
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.

------
tabtab
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
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
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.)

~~~
blattimwind
> I should note I'm a fan of the CASE idea of the 90's.

What's CASE?

~~~
tabtab
Computer-Aided Software Engineering. It has different interpretations, but in
my usage it means most of the application is controlled by meta-data that
defines navigation, data relationships, field info, screen names, role
associations, etc.

It's essentially a glorified integrated ERD + IDE. If you think about it, most
of the info that goes into a typical CRUD application can come from tables.
Related: "Data Dictionary". When I first saw them, I went, "Wow! This is the
future!", similar to my first Macintosh visit. (One tricky part is dealing
with the 15% or so that still needs custom adjustments. I have some ideas
about that, but that's another long topic.)

------
pachico
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

------
MuffinFlavored
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
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".

------
cdcarter
Action Domain Responder, anyone?
[https://en.wikipedia.org/wiki/Action%E2%80%93domain%E2%80%93...](https://en.wikipedia.org/wiki/Action%E2%80%93domain%E2%80%93responder)

------
axilmar
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.

------
dredmorbius
MVC: Model View Controller

[https://en.wikipedia.org/wiki/Model–view–controller](https://en.wikipedia.org/wiki/Model–view–controller)

------
fermigier
Previous discussion:
[https://news.ycombinator.com/item?id=4189811](https://news.ycombinator.com/item?id=4189811)

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

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

------
chrshawkes
I prefer Django's Model View Template.

------
5cott0
Massive View Controllers never say die.

------
anm89
Step 1: Call thing that people use dead

Step 2: ?

Step 3: Profit

------
zamfi
(2012)

------
RocketSyntax
JupyterLab... with a model

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

------
soulchild37
Lol no

------
adamnemecek
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)

~~~
EamonnMR
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...](https://github.com/EamonnMR/Flythrough.Space/blob/master/src/ecs.js)
[2]
[https://github.com/EamonnMR/Flythrough.Space/blob/master/src...](https://github.com/EamonnMR/Flythrough.Space/blob/master/src/gameplay.js)

~~~
adamnemecek
I think that js me not be the best language for it.

