Scribd
Upload
824 views

Physical Models and Logical Models in Rails

Physical Models and Logical Models in Rails dan chak. Physical models mapped to database tables through ORM; logical models mapped by you. Chak: relegate the ORM to where it belongs: Physical Model management.

Uploaded by

danchak
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
824 views

Physical Models and Logical Models in Rails

Physical Models and Logical Models in Rails dan chak. Physical models mapped to database tables through ORM; logical models mapped by you. Chak: relegate the ORM to where it belongs: Physical Model management.

Uploaded by

danchak
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

Physical Models &

Logical Models
in Rails
dan chak ([email protected])
Nov 11, 2008
Less about “Enterprise” in
terms of buzzwords and
integrating with specific
enterprisy things.

Instead: Soft ware


Engineering in Rails.

Enterprise This talk is not an explicit


chapter. It touches on

Rails many areas so concepts


spread throughout.

This talk is a distillation of


a single theme. Maybe
separate chapter in 2nd
edition!

Dan Chak

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: Remember skinny-controllers, In a concept that is the
has many, has one, habtm, fat models? composition of t wo models,
belongs to neither is the right place to
Over time, fat models forces you shove methods which touch
Non-standard column names to create new non-db-backed both.
models, because models diverge.
Magic columns:
position for lists So, skinny physical models, too.
parent/child count for trees Fat logical models.

Facade column getter/setter


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.
1. Requests
intercepted by

request
controller

est
es u

u
req

req
External API 11 External API 2. Controller maps
(#1) & Logical
models (#2)
controller
Skinny request to logical
match closely controllers
model objects
21

#3 transition
3. Logical model maps
persistence
Logical Model API Logical / Object
is the heavy Models
lifting 31
Physical
Model
Physical
Model
Database Bridge /
ORM
operations to
41 ORM physical models
Physical
models simple; 4. ORM translates
straight ORM
mapping between Ruby
Database
objects and data
layer
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?

You might also like