Hacker News Reader

Comment by narrowtux | Hacker News Reader

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.

View on HN

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.

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.

Sounds like what FubuMVC used to do.

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.

Reply on news.ycombinator.com