A web app need a database and direct SQL is often cumbersome, resulting in home-grown ORMs. Active Record is highly complex, and encourages conflation of the database access code with domain logic. This is almost always a bad idea and provides very little benefit over separating these concerns.

A web app should have a clear way to access a database, and should provide a simple API that allowed manipulating a row in the database as a struct in the code. For example, the name field of the widgets table should be accessible via the #name method of some sort of Widget object. That said, naming database-accessing classes after domain concepts makes it hard to separate these two concepts.

We reject a flexible, pluggable data layer as this is highly complex and generally exists to support matters of taste, which are not valued. We also reject the active record pattern as this creates difficult in code management as well as design complexity when deciding where and how to store data and how to manage business logic. The web framework should encourage these concerns to be separated.

The hope is that data access can be clearly defined behind a boundary, accessible via a well supported, well documented, and well understood framework.

The primary downside is that this is different from Rails. This is OK, and we feel developers will enjoy the benefit of separating data access and modeling from business logic. Ruby's Forwardable module can be used if a domain object needs to behave like a database object.

By separating database access from any sniff of domain logic, developers will have an easier time managing their business logic. They can use a service layer or service objects, or they can create fleshed-out domain objects. No matter how this is managed, the code to access the database can remain stable and clearly defined.