juin
2007
Un article de Matthieu MEZIL
Imaginons une base SQL Server avec deux tables : une table Worker et une table Company.
Quand vous ajoutez un fichier de type LINQ to SQL File à votre projet et que vous rajoutez dedans les deux tables, vous avez une classe qui hérite de System.Data.Linq.DataContext ainsi qu’une classe Worker et une classe Company.
Votre classe qui hérite de System.Data.Linq.DataContext a deux propriétés : Workers et Companies. Comme vous pouvez le remarquer, ces noms sont au pluriel. Pour info, ces propriétés sont de type System.Data.Linq.Table<Worker> (resp System.Data.Linq.Table<Company>).
Quand vous ajoutez un fichier de type ADO .NET Entity Data Model, à votre projet et que vous y associez les deux tables, vous avez une classe qui hérite de System.Data.Objects.ObjectContext ainsi qu’une classe Worker et une classe Company qui héritent toutes les deux de System.Data.Objects.DataClasses.Entity.
Votre classe qui hérite de System.Data.Objects.ObjectContext a deux propriétés : Worker et Company. Les noms sont ici au singulier. Pour info, ces propriétés sont de type System.Data.Objects.ObjectQuery<Worker> (resp System.Data.Objects.ObjectQuery<Company>).
Je vous l’accorde on s’en fout un peu de savoir si le nom est au signulier ou au pluriel mais bon si vous voulez remplacer votre LINQ to SQL pour travailler en LINQ to Entities, il vous faudra changer plus que votre Context.
Dans un post précédent, j’avais référencé un lien expliquant quand utiliser LINQ to Entities (ou ADO.NET Entity Framework) par rapport à LINQ to SQL.