1

Ì am currently working on a ASP NET MVC project. We use Entity Framework and follow the Database First approach. The database already exists. The database has been created using the convention, that every table has a specified single primary key, even if it is a junction table.

Example :

  • Table User : UserId (PK); Username

  • Table UserRole : UserRoleId (PK); UserId (FK); RoleId (FK)

  • Table Role : RoleId (PK); Rolename

As said, the database already exists and this convention is not discussable. When I want to create an Entity Data Model in Visual Studio, I also have three Entities. But it would only make sense to have two Entities: User and Role. The UserRole Entity makes no sense.

Is there any possibility I can influence the way that Entity Framework maps my tables, so I can get rid of those relational (useless) entities?

ckonig
  • 1,234
  • 2
  • 17
  • 29

1 Answers1

1

Is there any possibility I can influence the way that Entity Framework maps my tables, so I can get rid of those relational (useless) entities?

No, you cannot force EF designer to do that. When using automatic tools you will always end with junction table mapped as a separate entity because it is not considered as junction table any more - it has special data (a separate key) which gives this entity new possibilities (for example relation between two entities can exist multiple times which is not possible with normal junction table).

The only way to avoid this is abandon tooling support and use either code mapping or manually write EDMX file and don't tell EF about that additional key. Instead let EF believe that there are only those two FKs forming composite PK as expected from junction table. Obviously if your database requires those special possibilities allowed by separate PK you cannot do this.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • This is not the answer I was hoping for, but thanks anyway. I guess I will try to discuss the undiscussable convention ;) – ckonig Mar 19 '12 at 13:11