On Sep 27, 2008, at 9:17 am, Matt Wynne wrote:
I wouldn't call this the 'rails way' particularly - I think it's
more of a general OO design philosophy that says the database is
just an implementation detail. I have gradually moved, over the
years, from feeling like the database needed to be the foundation of
my whole domain (and therefore have tight integrity rules etc) to
wishing it would just go away and stop bothering me. I like the way
ORMs let me work in code most of my day rather than having to drop
into the database to find out what the rules are.
Matt,
I agree with you - to am extent. The thing is, with a full suite of
stories (that work through the public interface) your *entire app* is
an implementation detail.
<aside type="anecdote">
The other day I was going over some example code with a client. I
prepared it for a user stories + Cucumber + Celerity talk/workshop,
although I don't think I'll need it now. It was a crude one-
controller CRUD (well CR, anyway) app written in Ramaze, for
simplicity. The plan was to build a fuller Merb app to build on
later. The only reason I was going to switch to Merb was because this
client is considering it, and was more than happy when I suggested
doing some research on it on my time. But I knew this could raise the
issue "the first one was a prototype, and Ramaze is a prototyping
framework". Even more so because the data store was this:
class EventsController < Ramaze::Controller
EVENTS = [ ]
# ...
def create
EVENTS << request[:event_name]
end
end
Which led us on to a discussion about what exactly *is* a prototype,
and what is a primitive production app. (I've had to pull the slides
for this, I think it'd be a talk on itself.) So I said, "Hmmmmmmm,
how long *would* it take to port to Merb?" Not wanting to let our
coffee go cold, I set to it... and 10 mins later, five of which was
faffing around working out the differences between Ramaze and Merb
controllers, it was running. Indeed, Cucumber told us so before I
loaded the page in a browser, as it implemented this:
Feature: Event creation
So that Potential Delegates know an Event is happening
As an Organiser
I want to create Events
# ...
Scenario: Multiple event creation
GivenScenario Successful Event creation
Given I am on the Event creation page
When I submit valid Event details for event 'My Second Event'
Then the Events index page should show 'List of events'
And it should show 'My Second Event'
And it should show 'My First Event'
And it should not show 'No events, please come back later'
Eventually my client decided that, on the basis that I evolved the
code rather than throwing it away and re-writing it, that it was
actually a primitive production app. And it stores the data in an
array in the controller. More surprisingly, he decided that - on the
basis it has no runnable specs - his own 2-year-old app serving
several clients is a prototype!
</aside>
So anyway, my point is, if you disparage the database on the premise
it's an implementation detail, you should apply equally little concern
to every other part of the app.
The reality I've found is that you find uses and insight in data long
after you initially decided how to model it - possibly long after you
stopped maintaining your app. And I've been in the situation of
having to unravel garbage and data corruption because someone didn't
enforce DB integrity.
I think every component of an app should receive the same attention to
quality. It's impossible to know where an edge case will sneak past
and bite you, so you have to cover as much as possible.
(Sorry if that was even rantier than usual - but I have a thing for
data quality!!!)
Ashley
--
http://www.patchspace.co.uk/
http://aviewfromafar.net/
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
