Entity Framework designer not effective anymore

Question

At my current workplace, Entity Framework 5 is used for all data access/manipulation.

It is a database-first approach using the model designer to add/edit/delete/update entities.

Problem

We now have tons of tables and this is becoming a nightmare to update. The model is very convoluted and it can sometimes crash the IDE. I'm not super clued up on the Entity Framework side of things, but surely this isn't the recommended approach. I have never liked the designer from the beginning. WYSIWYG-like designers spell trouble in my eyes.

Solution?

Structural changes to the database are essentially done by DBAdmins so we can't do code-first (anyway, I prefer not to have database tables generated).

Is there a better approach to this? Shouldn't we be using an XML-based mapper instead of using the designer. What about code-first to the existing database?

Answer 1

You should consider a few things. Most importantly, don't use one big huge model for your whole app. Create different models focused on your sub-domains. (This is my advice whether you are using code first or using the designer) If you can't give up this big model and don't want to flip to code first, take a look at the EF designers by LLBLGen and DevArt.

Answer 2

We had the same situation and we turned into the code-first approach. Because essentially what EF Designer does, is to:

1. Generate some classes for you
2. Map those classes to equivalent database entities

Which is the essence of every ORM. EF designer is only a utility or facility out there, to save you time from writing hundreds of codes of entities. Thus in code-first, the major difference is that you should write the code yourself.

However, since you say that DBA changes the DB, I recommend two things:

1. First, talk to him to follow OCP in database level too. Once a table is used in many places in code, it's better no to modify it, but to extend it.
2. Create a powerful mapping test for your data access layer and your models. We have this. Each time we encounter a bug, we first run mapping tests to make sure that our classes are mapped correctly to our database, then we search other places.