# Don't just dump code into your models

DevFeed: [Don't just dump code into your models](<https://devfeed.tech/articles/don-t-just-dump-code-into-your-models-20370.md>)

Original publisher: [Read original article](<https://blog.sensible.io/2014/04/19/don-t-just-dump-code-into-your-models.html>)

Author: sensible.io team

Published: 2014-04-19T16:05:00Z

Content type: opinion

Language: en

Sources: [Sensible](<https://devfeed.tech/sources/sensible.md>)

Topics: [mvc](<https://devfeed.tech/topics/mvc.md>), [Code](<https://devfeed.tech/topics/code.md>), [Ruby](<https://devfeed.tech/topics/ruby.md>), [Development](<https://devfeed.tech/topics/development.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [API](<https://devfeed.tech/topics/api.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [code](<https://devfeed.tech/tags/code.md>), [controllers](<https://devfeed.tech/tags/controllers.md>), [development](<https://devfeed.tech/tags/development.md>), [mvc](<https://devfeed.tech/tags/mvc.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [test](<https://devfeed.tech/tags/test.md>)

## AI overview

The article argues that the "skinny controllers, fat models" rule should not lead to oversized model classes. It presents MVC as a starting point for separating concerns and recommends introducing appropriate abstractions for services such as mailing-list subscriptions, improving configuration, testability, and dependency handling.

## Source excerpt

A few years ago there used to be a motto saying Skinny controllers, fat models. It was good at the time, because people thought all of the application code belonged into the controllers, and it helped them realize that it's good to have just a simple controller layer and push things down. The problem with this motto is that it's wrong. Just because you should have skinny controllers it doesn't mean you should have fat models. In fact, none of your classes should be fat. The reason we have MVC is that it is a good starting point for separating the concerns in your application. It makes it more obvious where you should put your code when you're starting out with your application. But this doesn't mean your application should be limited to just these three layers, quite the opposite. Every time you need to add a new service to your application, you should think about how you're going to be using it, and then build a sufficient abstraction on top of that. For example let's say that your application needs to automatically sign up newly registered users to a mailing list. You've even chosen a provider, say AWeber or Mailchimp, as both of these have a nice Ruby gem wrapping up their API, allowing you to subscribe the user with only a few lines of code. Here's how the naive solution might look like class User after_create :subscribe_to_mailchimp def subscribe_to_mailchimp list_id = ENV["MAILCHIMP_LIST_ID"] Mailchimp.new(ENV["MAILCHIMP_API_KEY"].subscribe(list_id, self.email) end end If you happen to like YAML files more than environment variables, you might write something like this instead def subscribe_to_mailchimp config = SomeGlobalYamlConfigReader.mailchimp Mailchimp.new(config["api_key"].subscribe(config["list_id"], self.email) end While this might make sense the first time you try this, there are actually many things wrong with this approach. Let's list a few: If the Mailchimp API is unavailable during the time you decide to create a new user, your after_save callbac