Physical Models And Logical Models In Rails

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 Rails Dan Chak

http://enterpriserails.chak.org

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!

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

Remember skinny-controllers, fat models?

Non-standard column names

Over time, fat models forces you to create new non-db-backed models, because models diverge.

Magic columns: position for lists parent/child count for trees

So, skinny physical models, too. Fat logical models.

Facade column getter/setter

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.

11

req u

est

request

t es u req

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

External API

controller

Skinny controllers

Logical Model API

Logical / Object Models

21

#3 transition is the heavy lifting

31

Physical Model 41

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

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?