Re:Ask YC: Should I use a framework or just write the code m...
by DanielBMarkham on Thursday November 15, 2007 @11:05AM
(#80227)
There's a lots of answers to your question, John. I'll try giving you a couple.
One -- I might want my data to live in multiple places. For instance, I had an app I wrote recently that could persist its data to and from three places -- SQL, a funky XML format, and a private file format. That's too much read/write crap to pollute my app with.
Two -- I might want my data to live in multiple versions. If you've got multiple versions of your data format out there, such as if you were Quicken or something, you want to change/modify the data code in one spot, not all over the place.
Three -- the job of writing the UI is different than the job of knowing about data. Whether it's one box or ten thousand, one table or five, why should I care/know where the data lives? I'm writing the UI for goodness sakes. Just make the stupid stuff go away and come back when I need it. One well-constructed data tier should be able to service a hundred UI developers.
When coding imperatively and using a "short-cut" data access paradigm like RoR or CodeSmith and NetTiers (my favorite), the temptation is to start thinking well gee, if every table is an object, what's the point? Why not just hit the database directly? The answer is that you're coding just using a big shortcut -- it ain't going to work all the time like that. You have to know why the shortcut works and why it doesn't work.
One -- I might want my data to live in multiple places. For instance, I had an app I wrote recently that could persist its data to and from three places -- SQL, a funky XML format, and a private file format. That's too much read/write crap to pollute my app with.
Two -- I might want my data to live in multiple versions. If you've got multiple versions of your data format out there, such as if you were Quicken or something, you want to change/modify the data code in one spot, not all over the place.
Three -- the job of writing the UI is different than the job of knowing about data. Whether it's one box or ten thousand, one table or five, why should I care/know where the data lives? I'm writing the UI for goodness sakes. Just make the stupid stuff go away and come back when I need it. One well-constructed data tier should be able to service a hundred UI developers.
When coding imperatively and using a "short-cut" data access paradigm like RoR or CodeSmith and NetTiers (my favorite), the temptation is to start thinking well gee, if every table is an object, what's the point? Why not just hit the database directly? The answer is that you're coding just using a big shortcut -- it ain't going to work all the time like that. You have to know why the shortcut works and why it doesn't work.