some notes on Entity Framework

The code first approach comes with some troubles. A DBA cannot just add a column at a table and expect that to be matched by a developer adding a corresponding getsetter on a POCO. The change has to be hydrated to the database from the code. Data Migrations with Code First expect a very specific configuration and are otherwise sabotaged if code first is not indeed, code first. Code first and the "read from schema" .edmx thing are BOTH bad as it turns out, but we are not stuck with just two bad choices as it turns out. There is another approach called Reverse Engineering Code First which creates classes off an existing schema. You should not, with this approach, start with Code First and then generate a second code base off of drinking up the database tables as the two code bases will be different. You need to start with the database. I was told all this verbally yesterday and I also learned that the hydrated code from the database all ends up in one folder and that that folder may just be destroyed and rerendered when the schema changes. When my mind attempts to picture this it also pictures that that which I would put in the Infrastructure and that which I would put in the Core in an Onion Architecture to be sprinkled about in the same folder together. Maybe the third choice has a dark side?