My recent work has had me diagnosing some fairly common issues that one sees from developers moving from a language like PHP to Ruby on Rails.  The PHP philosophy (as I remember it) is to not restrict how you work and to seamlessly weave your code and your views together.  For very small websites this is fine.  I’ve even been told that this works really well for situations where most of the work is happening elsewhere (think Actionscript and Flash), which forces a kind of modularization.  Regardless we end up with lots of code and the persistence/database ends up being where we put things to remember them.  I’ve started calling this logic-driven design.  I’m not sure if I’m stealing someone else’s term, but it communicates the essence of the idea.

Logic-driven Design
To me LDD has a few key markers that make it stand out:

1. The persistence engine is used to store data and little bearing on the logic of the larger system.
1. There is no abstraction layer in which to place business logic.
1. The business logic emerges out of the flow of logic, rather than from some modular abstraction.

Most PHP programs that I have looked at fall in to this category.  Only as the project size grows past a certain complexity does one see PHP projects with more explicit abstractions around the persistence layer.  The reason this is done is because at a certain size in a project a programmer can no longer track all lines of logic in their head and continue to develop the application efficiently.

Data-driven Design
This addition of an abstraction layer around the persistence engine that is used for managing business logic is what has been called data-driven design.  This is obviously not a new idea.  In fact one of the points of pride for me in using Ruby on Rails is it’s particular grace in working in this manner.

Data-driven design aims to drive the logic and output of the application directly from the persistence engine; the data source.  The convenient side-effect of this design approach is the adjustment of most of the business rules and how the application behaves is matter of changing records in a database.

PHP to Ruby on Rails
Ruby on Rails employs an MVC architecture.  This architecture is designed to support data-driven design by providing a powerful abstraction layer for the persistence engine (the model).  Rails has a particular sweet spot for social web applications for this reason.  The framework excels in user generated content, as this is a form of data-driven design.

Developers moving from PHP to Rails often miss this shift in thinking when they make the jump.  The result is code that is primarily located either in the controller or the view layers, since this is analogous to PHP’s logic-driven model.  The end result is very heavy controllers with big functions that do a bunch of logic on database records, and then render it out to the user.  In this paradigm the Rails models are only used to retrieve the record and nothing else.

When Rails moved from solely MVC to a resource-based approach a few members of the community had some negative feedback.  Some people feel like the resource concept makes development in Rails more complicated.  What I’ve seen in practice however leads me to believe that the real difficulty with the resource based approach is that it forces you to make the jump from logic-driven to data-driven.  PHP style development becomes contradictory in a resource based rails application.  Instead you have to think about the “resource”, the entity that will affect and be affected, and build your application around that.