L'utilisation d'une classe Entity simple pour mapper vers une table à l'aide de LINQ to SQL?

Question

Supposons que j'ai écrit un client de classe qui a des attributs comme le nom, l'âge, la désignation, etc. Et j'ai aussi une table avec le client avec les mêmes attributs.

Maintenant, je ne veux pas utiliser le concepteur à condition de générer les classes d'entités pour moi.

Est-il possible pour moi de mapper le Customer.cs au client de table tout en utilisant LINQ to SQL comme OR/M.

Answer 1

Vous allez avoir du mal à faire cela parce que votre classe n'aura pas toute la plomberie interne une classe L2S doit gérer les relations FK, les modifications, les pièces jointes à une source de données, etc.

OTOH, nous avons fait une chose similaire. Dans notre application L2S, nous avons ce que nous appelons des "entités d'application" qui sont nos propres entités (et beaucoup plus légères), et nous avons les entités générées par L2S (avec toute la plomberie interne L2S). Dans notre back-end, les entités d'application sont mappées à une entité L2S correspondante pour la manipulation des données. Fonctionne très bien pour nous.

Randy

Answer 2

Oui, c'est effectivement. Vous pouvez fournir un fichier de mappage lorsque vous instantiante un DataContext comme ceci:

var dataContext = new DataContext("connectionstring", entity.map); 

Ce fichier peut être généré automatiquement avec SqlMetal.exe:

sqlmetal /server:servername /database:databasename /context:nameofdatacontext /Map:Entity.Map /code:Entity.code 

Donc, si vous vous en tenez à la convention pour nommer les propriétés les même dans db et je enties, vous serez en cours d'exécution.

En outre, vous pouvez utiliser des modèles T4 pour générer votre datacontext, en générant également le fichier dbml.

J'ai créé un fichier .bat, que j'exercerai de l'explorateur de solution avec powershell.exe, que

• fonctionne SqlMetal.exe avec le paramètre carte
• fonctionne SqlMetal.exe avec dbml paramètre
• et exécute TextTransform.exe sur mon modèle T4 qui génère mon datacontex.

Mais vous devriez probablement utiliser EntitySet<T> et EntityRef<T> dans votre entité si vous ne voulez pas la fonctionnalité normale manque comme lazyload. Cela signifie évidemment que vous n'aurez pas de POCO propres, mais si vous pouvez vivre avec cela, c'est un compromis assez petit.