How easy it is to update Entity Model from database when enough code has already been written?

Question

I am new to Entity Framework.

I know there is an option to update model from the database, but I want to know how easy and successful is this task. I may need to update my model in a few weeks but till that time many lines of code has already been pushed inside.

Is it difficult to track changes and make code work?

Answer 1

Code generators are a double-edged sword. You can build lots of complex code quickly and easily but you have to be prepared to live with the code you've generated. You can't (don't want to) customize this code because your customizations will be wiped out if you ever regenerate.

In my experience, recent versions of EF (say 4.x) are perfectly capable of regenerating from changes to a database.

As long as you've avoided the temptation to customize the generated code, you will be fine.

There is a caveat, of course. If your DB-side changes include modifications or deletions to previously existing items then any code that touches the ORM for those items will potentially be broken. This means any business logic or presentation layer code which uses modified database objects could be broken after updating your model.

You will need to do a thorough regression test of your existing code if any of your DB changes touch items that were already in your model as of your previous generation.

Answer 2

EntityFramework was originally designed with the "Model-First" approach as the preferred approach to building your Data Access layer, however many software shops still seem to live in the Dark Ages where they prefer to design the schema first and then the model to accomodate it. Okay, I may be a little unfair, if you have database intensive processing where stored procedures benefit performance then it can make sense to start at the database and work your way up.

Regardless, when I played with the early release of EntityFramwork, support for refreshing the model from the database existed, however it was somewhat buggy at first. This was years ago however and I remember reading that a lot of those issues have been worked out since. I hear nothing by great things about EntityFramework being used in this way.

Is it difficult to track changes and make code work?

This all depends if you are following an appropriately layered architecture with loose coupling. Ideally if the EntityFramework model changes then changes in the Data Access and Business Logic layers should be constrained to the layers that use the EntityFramework model.

Ideally if you are practicing TDD then your unit tests should fail and indicate which areas need refactored after a model change.

Answer 3

I've been doing some testing/learning projects with this recently and I've found that the update Entity from DB goes smoothly for the most part. You have to be careful to pick the right choice of tab and not screw everything up by using add rather than update. One of the downsides is that if you generate something wrong it's sometimes easier just to delete and start over than to try and correct problems.

I found the Entity to DB process to be less smooth, particularly when dealing with a Compact SQL DB. Sometimes weird errors would cause me to have to shut down VS and restart it and, after doing that, the generated scripts would work. However, sometimes the scripts weren't entirely correct and left out an index. This required a manual fix to the DB.

As Joel Brown mentioned, you want to avoid making changes to the generated code. However, you can use partial classes to add in functionality if you need to. I used this to implement IEquatable for some Entities since I needed it for a business layer routine.