So Rob Conery wrote a really cool post the other day that I just had to comment on.
Here’s my thought for you: What if you used an OODB for development ONLY and implemented SQL Server later, when you know what you need to create.
It made me wonder; how many applications really, really need a full on RDBMS (Oracle, Sql Server etc.) as backend? I wouldn’t know, but if I were to guess I’d say; not all. Vague, I know… 😉 But I do know this; my next project will use Db4O! I just have to try this stuff out!
Crazy Talk: Reducing ORM Friction : Rob Conery
In my opinion (IMO) there is only one proper way to hide database/implementation specific stuff; Use a Data Access Layer (DAL). Whatever lies behind that can be as ugly-bugly as you want to, as long as it returns data according to a set of defined rules. I generally like the “EntityDataManager” naming convention; CustomerDataManager and OrderDataManager. Or use Agent instead of manager, it sounds cooler. We actually have a UIAgent class responsible for converting/formatting data depending on the clients UI.
SPs or Inline? If you have a very complicated, and perhaps old, database SPs might make more sense. Just to hide the worst of the database stuff from the DAL. But you can do alot with views too…
PaulStovell.NET » The Inline SQL application – Six Months Later
Looking forward to the day Microsoft implements Oracle support in Data Dude, so we can use it to. Or, even better, we drop Oracle support all together!
Link to CoDe Magazine – Article: The Data Dude Meets Team Build