Top Down vs. Bottom Up

I used to start building new applications by writing the model and persistence layer. I'd flush out my model, then build the persistence on top, and then go about writing the view. I will not likely use this approach ever again.

I'm currently working on a MonoRail application where I'm taking a different approach. I've been start at the controller and view level and been working downward. When I reach a point where I need to work with the model and persistence, I instead define an interface and an appropriate model that would be ideal for the specific use case I'm working on.

I've found myself stubbing out implementations to these interfaces, instead of actually creating the database and persistence logic. A huge win that I've found is that I'm able to test the web application without a database! It makes changes and refactoring take a fraction of the time because I don't have to worry about updating the ORM mapping, database tables, etc. I also save myself from writing unneeded functionality in the model and persistence layer. But being able to see the application interface using mock data and not ever actually hitting the database have both been a huge benefit. The time to do a write/compile/test cycle has been greatly reduced. I have less code in my codebase that I'm not actually using.

I believe this approach matches the TDD style of development a bit better than what I'm used to doing as well. Write the API that want to use from the top down, not the API that you think you'll use from the bottom up.

My inspiration was this post was list of best practices that John-Paul S. Boodhoo jotted down about a course he was taking. There's lots of other great stuff his notes as well.