It’s a database. It comes with Rails. It models the behavior of objects in a Rails app (known as Object-Relational Model or ORM) while also establishing a place for the data that those objects collect to live and later interact with (known as persistence).
ActiveRecord is a library of Rails. It provides a base class (ActiveRecord::Base) that, when subclassed (class Product < ActiveRecord::Base, also known as Models), sets up a mapping between the new class and an existing table in the database (which is Base if none other exist?). Models can also be connected to other models by defining associations between the models (the relational part like has_many :model_name, belongs_to :model_name).
Views and Controllers are tightly coupled with Models (MVC anyone?), making tests long and confusing. One school of thought is that Domain Logic should always be separate from Table Logic (what I’m calling it) — “Objects expose behavior while data structures have no behavior.” – Uncle Bob, Agile Manifesto
It’s easy to extend model and controller objects over and over again which creates huge, crazy objects that get too hard to trace down through the many different controllers and models using them. So, to avoid this, small pieces of code should be extracted into their own classes. This makes things less messy plush speeds up test execution, and clarifies naming concepts in the system (that were previously implicit, which is impossible for a programmer to keep track of), and adding explicit abstraction layers. Basically, to counteract the ActiveRecord setup, keep your code object-oriented by pulling out pieces of model logic that is embedded in a controller so it has its own class with isolated tests.
bec's blog 