0

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?

  • 1
    You can use EF Power Tools to reverse-engineer 'code-first' (not the most fortunate naming choice, IMO) mappings from existing database. When I'm using EF, that's what I'm usually doing and then just tweaking it manually where I need to. – Patryk Ćwiek Sep 2 '13 at 15:23
  • Having dozens of tables in a single model may indicate that you are not separating concerns well enough. – CodeART Sep 2 '13 at 15:31
  • @CodeWorks: Should we essentially have multiple edmx models? I never thought about that. Certain entities would need to be in all models then I assume (like User and Logging tables) – Dave New Sep 2 '13 at 15:38
4

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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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