Models and Controllers

When the generate script creates a model, it creates a subclass of
ActiveRecord. Is this to say that every table - even pure support tables
such as a table for state codes - should have a model?

And what is the relationship of models to controllers. It seems there’s
no problem with a controller handling several models, but is there a
rule of thumb on how these relationships should be laid out.

Thanks for your thoughts on this.
—Michael

If you use those tables why not creating model for quick and easy CRUD?

On Oct 6, 2006, at 7:44 PM, Michael S. wrote:

even pure support tables
such as a table for state codes - should have a model?


Emanuele T.
mob +39 329 29 56 995
icq 30 77 52 76
web mekdigital.com

When the generate script creates a model, it creates a subclass of
ActiveRecord. Is this to say that every table - even pure support tables
such as a table for state codes - should have a model?

No, on the contrary this is to say that every model is supposed to have
a persistency attached (simple case: 1 table).
The most common case of a table not having a model attached is the “join
table” in a habtm relationship.

And what is the relationship of models to controllers. It seems there’s
no problem with a controller handling several models, but is there a
rule of thumb on how these relationships should be laid out.

Rule of thumb? Difficult to say…

I would suggest: run away as soon as you can from the “scaffolding”
programming model.
It could give you the wrong feeling that you have a 1 to 1 relation
between models and controllers. Not all the applications are “model”
centric, you can have controllers not relaying on anything but a
“virtual” model (think, for instance, of a controller doing the
+,-,*,/,% operations on any couple of integers).

For a “blog” like application you want to have several controllers using
the same model (Authentication and Blog use Person) and models (like
Comment) not having their own controller.

mauro

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs