No more MVC | Hacker News Reader

No more MVC

dev.to

31 pointsrbanffy19 comments

> Action-Domain-Responder or ADR is a rather refinement of the term MVC than a brand new architectural pattern.

There's nothing new here other than renaming.

If I understand correctly, the main difference is that the controller no longer calls the view (templating system or what-have-you) to output the result, but rather outputs the model and the responder figures out how to render that data.

I find this useful because it allows you to reuse a controller (action). In most applications you'll have at least 2 views on the system: UI and API. Sometimes, they're the same, but very often they're not.

Sounds like what FubuMVC used to do.

I'd say that's exactly what it does. The Action (Controller) gets data from the Domain (Model), and calls the Responder (View) with the data which is then appropriately rendered and returned to the client.

I don't doubt that the pattern is useful for web sites and services, it just looks like plain old MVC to me and thus not meriting a new name.

Sounds like what's been pretty much a default in Java applications for a while, the controller receives an API call, and a system like Jackson or whatever converts the model to json or xml using reflection, annotations, and magic.

I think it is useful for helping to more strictly determine each piece's responsibility. But if a controller/action is simply a pubsub middleware between the domain and responder, won't this mean that the number of controllers would be insanely low, since you could have one base controller shared across most domain/responders?

I'm not sure that would be a problem, but it was kind of undefined as to what other responsibilities the controller would have.

Exactly this. The only difference between Web API and MVC in the .Net world is one returns a JSON payload and the other returns HTML. They both use the same pipeline and architecture.

Not a great article, but the idea is worth discussing. For me, Model-View-Controller has morphed to Model-Controller-Frontend. Server side templating has been dropped and replaced with a JS framework. For complex web applications it's a great fit which allows you to move quickly but stably.

I now pretty exclusively use statically typed backends with js frontends. This gives me stability where I need it, and rapid development where I need it.

It's really still MVC, but the V got bigger and has been separated from the M and C. MC-V?

I rather like the MCF phrasing!

My team has transitioned into the same style stack. We used Codeigniter for everything. Now we use its controllers solely as a PHP api and its models as a db query wrapper. AngularJS handles our whole frontend. We just had a big discussion if we want to move to something smaller. Alot of us want to switch to python for professional reasons.

Why python in particular? I’m just curious.

Its used in alot more industry than just web design. I've seen it used for both robotics and ML as well. If I'm still writing server side code for the foreseeable future, I'd like to practice skills in a language that can translate to other uses, whether that's python or javascript via node.js

The main issue with most applications is state management. This is where Redux get's it right, but I don't think there's much value trying to sum up why Redux solves the state management problem in a succinct little diagram. For me, the important things introduced by redux are

  1. As single, immutable, source of truth (The Store)  
  2. Unidirectional data flow  
  3. Clear separation of concerts (views, actions, reducers, 
  the store).

You could stop there and create a nice little diagram, but you need to go further to get the actual benefits.

  4. Functional programming (eschew OOP)  
  5. Higher Order Components (or render prop)  
  6. Forget DRY, favour simplicity over abstraction  
  7. Selectors  
  8. Proper control over side effects (see Redux Sagas)  
  9. Container components and presentational components.

You could still draw a diagram, but it wouldn't be the nice, neat, three box diagram people seem to love so much.

Redux is really only viable for Javascript at the moment, but I think it would be an approach worth using elsewhere. Sadly, the model part is hard to get right in compiled, statically typed languages.

I'd add to this, I think a thoughtful approach to a redux architecture negates the need for typed Javascript. When your code is functional, your functions are small, your concerns are properly separated, you side effects are wrangled and you state is under total control, Typescript and Flow just make things complicated again.

The title is clickbait, but renaming MVC to ADR is a change that shouldn't be underplayed: ADR seems orders of magnitude more intuitive conceptually

tl;dr; version: They've just renamed the Model, View, Controller into Domain, Responder & Action... which I admit is a bit clearer way to name them, but the idea is still exactly the same.

If only the blog post didn't have a blatantly click-bait title.

The boundary lines between the Model, View, and Controller always tended to be a bit fuzzy (with each technology providing their own interpretation of it).

I'm alright with a clarifying name change. But it certainly doesn't mean that MVC is "dead".

A better name for this very short article would be: How to use MVC for "modern server-side web development".

MVVM seems to be the way most of the world has gone. The common model is translated to a view model and exposed over REST.

> However it does not describe well how (server-side!) web-app architecture looks like.

Does it need to?

Reply on news.ycombinator.com