What is the purpose of Active Records?

Active Record is a design pattern for data access...

At the moment there are two main design patterns I seem to come across regarding data access: ActiveRecord and the Repository Pattern

Active Record

Your objects contain methods for persisting their state to a DB (or other persistence mechanism) so:

You may have a Customer object.

Customer object will have a bunch of methods like Customer.Save();, Customer.Get(int id); and others.

These methods do not really have anything to do with a customer in the real world. They are really about the infrastructure of your application.

Repository Pattern

In repository pattern, your customer object would be a POCO, or dumb object. It only has methods and properties that it really needs to represent a customer (things like name, email address, List orders, etc.)

When you want to persist the customer - you simply pass it to your repository

Repository.Save(MyCustomer).

The Active record pattern is quick and easy to work with. Unfortunately, it does clutter up your domain model with these methods which do not really have anything to do with a Customer. This makes it slightly harder to maintain your domain model over time.

For a lot of situation it is very appropriate to use an Active record pattern. For example - If I'm writing a fairly simple app that is probably not going to change much, I'd probably fire up SubSonic and generate my an Active Record DAL. I'd be coding my business code within 20 minutes and all the DB stuff is taken care of already.

If, on the other hand, I am modelling a particularly complex domain, with high susceptibility to change, I'd rather keep my domain models clean, and implement a repository pattern with nHibernate or similar...

It's been a long time since I rolled my own data access using ADO.Net, and I don't really recommend it now there are so many great data access tools available.

The "Active Record Pattern" is becoming a core part of most programming frameworks. It makes simpler CRUD (Create, Update, Read, Delete) tasks quicker to achieve. For example rather than having to write many SQLs to Insert, Update and Delete many common and simple data objects, it allows you to simply assign the values to the data object and run a command e.g. $object->save(), the SQL is compiled and executed for you.

Most frameworks also implement data relationships within their respective Active Record models which can greatly simplify accessing data related to your object. For example, in CodeIgniter, if you specified that a Category "has many" Products then after loading the Category object from the database, you can list it's child Products with a simple line of code.

foreach ($category->products as $product) {  echo $product->name;}

Another benefit of Active Record is, as you say, that it makes your code easily portable to different database platforms (so long as the framework that you are using has a driver for your chosen database) and although this is not likely to seem important right now, it my have greater value at a later date if your application becomes popular!

Hopefully this will have helped. Wikipedia describes Active Record well (http://en.wikipedia.org/wiki/Active_record_pattern) and the CodeIgniter docs will aswell. Personally, I use KohanaPHP (http://www.kohanaphp.com) which is a PHP5 only fork of CodeIgniter and I find that it's ORM models are very useful!

I could give my own view on this pattern but the best coverage of Active Record (and many others) is Patterns of Enterprise Application Architecture by Martin Fowler.

From chapter 10:

Active Record

An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.

An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their data to and from the database.

...

When to Use It

Active Record is a good choice for domain logic that isn't too complex, such as creates, reads, updates, and deletes. Derivations and validations based on a single record work well in this structure.

...

Active Record has the primary advantage of simplicity. It's easy to build Active Records, and they are easy to understand. Their primary problem is that they work well only if the Active Record objects correspond directly to the database tables: an isomorphic schema.

If your business logic is complex, you'll soon want to use your object's direct relationships, collections, inheritance, and so forth. These don't map easily onto Active Record, and adding them piecemeal gets very messy. That's what will lead you to use Data Mapper instead