a Entity Framework<->SQL database system,
I looked into this 6-8 months ago in the context of a personal project, and it seemed to me that the tools visual studio/.NET provides looked really good in principle, but lacked that last 5% to make them a complete system.
The first issue was "If I change my class structure, how do I update my DB schema in such a way that the data in my existing DB isn't destroyed?" My recollection is that their system will generate an SQL script that you can run to update the DB, but if you e.g. add a column to a table (because you've added a property to an object) then the script essentially executes "blow away the existing table, then recreate it with the new list of columns" rather than "add all new columns, remove all removed columns". In other words, if you already had your class structure it was good at generating DB tables, but if you needed to change the class structures then it was equivalent to starting over.
Do you know how to coax the tools to do this automagically, or is there still a lot of grunt work involved copying things over and editting tables by hand?
The other thing I remember running into was with the non-license version SQL Server that you can ship with executables (SQL Server Express?) I think the issue was that you couldn't add items to a table with a pre-specified key (i.e. you needed to let the table auto-generate the key), which meant that the automated binding tools didn't work right and you had to work around it in your class objects by hand. Do you know if they've fixed this?
Like I said, this was a while back so I might have distorted the details, but the 50,000 foot observation that it didn't seem to fully work out of the box stands. Or is that what you meant when you said "creating a framework" - there's some standard trick to automagically persist your DB information across architectural updates, but that one needs to implement that trick?
John
PS - This is just curiousity, not relevant to your Aurora efforts.