Topic: How to achieve "fat models"

I have been told through various sources to "make my models fat," i.e. take some of the logic out of my controllers and views, and stick it in my models.

Fine.  I tried to do that.  What I seemed to have found out is, nothing works.  ActiveRecords don't seem to like being anything other than an interface to a database table.

One example - I wanted to zero-out the ActiveRecord object in question if the user_id for the user logged-in didn't match up with the user_id for the record he requested and loaded up.  Pseudo-code follows:

# inside an ActiveRecord model

def validate_or_zero_out user_id
    if user_id != @user_id
        @var1 = @var2 = @var3 = nil
   end
end

Nope, doesn't work.  Other things don't work when I've moved them from the controller to the model either.

Question:  If ActiveRecords are simply glorified database rows, how are "fat models" to be achieved?  Am I missing something?

Thanks.

Last edited by rex.goxman (2012-06-02 19:37:21)

Re: How to achieve "fat models"

Hhhmm!

i.e. take some of the logic out of my controllers and views, and stick it in my models.

Totally agree!

What I seemed to have found out is, nothing works.

Course it works!

ActiveRecords don't seem to like being anything other than an interface to a database table

Now that is just about right!
In a 3 tier application it is argued that the middle tier and the database tier have the responsibility for ALL the data and data integrity.

In Rails MVC architecture the model layer is the middle tier.

If you have functions and methods that do stuff with data then put in the model! It really is that simple. You can of course (and probably should) put stuff in the database.

Controllers are essentially a collection of views. And as little logic as possible should be placed in views.

Why?

Well, perhaps you would find this an interesting read.
http://wekeroad.com/2011/10/14/rails-mo … ness-logic

As a rule of thumb, when considering placing logic in views ask yourself how you would use that logic from a rake task.
Another rule of thumb
If you need to access the same functionality elsewhere then it belongs in the model.

Change the way you think and the way you develop. Take the TBDD approach, applies to all good languages, not just RoR, You will quickly understand, when writing your tests how the jigsaw pieces of your application fit together.
It's a very OO approach that more than a few developers just don't get, even some of those that think they do, really just don't get it.

With the right approach you'll develop your code to be a lot more stable, readable and bug free in far shorter time scales than traditional development approaches, and time is money, so ultimately that is the reason why.

What you want and what you need are too often not the same thing!
When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.
(Quote by me 15th July 2009)

Re: How to achieve "fat models"

Now, as far as your seudo example is concerned

def validate_or_zero_out user_id
    if user_id != @user_id
        @var1 = @var2 = @var3 = nil
   end
end

The model should not really override the controllers job of pulling the data together for a view.
So rather than zeroing out data that a logged in user should not see, why not just get data that a user is allowed to see ion the first place.
That is the responsibility of a model. The controllers job is to ask the model what data this user is allowed to see.

This kinda slightly touches on an awesomely simple explanation here
http://m.onkey.org/how-to-access-sessio … t-in-model

In the same way sessions should not be accessed in models, controllers instance variables should not be accessed in models. They should be passed in as parameters to a method in a model rather than accessed directly.

What you want and what you need are too often not the same thing!
When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.
(Quote by me 15th July 2009)