Enterprise Rails

Creating an Abstraction Barrier

In the first half of this book, we concentrated on third normal form (3NF) and domain key/normal form (DK/NF). In this chapter, we’ll move away from this normalization restriction when we create an object model. That may sound surprising, given the emphasis placed on normalization at the data layer, but as we’ll see, normalization won’t help us here.

Before we proceed with creating an object model, we first need to understand what one is and what it’s not. Therefore, we need to take another look at ActiveRecord, from the perspective of the application as a whole. Once we’ve done that, we’ll see how an object model fits into the picture.

ActiveRecord As the Physical Model Layer

Think back to earlier chapters in this book and recall your thoughts as a simple schema turned into what at first glance may have seemed like an overly complex one. In many ways, that more intricate data model was easier to deal with because it removed the possibility of recording or producing incoherent data, which itself is no picnic to deal with.

Often developers shy away from highly normalized schemas because the abundance of tables and relationships seems too distant from the end result they hope to display on a web page. The data presented to users on web pages is usually not normalized, and if you work from display to schema, it will seem onerous (or even pointless) to obsessively normalize your data.

Such a perspective seems hard to argue against; what’s missing is a key ...