Hacker News new | past | comments | ask | show | jobs | submit login

Sure - I don't think anyone in the Rails world is claiming to have invented these principles.

The problem is that Rails ships with a very limited set of core architectural concepts, and many inexperienced Rails developers feel like they've got to cram all of their code into a Model, View or Controller.

Once your codebase reaches a certain complexity, principles from other programming paradigms are extremely useful.




> "The problem is that Rails ships with a very limited set of core architectural concepts, and many inexperienced Rails developers feel like they've got to cram all of their code into a Model, View or Controller."

The problem is that people think Rails is an architecture to begin with. Rails is just a framework that uses the MVC pattern (mangled slightly to fit the realm of HTTP). In the end, MVC is nothing but a directory structure for our files. What you put in those files and directories is up to you. Uncle Bob gave a great keynote on this called Architecture: The Lost Years. Here's a link: http://www.confreaks.com/videos/759-rubymidwest2011-keynote-...


You have to realize: Rails is incredibly populist in that it's "good enough" architecture for many devs. It's not terrible, but it's not at all the same as learning basic architectural principles for building apps. Devs don't stray outside of it much, they just deal with it when it gets to be a problem.

In this way, we've successfully commoditized another differentiating factor of developers so we can ship on Internet Time(tm).


Yes, that's a wonderful talk


Interactors, domain objects, service objects, etc. are still models; people just don't generally believe that their models are allowed to inherit from things other than ActiveRecord::Base.


They're not models, they're Objects. A model is an object but all objects are not models. The difference is what sort of role they play in your app.

A Service Object work, could just echo hello world every 15 seconds and still be called a Service Object, while a model in your application doing the same thing can no longer be called a Model.


I keep looking at interactors and thinking "I'd make this a command object and then hide it in the model" - so I'd be doing something like (inside the 'member' class)

    method confirm_grouper () {
      MyApp::Action::ConfirmGrouper->new(leader => $self)
                                   ->run
    }
and then the controller would simply do -

    my $result = $member->confirm_grouper;


Problem with your assumptions is that inexperienced developers do not understand architectural concepts.

So you could cram every design pattern known to man and they would still cram everything in their controller.

API's are hard to discover and it takes time through trial and errors or being teached the way things are.


To be fair, Rails does have concerns which let you easily compose your models out of modules, rather than having big god-object models, and it is easy to load other arbitrary collections of code too. So it is not really limited to MVC.

For beginners, I'm not sure it would be helpful to introduce a whole load of named patterns, as it just leads to cargo-culting and overuse of patterns without understanding whether they even apply.

It was interesting to read about a different approach though - thanks for the article.


The problem with concerns is that they don't actually break down the god classes, they just separate the pieces of the god class into different files and combine them at runtime.

The important metric here isn't "wc -l app/models/god.rb", it's "God.public_instance_methods.length".


You don't have to use them for that, you can use them for composing models out of shared bits of functionality, for example 5 of your models have a status - put all the code about statuses in one place in a concern and include Status in your models, and possibly similar for controllers - this cuts code duplication.

There is also an argument for making models smaller by splitting some of their functionality into modules too (what you're talking about), but I think that's a weaker case - better to use concerns for shared code.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: