

Model View Whatever - khanlou
http://khanlou.com/2014/03/model-view-whatever/

======
thibauts
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.

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

~~~
thibauts
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 ?

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

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

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

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

~~~
ballard
s/app/lib/

