For example, model objects in Rails
map neatly to the M in MVC, by handling database communication, validation, and internal logic. Controller
classes map to the C in MVC, and each public method in a controller corresponds to a separate action.
Finally, there is one separate view??”which is an RHTML file??”for each distinct action, unless you override
the rendering logic. All pieces are there.
When coding an application with Rails it is important to follow this separation of concerns in your own
code too. If you don??™t, many of the benefits you can get from Rails will be void. In real terms, this is simple:
never write any code in the view templates that contains business logic in any way. If you find yourself using
much code in RHTML, be suspicious. It??™s not always a sign that something is bad, but it could be. If you need
lots of presentation logic, try to abstract it and put it into helper methods. By the same token, try to refactor
all logic that concerns the model into the model classes. Make your controllers as clean as possible. Look at
the code generated for scaffolds for examples of how to write controller logic that only contains what??™s
necessary for the controller. Finally, any view information should not be found in the model objects. This is
probably one of the few things I object to in the Rails framework. Validation messages are usually placed
inside the model objects, together with the rest of the validation rules. However, because this is view information,
it??™s certainly not the right place for it.
Pages:
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89