It's almost a truism that every time someone talks about Rails and issues with "convention over configuration," it means they're going to be substituting CS concepts (usually filtered through Java) for well-engineered Rails techniques and creating code smell.

To the presenterFactory, let's go!

"StoryAssigner"? Really?

"Don't make objects that end with 'er'." [1] From a post previously seen on HN.

http://objology.blogspot.com/2011/09/one-of-best-bits-of-pro...

I like using service classes for things like this.

  class StoryService
    def self.assign_story(params)
      story = Story.find(params[:story_id])
      user = User.find(params[:user_id])
      story.assign_to(user)
    end
  end

This example is fairly minimal, but with service classes handling workflow and object coordination instead of the controller, the code is easier to test and reuse.

See, this strikes me as CS-driven code smell. Why not use an association between User and Story (maybe through :assignments) and just `user.stories.create(...)` or `user.assignments.create(:story => story)` ? No spurious class necessary.

That is probably how you would do it in this case, but in more complex scenarios, a simple association wouldn't be sufficient. In those cases, putting the code into a service instead of the controller will make the code easier to test and reuse.

What's an example that exceeds the functionality of associations?

You wouldn't put the code in the controllers; you'd extend the association proxy.

Rails is not actually MVC. The MVC system is asynchronous, as you can tell with a quick look at the wikipedia page linked there - it was intended for desktop applications (though there are a few js frameworks out there that do a good job of it also).

Rails is closest to a Model 2 system: http://en.wikipedia.org/wiki/Model_2

"Out of Controller"...that is our nickname for our current Comptroller. When he drinks...holy shit is it a good time.