Discussion :

[obiflo]

Bonjour,

Dans plusieurs tutos on montre l'utilisation de EF et de Linq to SQL pour construire a partir d'une bdd nos classes métiers avec les relations vers la bdd.

Mais cela est il possible dans l'autre sens ?
Cad : Dans VS 2010 je crée un ClassDiagram (.cd), qui me génère mes classes. Est il possible de les rendre pressantes dans une Bdd qui seras crée via mon diagramme de classe ?

Merci bcp

[The_badger_man]

Il faut que tu crées un model EF en choisissant le template le deuxième template (pas celui dont tu parts de la base, l'autre, je ne sais plus son nom).

Depuis le model tu pourras générer le script SQL correspondant (clic droit sur le model).

[obiflo]

Salut

Dans "Add New Item" dans Data le 2ème étant ADO.NET Entity Data Model
Après il me demande de choisir entre : Generate from database et Empty model
Si je prend Empty model, il me crée un fichier .edmx et me propose de mettre des entity dedans...

Mais cela ne m'arrange pas pour le moment, car je voudrais que mes 2 classes déjà existante soient dans le model.

++

[cinemania]

Le problème ce que tes classes perso ne sont pas forcément fonctionnelles pour EF... en effet, les classes EF bien que plus propres que les classes générées par Linq To SQL, en sont pas moins décorées par des tas d'attributs nécessaire à EF pour fonctionner.

EF par l'emdx génère des classes partielles, et donc tes classes métiers déja codées tu peux les intégrer partiellement, tu peux conserver tout le code métier dans ces classes déjà écrites, et déployer dans l'EDMX uniquement les propriétés et les contraintes de liaison, suffit de virer les déclaration des propriétés dans tes classes, et d'indiquer que ta classe déjà écrite est partielle et le tour est joué.

Sinon si ce n'est pas ce que tu veux, tu en demande peut être un peu trop à cet éditeur, qui n'est pas conçût pour faire du reverse engineering.

EDIT :

En général quand on développe surtout avec des bases de données, on se pose la question de la modélisation de données avant le développement coté "code" ou justement EF permet de faire le mappage et la transition, si les deux modèles sont différents.
toi tu part du principe que tu as des classes pas forcément adaptées à la DB et que tu veux en extraire ton modèle physique de données... Personnellement je trouve que c'est une erreur conceptuelle plutôt grave, car les contraintes sont plus nombreuses coté DB que coté code, aussi il vaudrait mieux suivre un ordre plus logique.

Comme je l'ai dit, là tu fait du reverse engineering et ce n'a pas l'air d'être ce que souhaite réellement faire...
question donc, qu'est ce que cela te coute de faire une vraie analyse de ton problème et de faire un modèle conceptuel et physique des données, voir directement physique si tu n'a pas besoin d'un modèle conceptuel et logique ?
( à part un peu de temps, ce qui pourrait également te faire gagner pas mal de temps par la suite... une DB bien pensée est souvent plus importante que le projet lui même...)

[obiflo]

Ok, merci pour les informations...

Le but étant d'explorer au max les solutions reverse engineering.

Les remarques sur le sujets me dirige dans ma réflexion sur le sujet, merci

[cinemania]

tu peux créer ton class diagram dans SQL Server hein, enfin ca sera un MPD mais bon... ca ressemble à un class diagram lol...

il existe des outils d'uml suffisamment performant pour générer du code SQL depuis ton modèle uml, mais il n'est pas souhaitable d'écrire un modèle SQL depuis ton code... comme je l'ai déjà expliqué.
pas souhaitable signifie juste que c'est pas un choix particulièrement heureux, mais pas impossible, mais quand à savoir si VS et EF sont vraiment orienté dans ce sens, la réponse est clairement non, même s'il peut y avoir ici et là des bribes et quelques briques permettant d'aboutir.

VS est un outil de développement de code avant tout, il est donc assez logique finalement que son accès aux données soit plus consultatifs ou disons quelques tools même de création pour dépanner, que orienter clairement DB...
si tu veux vraiment partir de ton code vers une DB, le mieux serait d'envisager d'investir dans une DB Objet...