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 ...
Get Enterprise Rails now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.