Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 3 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
maple_shaft: Are you advocating for code-first or is your "Dark Ages" comment directed at data modeling by DDL? I'd argue that just about any non-trivial system benefits greatly from starting with a sound data model. – Joel Brown Feb 20 '12 at 14:04
@JoelBrown And what are these benefits outside of tailoring DDL for improved performance? I am actually advocating that "Pre-mature optimization is the root of all evils." Why not design the application data model first, have the schema auto-generated while data access and business logic developers can begin development immediately? Unless you are 110% sure of certain performance bottlenecks before you start, I can't see a valid argument against this approach. If and when you run into performance issues later then address it later. – maple_shaft Feb 20 '12 at 14:15
Another factor is that often you'll get saddled with a legacy DB of some sort that you have to shoehorn into your model. Ideally, you would start fresh so you don't have tables like CustomerInvoice, InvoiceCustomer, MainInvoice, AuxInvoice, MainInvoice2, etc. and a myrid of stored procs that may or may not do something important but nobody knows exactly what they do. But, because there are huge amounts of data already in this clumsy structure, you have to find a way to deal with it. – jfrankcarr Feb 20 '12 at 14:55
@jfrankcarr (shudder) I wish I could travel back in time and sit in on the meeting room where the original schema designers are discussing design over a white board, and when the first one says, "Why don't we name this table MainInvoice2?", I can walk over to him slowly and proceed to beat him mercilessly with a Louisville Slugger, DeNiro style. But then this doesn't really solve the problem, it is more of a recurring fantasy that pops in my head while I wait for the build to be completed. – maple_shaft Feb 20 '12 at 15:11
You'll find that I've advocated against premature optimization, so we are in agreement on that point. My point is that data modeling is something that a lot of programmers are no good at and it is therefore given short-shrift much of the time. This is too bad because a slapped-together data model (even at the application level) is like having a vaguely defined foundation for a building. I believe that a carefully considered data model is an important first step in any new development. Whether this happens in a modeling tool or DDL isn't important in my view, just so long as it gets done. – Joel Brown Feb 20 '12 at 20:41

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.