Je me doute que la question à déjà du être traité, mais est-il possible d'affecter une entity à un schema en particulier ?
J'utilise EF6 en DBFirst.
Cordialement
Je me doute que la question à déjà du être traité, mais est-il possible d'affecter une entity à un schema en particulier ?
J'utilise EF6 en DBFirst.
Cordialement
Bonjour,
Qu'entendez vous par une entity? Voulez dire "ajouter une entité à un schéma"? Si telle est la question, la réponse est oui?
Cordialement.
La recherche de la connaissance est une Lumière qui apaise le Cœur.
Si une réponse vous a été utile , n'oubliez pas de voter en cliquant sur:.
Et comme faites vous pour définir le schéma de l'entité en DBFirst ?
Bon je ne sais pas quelle architecture vous utilisez. Si vous utilisez une architecture de type n-tier:
-Vous ajoutez un nouvel élément de type ADO Entity Data Model dans la DAL.
Si c'est un projet à couche unique vous ajoutez l'élément ADO Entity Data Model à votre projet.
Voici les étapes en images jointes dans l'ordre de progression.
Cordialement.
La recherche de la connaissance est une Lumière qui apaise le Cœur.
Si une réponse vous a été utile , n'oubliez pas de voter en cliquant sur:.
Je ne suis pas sûr que vous répondiez à sa question.
rvzip64 vous parlez de mapper des table dont le schéma est différent de dbo dans l'edmx?
Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
MCTS Database Development
MCTS Database Administration
Salut iberserk,
C'est exactement ce que je cherche à faire ! Vous avez une piste ?
Salut,
J'ai du mal a comprendre ton problème.
Car voici ce que j'ai essayé :
Et je n'ai aucun problème pour l'intégrer dans mon edmx :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 USE [TestSchema] GO CREATE SCHEMA [abc] GO CREATE TABLE [dbo].[Customers] ( CustomerId INTEGER NOT NULL PRIMARY KEY, Nom VARCHAR(50) NOT NULL, ) CREATE TABLE [abc].[Clients] ( ClientId INTEGER NOT NULL PRIMARY KEY, Nom VARCHAR(50) NOT NULL, )
Donc si tu pouvais nous donner un peu plus de précisions
Ma question se pose au niveau du Designer pas du code SQL...
J'avais bien compris mais ma démonstration servait d'exemple...
Mon image (de mon message précédent) est dans le designer Visual Studio et il m'a fallu 10 secondes pour ajouter une table qui n'est pas dans le schéma "dbo".
Mais je repose ma question :
Quel est ton problème ???
Le problème c'est que vous , vous importez votre base de données qui comporte déjà deux schémas.
Alors que moi je vous demande comment faire pour spécifier dans le designer un schéma spécifique pour une entité.
De plus, je pense que si vous générez votre script SQL a partir du designer vous aurez perdu l'appairage entité/Schéma ...
D'après ton premier message tu es en "DbFrist" : Ce qui veut dire que ta base de données est crées et que tu l'importe dans Visual studio. ==> Voila pourquoi j'importe ma Bdd.
Donc en DbFirst il n'y a pas a modifier le schéma dans Visual studio puisque cela est géré en SQL.
Par contre en "Code First" tu peux configurer tes schéma pour la génération de base ou pour te relier à des tables existante.
Dans ta classe Context :
Ou par attribut sur tes classes :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Entity<Customer>().ToTable("Customers"); modelBuilder.Entity<Client>().ToTable("Client", schemaName: "abc"); }
En faites je pense qu'on a du mal a se comprendre sur les mots.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 [Table("Clients", Schema = "abc")] public class Client { ... }
Mais on va y arriver
En faite je pense avoir compris !
Tu es en "Model First" : Tu crée ton schéma dans le designer pour pouvoir créer ta base ensuite...
C'est ça ?
Si c'est bien ça je n'ai pas de solution car dans le deisgner il n'y pas pas de propriété pour choisir sont schéma au niveau de l'entité mais bien du Model...
En mode arrache : Créer plusieurs "entity data Model" ou chacun aura un Schéma différents...
(mais tu perd tes relations avec EF il faudra faire des "join" a la main dans Linq)
lol oui on a du mal à ce comprendre
Je comprends complètement votre exemple, je vais faire un résumé d’après ce que vous m'avez expliqué et de ce que j'ai pu lire.
3 façons de faire avec EntityFrameWork
Db First
Si la base de données existe déjà, on fait un import dans l'EF pour construire la DAL. La gestion des schémas est évidente vu que c'est dans le serveur de base de données
Code First
Si la base de données n'existent pas, on code en C# puis on injecte le modèle dans SQLServer, et d'aprés votre dernier post, il est facile de faire la distinction entre les schémas
Design First
Si la base de données n'existent pas, on fait un design, puis on génére le SQL pour l'injecter dans le Serveur. C'est la méthode que j'ai choisi (c'est peut être une erreur) et je ne sais pas comment spécifier le schéma dans le designer, sachant que je veux pouvoir gérer plusieurs schémas
Mon problème se pose avec le design First.
Exactement !En faite je pense avoir compris !
Tu es en "Model First" : Tu crée ton schéma dans le designer pour pouvoir créer ta base ensuite...
C'est ça ?
Si c'est bien ça je n'ai pas de solution...
katkiller, vous utilisez habituellement qu'elle méthode pour faire votre DAL et modéliser votre DB ?
DbFirst ? CodeFirst ?
Qu'est ce qui a justifié votre choix ?
Un peu embêtant en effet ...(mais tu perd tes relations avec EF il faudra faire des "join" a la main dans Linq)
Quand j'ai commencé mon apprentissage d'EF, je voulais absolument faire du "ModelFirst" (DesignFirst). Mais j'ai rencontré beaucoup de problèmes avec la génération de la Bdd. En gros je n'ai presque jamais réussi a mettre ma base de données a jour sans la supprimer...
Aujourd'hui je suis 100% "Code First" (base existante ou non) :
Je garde la maîtrise de mes classes, de mon context (mapping entre mes entités et ma Bdd).
Cela me permet d'avoir une classe qui représente mon métier plutôt que ma Bdd.
Pour la mise à jour de ma base : Code First Migration.
Avec cette méthode il y aussi l'avantage de pouvoir remettre à jour ta bdd à un point initial --> méthode "Seed" dans le lien ci-dessus.
J'utilise aussi les BoundedContext qui me permettent de cloisonner mes entités selon mon besoin. Cette technique m'évite d'avoir 200 entités dans mon modèle alors que dans mon context métier(besoin) j'ai besoin que de 5 entités.
L'avantage de "DbFirst" c'est que tu contrôle totalement ton SQL. Et grâce à l'import cela te permet de mettre en place un Schéma (modèle d'entités) rapidement. Mais je pense que dans ce type d'approche il faut vraiment gérer la base coté SQL et juste mettre à jour ton modèle coté Visual studio.
Mes explications sont totalement personnelle et mériteraient certainement d'être davantage développées.
Si j'ai un peu de temps j’essaierai de faire quelque chose de mieux... En attendant si tu as des questions n'hésite pas !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager