Model View Whatever | Hacker News Reader

Model View Whatever

khanlou.com

20 pointskhanlou8 comments

The article is pretty well thought-out and documented, but I feel it's missing the target once again.

Am I the only one to feel that this plethora of nebulous patterns hinder creativity and intelligence more than anything else ? What is the deal really ? I may be missing the whole point but for me it seems to be, summed up : keep as much of the core business logic separated from the interface because one will die sooner than the other. Then the correct model depends a lot on the platform you're building on, and the freedom to try and design new paradigms seems to me a much more valuable asset than trying to force-fit your app into MV-WTH. I feel we don't even remember what constraints these models are here to help optimize. Please tell me if I'm missing something. I eagerly await the day when this will all (MVC and friends) settle down and we will be able to start building on top of all that towards more ambitious architectures.

I'm curious what you feel the target is. What we call patterns here are no different than any other industry.

Seriously, name an item and we can quickly describe some common patterns in them. More interestingly, we can describe different sets of patterns that cover the same item. Depending merely on the vantage of who is looking at it.

I think this is where things get truly difficult in programming patterns. We try to get the one abstraction to rule them all. Not necessarily that easy to do.

To me the target is being able to adapt. Patterns are not bad in themselves. What make me cringe is the obsession with MVC and derivatives. That's like trying to fit everything that is merely spherical in the "ball" label. That is "ballish", "ballable", "balloid". Maybe it's just not, and being able to take a fresh look on it might open new perspectives.

Looking for one abstraction to rule them all is is like looking for one word to rule them all. Does it make sense ?

Oh, it certainly does. My point on the "one abstraction" was just how fraught that idea is.

On the train home I thought of a retort to the idea of all of this. When it comes to describing a system, there are really only two things I care about. The inputs and the outputs. Anything that obscures either of these in relation to the other is just going to get in the way at some point.

I used to call programming web pages the act of building a giant Rube Goldberg machine where you mix several inputs into building out a web page. I still feel this way, to an extent, but I am hopeful of simple solutions that do not obscure where data comes in and how it goes out. (If that makes sense.)

I'm beginning to appreciate the concept of Interactors and Entities more these days (application-specific business logic versus application-independent business logic), now that I'm some sort of a mature adult (jury is still out on that one). This post highlights that as part of the "VIPER"-style architecture. The great part about these patterns is that they can typically be applied to a lot of modern Ruby and iOS projects _both_ to cleanup code.

Great post; I always enjoy reading these sorts of things.

Funny, I have ended up with VIPER (sort of). Only, nearly all of the classes involved are Plain Old Objects, instead of having particular defined/inherited behaviour. It's quite nice. My view layer is gone, too, as I'm just kicking out JSON from my server (although I can wrap dumb views in front of the API if needed). This is web development, mind you.

Lately I've been trying to learn game engine development, from scratch in C++(!). It's... an experience, and aside from the amazing book Game Engine Architecture and a few others I have, I've come to really miss how well defined architecture is for web dev compared to game dev.

If anyone wants to see the MVVM (MVCP) pattern in Rails 3 action, the diaspora codebase on github is a good place to look.

We also add our own standards to Rails:

    app/clocks/      # clockwork
    app/hacks/early/ # before boot
    app/hacks/late/  # after initialize!
    app/threads/     # launched in Thread.new to save RAM costs (150 MiB / process)
    app/workers/     # sidekiq

And foreman_god to support passenger-like tmp/stop.txt and tmp/restart.txt

s/app/lib/

Reply on news.ycombinator.com