Physical Models & Logical Models in Rails

dan chak (dan@chak.org) Nov 11, 2008

Less about “Enterprise” in terms of buzzwords and integrating with specific enterprisy things. Instead: Soft ware Engineering in Rails.

Enterprise Rails
Dan Chak

This talk is not an explicit chapter. It touches on many areas so concepts spread throughout. This talk is a distillation of a single theme. Maybe separate chapter in 2nd edition!

http://enterpriserails.chak.org

Problem:
The disconnect between Object Models and Physical Models, and the ORM
Talk at Rails Conf ‘08: “The t wo main modeling systems”

Why do you care?
Have you heard of... 1. Skinny controllers, fat models 2. REST or SOA 3. Changing business needs

Solution:
Relegate the ORM to where it belongs: Physical Model Management

How?
Recognize two distinct types of models in your code: Physical Models and Logical Models
Physical models are mapped to database tables through ORM. Logical models are mapped to your business problem. Logical models are mapped to physical models by you.

Paradigm Shift
Physical model files are nothing more than database configuration files, written in Ruby.
Relationships: has many, has one, habtm, belongs to Non-standard column names Magic columns: position for lists parent/child count for trees Facade column getter/setter Remember skinny-controllers, fat models? Over time, fat models forces you to create new non-db-backed models, because models diverge. So, skinny physical models, too. Fat logical models. In a concept that is the composition of t wo models, neither is the right place to shove methods which touch both.

Paradigm Shift
Object Models represent the business problem. 1. Not relational or normalized 2. Model API can change with no change to data store 3. Model API can stay the same while the data store changes

Think External API
thinking storage leads to one model -- the physical model. 3NF. thinking about API leads to another model -logical model.

External API (#1) & Logical models (#2) match closely

1 1

External API Skinny controllers

controller
2 1

#3 transition is the heavy lifting

Logical Model API
3 1

Logical / Object Models

Physical Model
4 1

Physical Database Bridge / Model ORM

ORM

Physical models simple; straight ORM mapping
Database

1. Requests intercepted by controller 2. Controller maps request to logical model objects 3. Logical model maps persistence operations to physical models 4. ORM translates between Ruby objects and data layer

request

t

u req

req u

est

es

iCalendar Event
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//hacksw/handcal//NONSGML v1.0//EN BEGIN:VEVENT DTSTART:19970714T170000Z bold parts can correspond to db columns, or can store DTEND:19970715T035959Z entire text in one column. SUMMARY:Bastille Day Party lots of these represent entire calendar for END:VEVENT storage. but is a terrible representation for END:VCALENDAR manipulation.

Calendar Physical Model
i_calendar_entries id version dstart dend summary repeat etc...

Calendar Logical Model

Calendar

*

Month

*

Day

*

Event

Implementation via Modules

N.B.
• Must respect module dependency. • Controllers => Logical => Physical • Never the other direction; never skip levels • Abstraction barriers

It’s not more work
(not much more, anyway) It’s better organization today, which leads to better code tomorrow.

Benefits
• Better organization • Clarity. It’s “logical.” • Better fit for REST interfaces • Maintainability across changes • Reliable Caching (See Chapter 20)

These concepts, and more...

Enterprise Rails
Dan Chak

questions?

Sign up to vote on this title
UsefulNot useful