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.
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.
[+] [-] thibauts|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] kreeger|12 years ago|reply
Great post; I always enjoy reading these sorts of things.
[+] [-] girvo|12 years ago|reply
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|12 years ago|reply
We also add our own standards to Rails:
And foreman_god to support passenger-like tmp/stop.txt and tmp/restart.txt[+] [-] ballard|12 years ago|reply