2009-11-19 8 views
44

Uso de VS 2010 beta 2, ASP.NET MVC.Problemas de asignación uno a uno de Entity Framework

Intenté crear un archivo Entity framework y obtuve los datos de mi base de datos.

Hubo algunos problemas con las relaciones, por lo que comenzaron a ajustar las cosas, pero me hacía cada vez el siguiente error de simples relaciones uno-a-uno

de error 1 Error 113: La multiplicidad no es válida en Role 'UserProfile' en la relación 'FK_UserProfiles_Users'. Debido a que las propiedades del rol dependiente no son las propiedades clave, el límite superior de la multiplicidad del rol dependiente debe ser *. myEntities.edmx

Mi mesa 2.024 usuarios es consta de algunas otras relaciones muchos-a-muchos a otras tablas, pero cuando intento hacer una relación de uno a uno con las otras mesas, que el error aparece.

Usuarios Tabla

  • UserID
  • nombre de usuario
  • correo electrónico

etc ..

UserProfiles Tabla

  • UserProfileID
  • identificación de usuario (FK para los usuarios de la tabla)
  • Ubicación
  • cumpleaños

Respuesta

65

Para las relaciones uno-a-uno, EF espera que las mesas están utilizando la misma clave primaria. Y realmente, si es un verdadero uno a uno probablemente debería. Por lo tanto, en su ejemplo, si convierte UserID en la clave principal en la tabla UserProfiles, su uno-a-uno funcionará.

+12

Tengo este problema tratando de configurar una relación 0..1 a 1 entre una tabla principal y una tabla de extensión. La extensiontable como muchas otras relaciones, así que no quiero meterme con el PK de esa. ¿Alguna idea de cómo resolver este tipo de situación? – Andreas

+1

@junior: esa es una relación de clave externa y puede llegar allí seleccionando la relación, yendo a las propiedades y cambiando la configuración "Multiplicidad End1" y "Multiplicidad End2" (aunque no estoy seguro de si esto es VS 2010 solamente). Lo más probable es que establezca "Multiplicidad End2" en "0..1". –

+0

No hay * "debería" *, incluso si EF no puede manejar correctamente las multiplicidades RA normales y, por lo tanto, obliga a cambiar un diseño RA perfectamente bueno. Esto * no * implica * que el modelo deba cambiarse, el caso actual a un lado - significa que EF, y aún parece estar roto hoy, debe * arreglarse * para modelar correctamente el dominio de la base de datos RA. – user2864740

10

Tengo un problema similar, pero con un escenario de venta y almacenamiento.

Un layby puede existir sin una venta, y una venta puede existir sin un layby. Esto significa que tengo una relación 0 o 1 a 0 o 1.

Layby hace referencia a la venta, pero layby no puede usar la clave principal de Venta, y Sale no puede usar la clave principal de Layby.

He resuelto el problema mediante el uso de una relación 0 o 1 a muchos, configura el getter 'Laybys' y colocador sobre la venta como privada, y luego siempre mi propio captador 'Layby' y colocador en mi POCO .

+3

Tengo curiosidad, ¿alguna vez has encontrado una mejor manera de capturar este tipo de relación? – Hannele

Cuestiones relacionadas