On 1/16/06, Mufaddal K. [email protected] wrote:
I have often found that regardless of the technology it is important to
work on the design by getting a good understanding of the use cases and
then start creating the database model and laying that out. Getting the
database normalized is eventually an incremental process that changes
and grows as the needs of your application changes (ie different use
cases being added or removed etc).
My two cents on this is to work on this incrementally from both sides
(the two sides being the persistence layer and the view layer).
I’m working on a project now where I’m trying out a completely new
approach (for me anyway). It’s based loosely on the some of the ideas
presented in Joe Gregorio’s column on how to develop a REST-ful API
(How to Create a REST Protocol)
The hope is that by designing my application with a similar process,
it will help to make it much easier to expose it via a web service or
REST api.
First, I started with the domain model. I know fairly well what the
schema should look like, and what the relationships should be. So, I
create models using
./script/generate model Thingy
And I start writing tests for the model to ensure that I’ve got the
relationships correct, etc.
For the controllers, I have an OmniOutliner document (but you could do
it with plain text just as easily) with 4 columns - this is where I’m
stealing from the REST ideas.
Action: This is something like “Create a new thingy” or “Get all
widgets associated with thingy”
Representation: This is the URI for the Action, e.g. /thingy/show/[id]
Tested: A checkbox, checked if an Action has been written and tested
Method: GET, POST, DELETE or PUT
Then I create a controller (by hand as opposed to generating it, but I
suppose I could do either), and a controller test and I start doing
TDD.
I walk through the outline, and for each action in the outline I write
a test, and implement the action. For the views, at this point, I
don’t care what they look like at all. I just know that on the “Get
thingy” action I need a div that represents the thingy, so I test for
this:
...
With something like this:
assert_tag(:tag => 'div',
:attributes => {
:class => 'thingy',
:id => 'thingyt_' + thingys(:first).id.to_s})
If I get to a controller action which requires something I haven’t
implemented or considered in my domain model, I go back to that and
start writing unit tests.
It seems to be going OK so far. I’m a little worried that I’m not
doing enough “assert_tag” assertions, so I might be missing something.
But as a process it seems to be working.
Lance
Lance B.
http://lance.langwell-ball.com