J'ai une exigence unique que j'espère possible avec LINQ to SQL. Tout d'abord, j'étends une application plus ancienne, donc je suis coincé avec les noms de colonnes de base de données actuels et les classes d'entités LINQ existantes.LINQ to SQL: Comment étendre une classe d'entités avec un alias de colonne
J'ai un emballage LINQ avec la méthode suivante:
public T Get(int id) where T : class, IEntity {
...
}
IEntity ressemble:
public interface IEntity {
int Id { get; }
}
Ma classe d'entité existante (générée par LINQ) ressemble à:
//this is not the exact code
//it is just to give you an idea
public parital class Widget {
public int WidgetId { get; set; }
public string WidgetName { get; set; }
}
Donc, afin de faire fonctionner Widget avec mon emballage, je l'ai étendu pour être un IEntity comme:
public partial class Widget : IEntity {
public int Id { get { return WidgetId; } }
}
Quand je fais une sélection comme:
Repository<Widget>.Get(123);
je reçois une erreur disant Id n'est pas mis en correspondance dans SQL. Ce que je veux savoir, c'est qu'il existe un moyen pour moi de faire de Widget un IEntity et d'utiliser Id comme un alias de WidgetId. Il y a déjà beaucoup de code plus ancien écrit (sans le wrapper de référentiel) qui fait référence à WidgetId donc je ne veux pas avoir à changer cela.
Toutes les suggestions sont appréciées. Est-ce que je vais à propos de ce problème?
J'ai récemment lu ici sur SO que la manière correcte de mettre à jour un modèle LINK to SQL à partir des changements de base de données est de supprimer tous les objets sur celui-ci et de copier à partir de la base de données. Cela détruirait ce changement, n'est-ce pas? LINQ to SQL correspond directement à la base de données, toujours, donc cela ne semble pas être un bon ajustement. –
Pour faire ce qu'il veut, c'est probablement le moyen le plus simple de le gérer. Oui, s'il change la base de données et doit rafraîchir le modèle, il devra recréer ses changements. Mais cela ne devrait pas arriver trop souvent et le changement est minime dans tous les cas, facile à refaire. –
Je pensais que ce serait la solution, mais je voulais voir s'il y avait une autre façon sans changer le modèle parce que le code plus ancien utilise déjà WidgetId. Je suppose que j'ai un peu de refactoring à faire. Merci. – modernzombie