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.
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.
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).
10 comments
[ 5.2 ms ] story [ 20.6 ms ] threadhttp://objology.blogspot.com/2011/09/one-of-best-bits-of-pro...
To the presenterFactory, let's go!
Rails is closest to a Model 2 system: http://en.wikipedia.org/wiki/Model_2