Uso de varias claves externas a la misma mesa en LINQ

Question

Tengo una tabla usuarios y una tabla de artículos

En la tabla de artículos, que tienen campos como

ModifiedBy CreatedBy AssignedTo

cuales todos tienen un entero userId. La base de datos está configurada para tener estas claves como extranjeras en la tabla Usuarios.

Al utilizar LinqToSql, las relaciones que se construyen de forma automática desde el dbml acaban dándome nombres como usuario, Usuario1 y Usuario2

por ejemplo, myItem.User1.Name o myItem.User2.Name

Obviamente, esto no es muy fácil de leer y me gustaría que sea a lo largo de las líneas de

myItem.CreatedByUser.Name o myItem.ModifiedByUser.Name etc

Podría cambiar los nombres de las relaciones, pero eso significa que tengo que volver a hacer eso cada vez que cambie el esquema db y actualice el dbml.

¿Hay alguna forma de evitar esto?

Answer 1

La respuesta simple: No.

Alguien ha sugerido la idea de crear clases parciales Asociación donde los nombres de obtención de propiedad definidos, pero eso no va a funcionar bien: Renaming LINQ 2 SQL Entity Properties Through Partial Classes.

Su elección consiste en dedicar un poco de tiempo a aprender más acerca de "detrás de escena" de LINQ-to-SQL para que pueda hacer las modificaciones necesarias manualmente o simplemente cambiar los nombres de propiedad a través de la ventana Propiedades. Personalmente, simplemente elimino/redrag/renombre, porque no establecer una propiedad correctamente es difícil de depurar porque las excepciones que se lanzan le dan poca o ninguna pista sobre qué lo causó. Incluso llegué a crear una biblioteca de pruebas unitarias que toma cada objeto MetaTable en el modelo y verifica el recuento de campos, los contenidos de ServerDataType de cada campo, el recuento de asociaciones, los nombres de cada asociación y los nombres de cada extremo de la Asociación. Cada pocos cambios, ejecuto las pruebas de la unidad para asegurarme de que el modelo esté intacto.

Answer 2

En primer lugar, no ... los nombres se crean en función de la segunda tabla de la relación.

Pero lo que debes saber es que no tienes que "actualizar" (es decir, eliminar la tabla en DBML luego volver a arrastrarla y soltarla).

Para el proyecto en el que estoy trabajando, tenemos más de 200 tablas ... aproximadamente 50 de las cuales hemos modificado manualmente después de arrastrarlas desde la base de datos. Nos nunca eliminar y volver a arrastrar las tablas ya que ha habido tantos cambios post-auto-generación.

Answer 3

Puede usar linq para sql sin dbml puede ser un trabajo adicional por adelantado, pero desde la perspectiva de un cambio en el nombre de una columna de tabla puede ser más fácil que los cambios en el dbml como usted ha descrito.

Answer 4

Sugiero crear métodos de extensión asignando los nombres que desea a los nombres que obtiene del código autogenerado. De esta forma, después de cada autogeneración, no tiene que cambiar el código autogenerado, sino solo sus propios métodos de extensión. Eso, más las pruebas unitarias para hacer verificaciones de cordura, como se sugiere en otra parte de esta página, debería funcionar bien.

Acabo de enfrentarme a este problema y me voy a tratar de implementar mi propia sugerencia.

EDIT: Esto parece relevante: SQLMetal Multiple Foreign Keys Pointing to One Table Issue

Answer 5

acabo de añadir una pequeña clase parcial para extender el objeto con propiedades nombre adecuado, ejemplo siguiente:

namespace Database.TableModels { 
    partial class WTSR_Induction { 
     public EmailTemplate ConfirmationEmailTemplate { 
      get { return EmailTemplate1; } 
     } 
     public EmailTemplate InviteEmailTemplate { 
      get { return EmailTemplate; } 
     } 
    } 
} 

En este ejemplo, la tabla WTSR_Inductions tiene dos enlaces a la tabla EmailTemplates, de ahí las propiedades EmailTemplate y EmailTemplate1.

Answer 6

Un poco tarde pero puede hacerlo seleccionando la relación en el modelo de linq y vaya a las propiedades y actualice el nombre de la propiedad principal.