I've done a lot of research on this topic and there seems to be some dispute, so I wanted to get your opinions. Here is my basic situation - I have a User model:

class User < ActiveRecord::Base
# User consists of first_name, last_name, and other fields
has_one :profile # 1-1 mapping between User and Profile
# Profile is a nested resource of User
# this is the method up for debate:
# this obviously doesn't work unless I include
# the necessary modules in this class
def link(*args)
link_to self.first_name, users_profile_path(self), args
end
end

My reasoning for this kind of behavior is that, in my views, I'd like to do something like:

<%= @user.link %>

instead of:

<%= link_to @user.name, users_profile_path(@user) ... %>

every time. This link will be used thousands of times, in many different views. I want to centralize this "method" so that, when I need to make a change, I can make it once.

However, this practice absolutely violates the MVC architecture. Others suggest using a helper:

You've nailed something that's bothered me for the longest time. The fact of the matter is that probably 90% of helpers would actually be better defined on a class itself if it wasn't considered bad practice. I hope you find a good answer for this.
–
ryeguyDec 29 '10 at 20:14

3 Answers
3

Rails is all about coding by convention. As you've pointed out, using a method in the model breaks the conventions of MVC. Unless there's a compelling reason to do so, you're better off going with the flow, and using the helper approach.

One practical issue is testing: you'll find it easier to test the helper method than the model method. Helper tests will include the link_to and users_profile_path methods for you -- model tests won't.

Finally, think of other developers reading your code. Where would they expect to find this method? If you follow MVC, you'll make their lives easier.