5 ms·

It's probably just that the example is overly simple, but... 1. The spec speed up is from good mocking, not the service object approach. 2. Tying behavior to

It's probably just that the example is overly simple, but... 1. The spec speed up is from good mocking, not the service object approach. 2. Tying behavior to persistence is appropriate when it's appropriate, i.e. when it happens every time the object is created/updated. He's right that a slew of after_save callbacks is obnoxious, but Rails' observers already well encapsulate such behavior. 3. In this example case, logging isn't appropriate, because he doesn't want to create an activity feed when a user is created. Instead, he only creates an activity feed entry when a user is created on the website, i.e., through the controller. In that case, it would be perfectly reasonable to include the log creation as another line in the controller code in the success branch of "if User.create(params)". For this example specifically, if that happened in many controllers it could just as easily be a method in a module that was mixed into them ("create_user_and_log"), or even a User class method ("User#create_and_log"). It's a stylistic choice rather than an architectural choice. That's not to say the approach is without merit—it definitely has some. But what you're really doing is trading a "controller level" unit test (I've always hated that they're called "functional tests" in Rails) for a regular "class level" unit test. If that sort of encapsulation floats your boat more than, say, a module for your controllers, then by all means. I just don't see anything crazy, or heretical, or awesome here.

epochwolf 15y ago
I use the controller mixin approach. My controller has two public methods: event and save_record. This is how they are used: def create event(:create, @literature, :notify => current_user.follows_by.users(:literature)) unless params[:skip_event] if save_record @literature, &set_creator redirect @literature , :notice => "Literature was created." else render_form end end Here's the code: https://gist.github.com/1120260 https://gist.github.com/1120260
Periodic 15y ago
I haven't used rails in quite some time and have been publishing with Yii lately instead. It feels very similar. I feel like the right thing to do would be to dynamically mixin behaviors based on whether you are in the console or not. Though I guess that changes behavior between tests and production which could defeat the purpose of the tests. Right now the big ones are that our console needs to deal with permissions and there is no user logged in via the console. Simply skipping permissions modules when in the console has been one solution.

epochwolf 15y ago

I use the controller mixin approach. My controller has two public methods: event and save_record. This is how they are used: def create event(:create, @literature, :notify => current_user.follows_by.users(:literature)) unless params[:skip_event] if save_record @literature, &set_creator redirect @literature , :notice => "Literature was created." else render_form end end Here's the code: https://gist.github.com/1120260 https://gist.github.com/1120260

Periodic 15y ago

I haven't used rails in quite some time and have been publishing with Yii lately instead. It feels very similar. I feel like the right thing to do would be to dynamically mixin behaviors based on whether you are in the console or not. Though I guess that changes behavior between tests and production which could defeat the purpose of the tests. Right now the big ones are that our console needs to deal with permissions and there is no user logged in via the console. Simply skipping permissions modules when in the console has been one solution.