Ruby on Rails® for Microsoft Developers

7.3. Object-Relational Mapping

.NET developers are used to dealing with Connection, Command, Parameter, DataAdapter, DataReader, DataSet, DataTable, DataView, and so on. Most would probably agree that ADO.NET is very powerful, but its architecture veers on the complex side. ActiveRecord, on the other hand, strives to achieve elegance and productivity through simplicity. It all revolves around one concept, the model, which is a class that inherits from the ActiveRecord::Base class. As previously stated, that model represents a certain table in the database, and its instances represent the records within that table. It couldn't get much easier than that.

The tradeoff is one that's typical of all highly abstract languages, libraries, or framework: a loss in flexibility, which is usually fully justified by the advantage in productivity and maintainability of the code. For example, a DataTable in .NET can represent an arbitrary table in the database, whereas ActiveRecord has certain, conventional expectations on the nature of the table. Try to create a table lacking an id column and then use the corresponding model, and you'll see what I mean.

The previous chapters employed the scaffold generator as a way to get a head start when it comes to building an application that would work with articles and comments. That command generated a whole lot of code for you, including your models. There will be times, though, when you'd like to create a model without the need to generate a whole resource ...