| I think it's great to see someone make a run at a more decoupled ruby web app approach. I hope it succeeds. In my experience working on Obvious (http://obvious.retromocha.com) it is hard to get Ruby developers behind decoupled architectures because the large majority aren't Ruby devs, they are Rails devs and Rails happens to be in Ruby. Also, the larger group of developers doesn't like the idea of an app being a giant collection of very small objects. It's like there is a gravity to the notion of objects where we think of an object as something akin to a car, not the thousands of parts that make up a car. Last, I think the idea of MVC doesn't place the appropriate number of objects for the different roles in normal request processing. At a reasonable point of complexity really end up with routes, controllers, entities, data access objects or repositories/adaptors, presenters, views, templates, helpers, utilities/libs, and probably some other bits of random code in there somehow. That doesn't fit the 3 role view of the world that is MVC. Lotus does a better job than most of addressing such things, but I think the MVC approach in general falls flat. That lack of appropriate roles means that as programmers we invent a lot of names, patterns, roles, etc. to fit what our code actually ends up doing. That's why you see a lot of service patterns, presenter patterns, etc. being attached to Rails. Everybody is duct taping their approach to the notion of MVC, but very few are saying "what if we didn't see request processing as only having 3 roles?" MVC is better and cleaner than writing a page as one giant PHP file maybe, but I've seen it fall down so many times that I no longer trust it as a useful pattern or abstraction for expressing request processing and HTML string manipulation in code. In fact, if we were building command line apps and writing to files, I don't think we would use MVC at all. But, since we're writing strings of HTML, it's totally different right? |
One problem I have with "decoupled" architectures is that the only way you can sensibly interop with everything from RDBMS to flat JSON files is if you treat the RDBMS as a flat file. For instance, the sample Twitter clone treats every available DB as a plain key-value store.