Updating the Model from database? Proper steps? RRS feed

  • Question

  • I am trying to use the EF on a new solution, but can't help deal with a lot of doubt that this is going to be a maintenance nightmare.  Right now, there are a lot of database updates and the development pattern I'm following is this: update the database, delete the EF files, delete the domain service, and rebuild them.  This has been the only way that I can update my code in a reasonable amount of time once a database schema change is made.  I can't see this working in production on anything larger than a trivial system.  I've read lots of threads related to this issue, and I'm not sure any had a really satisfactory answer. 

    Let's say I have Table1 which has a 1-* relationship with Table2.  We then drop Table2 as a design/requirement change made it unneeded. 

    We want it and all tentacles of it removed from the EF.  We update from database, and that really doesn't do much.  If we delete the entity out of the model, we now see exceptions all over the place, first that there are now unmapped objects.  Second that the domain service is broken (which is a whole other issue).

    So here's the real question: Is there a good, simple guide for changing data objects under the covers, specificaly deleting or renaming an object. 

    Not to sound negative, but we are really starting to question our commitment to these technologies and going back to a known model.  I'm quite fearful of the day when there are a hundred tables or so in production and we have to rename a couple or delete one.

    Any help would be greatly appreciated - I have to imagine this has been throught through, but I've not been able to find a succinct guide.

    I program in C#... but I can't bring myself to retire the 10 year old vbSlinger moniker...
    Tuesday, July 5, 2011 8:12 PM


  • Hello,

    your problem is absolutely not related to the technology. It doesn't matter if you use entity framework with EDMX, entity framework code first, data sets, linq-to-sql, nhibernate or pure ADO.NET. You will always face same problems. Updating changes for EDMX file works quite well. The fact that entity is deleted will do the same errors in any other technology - simply you removed a class which is used in your application and you must deal with it. I can't say what does it mean for domain services because I have never used them.

    The main problem here is too much changes in your database. Change is good - that is agile way but everybody must fully understand that change comes with its price. If your stakeholders understand that you spend half of the iteration fixing issues with those "changes" you can be pretty sure that they will start to put better and more correct requirements. I did several project's with Scrum methodology where changes were absolutely common but if we had never needed to delete more then two tables per projects. There were a lot of changes for properties but those can be handled much better. Even in agile project still have some scope, target and main entities related to these two. Tables rarely disappears. They can be refactored to other table but it always demands large maintenance of the existing code base.

    Best regards,

    Tuesday, July 5, 2011 10:19 PM