# Where to define callbacks? Model vs model\_oberver **URL:** \ **Category:** Rails\ **Created:** [July 13, 2008, 12:19pm UTC](https://www.ruby-forum.com/t/where-to-define-callbacks-model-vs-model-oberver/142912 "2008-07-13T12:19:12Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\ **Post date:** [July 13, 2008, 12:19pm UTC](https://www.ruby-forum.com/t/where-to-define-callbacks-model-vs-model-oberver/142912/1 "2008-07-13T12:19:12Z")
Hi guys, I am wondering where I should define my callbacks. I have a user model and a few callbacks: before\_save, after\_save, etc. I can define each callback in the model, but it is getting a bit messy and overcrowded especially as I am using restful\_auth. The other option is to move the callbacks definitions in a user\_observer. However restful\_auth which is supposed to be an example for good coding practice defines before\_save :encrypt\_password inside the model. So what to do? 1. Stuff callbacks inside the model, but the model can become a mess 2. Separate callbacks from model, this is a step beyond mvc, cleaner, but it requires having to move back and forth between files and remembering to register the callbacks. How do you do that? What is today’s commonly accepted best practice? What about validations? For instance before\_validation, shouldn’t I also move it to an observer? ---
**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\ **Post date:** [July 13, 2008, 12:59pm UTC](https://www.ruby-forum.com/t/where-to-define-callbacks-model-vs-model-oberver/142912/2 "2008-07-13T12:59:30Z")
Hi – On Sun, 13 Jul 2008, Fernando P. wrote: > defines before\_save :encrypt\_password inside the model. > What about validations? For instance before\_validation, shouldn’t I also > move it to an observer? I’ve always felt that one of the nice things about AR model files is that you can put a lot in them and they _don’t_ turn into a mess. Long, maybe, but not messy. One thing you could do if you want to trim the files is put some of the methods themselves in separate modules and separate files, and then just have the callback declarations in the model file itself. David – Rails training from David A. Black and Ruby Power and Light: Intro to Ruby on Rails July 21-24 Edison, NJ Advancing With Rails August 18-21 Edison, NJ See [http://www.rubypal.com](http://www.rubypal.com) for details and updates! ---
**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\ **Post date:** [July 13, 2008, 1:41pm UTC](https://www.ruby-forum.com/t/where-to-define-callbacks-model-vs-model-oberver/142912/3 "2008-07-13T13:41:13Z")
Hi David, I liked your book very much. Organizing code in modules is a better idea than having to handle the observer file. I consider that callbacks calls have to belong to the model, but their actual code could actually be in another file, in order to be a bit more readable. I’ll follow your advice and use modules. Best regards, ---
**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\ **Post date:** [July 13, 2008, 3:48pm UTC](https://www.ruby-forum.com/t/where-to-define-callbacks-model-vs-model-oberver/142912/4 "2008-07-13T15:48:12Z")
When I had this concern some months ago, the advice that I found was this: if the callback directly affects the model (e.g., hashing the user’s password), declare it in the model; if the callback uses the model to do something else (e.g., log the fact that the user was changed from active to inactive), declare it in an observer. This rule of thumb has worked very well for me. I would rather see modules used to give a home to commonly used code instead of to house code for a model that seemed like it was becoming to large. If you have that sense about your model, consider the possibility that it simply does carry that much responsibility in its domain, or it’s carrying too much responsibility and the design of the domain should be reconsidered. Using modules to just move code around feels like the wrong approach to good domain design. Regards, Craig On Sun, Jul 13, 2008 at 7:41 AM, Fernando P. \< ---
**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\ **Post date:** [July 13, 2008, 4:33pm UTC](https://www.ruby-forum.com/t/where-to-define-callbacks-model-vs-model-oberver/142912/5 "2008-07-13T16:33:58Z")
I see what you mean Craig. I’ll think about it, and figure out what I am the most comfortable for me. ---
**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\ **Post date:** [July 14, 2008, 1:44pm UTC](https://www.ruby-forum.com/t/where-to-define-callbacks-model-vs-model-oberver/142912/6 "2008-07-14T13:44:20Z")
Hi – On Sun, 13 Jul 2008, Craig D. wrote: > simply does carry that much responsibility in its domain, or it’s carrying > too much responsibility and the design of the domain should be reconsidered. > Using modules to just move code around feels like the wrong approach to good > domain design. My preference is to leave stuff in the model file; as I said, I think model files can usually handle growth very gracefully. I like your observer rule of thumb. But I don’t entirely agree with what you’re saying about modules. Modules are of course great for reusable code, but if there’s a bunch of functionality that seems like a good candidate for a module, but only one class is going to use it, I don’t like to penalize that class for being the only user of the module by refusing to create the module. I’d say the same thing about a partial template, and most other modularizing tools. Similarly, while I definitely don’t advocate using modules just to shorten a file (e.g., throw the last 50 lines in a module called “ClutterFree”), I don’t think modules are a danger sign, in terms of design, if there’s a rationale for what goes into the module. The questions of whether the model aligns correctly with the domain and whether the domain needs reworking can arise even in the case of very short model files (like, two lines long 🙂 and on the other side I can imagine a model loading modules that make perfect sense for what it’s doing. So I’d tend to decouple the well-designed-domain question from the does-a-model-load-modules? question. David – Rails training from David A. Black and Ruby Power and Light: Intro to Ruby on Rails July 21-24 Edison, NJ Advancing With Rails August 18-21 Edison, NJ See [http://www.rubypal.com](http://www.rubypal.com) for details and updates!