Introduction par l'exemple à Entity Framework 5 Code First

Bonjour,

J'ai mis en ligne "Introduction par l'exemple à Entity Framework 5 Code First". C'est un tutoriel destiné en priorité aux débutants même s'il peut intéresser d'autres publics.

Citation:

---

- Création d'une base SQL Server 2012 à partir d'entités EF5 ;
- Ajout, Modification, Suppression d'entités ;
- Requêtage du contexte de persistance avec LINQ to Entities ;
- Gestion des entités détachées ;
- Lazy et Eager loading ;
- Concurrence d'accès aux entités ;
- Synchronisation du contexte EF5 avec la base de données ;
- Etude d'une application ASP.NET avec une architecture multi-couche ayant EF5 comme ORM et SQL Server 2012 comme SGBD ;
- Portage de l'application ASP.NET sur le SGBD MySQL 5.5.28 ;
- Portage de l'application ASP.NET sur le SGBD Oracle Database Express Edition 11g Release 2 ;
- Portage de l'application ASP.NET sur le SGBD PostgreSQL 9.2.1 ;
- Portage de l'application ASP.NET sur le SGBD Firebird 2.1.

L'application ASP.NET étudiée ci-dessus est celle utilisée dans le document [http://tahe.developpez.com/dotnet/pam-aspnet] où l'ORM était NHibernate et le SGBD MySQL 5. L'ORM est ici remplacé par EF5 et cinq SGBD sont testés.

Outils utilisés :

- Visual Studio Express 2012 pour le bureau ;
- Visual Studio Express 2012 pour le web ;

---

Vous pouvez sur ce forum, laisser des commentaires, signaler des erreurs, des difficultés, échanger des idées.

Simplement Merci :ccool:

Bonjour Serge,

A première vue ton introduction me paraît très sympa, beau boulot. ;)

Par contre j'ai 1 petite question et 1 commentaire :P :

Citation:

---

Si les champs proposés sont naturels, les mots clés virtual ne le sont pas. C'est une contrainte imposée à la fois par NHibernate et
EF5 : les champs des entités doivent être des propriétés publiques virtuelles.

---

Dans la création d'une entité (page 26), tu indiques que les entités doivent être "virtual"... Utilisant déjà 'EF5 Code First', je n'ai jamais déclaré mes propriétés de cette manière. (Bien qu'ayant déjà vu cela sur des forums anglais). Ma question, quel est l'intérêt de les déclarer "virtual"?

------------------

Page 33, tu souhaites donc initialiser tes noms de table en surchargeant la méthode "OnModelCreating"... C'est assez dommage de procéder de cette manière vu qu'on peut définir le nom de la table et le schéma au niveau de notre entité également.

En utilisant l'attribut Table qui vient de System.ComponentModel.DataAnnotations.Schema.

Code:

---

1 2 3 4 5

[Table("MEDECINS", Schema = "dbo")] public class Medecin { // ... }

---

Bonne journée. ;)

@Sobaka

Citation:

---

Dans la création d'une entité (page 26), tu indiques que les entités doivent être "virtual"... Utilisant déjà 'EF5 Code First', je n'ai jamais déclaré mes propriétés de cette manière. (Bien qu'ayant déjà vu cela sur des forums anglais). Ma question, quel est l'intérêt de les déclarer "virtual"?

---

Bah... Je croyais que c'était obligatoire. Tu me démontres que non. Au temps pour moi. Pour NHibernate, c'est obligatoire car les méthodes sont redéfinies par NHibernate. J'ai peut-être extrapolé un peu vite pour EF5 ?

Citation:

---

Page 33, tu souhaites donc initialiser tes noms de table en surchargeant la méthode "OnModelCreating"... C'est assez dommage de procéder de cette manière vu qu'on peut définir le nom de la table et le schéma au niveau de notre entité également.

---

Code:

---

1 2 3 4 5

[Table("MEDECINS", Schema = "dbo")] public class Medecin { // ... }

---

Merci pour l'information. Je savais qu'on pouvait déclarer la table ainsi mais je ne le savais pas pour le schéma.

Citation:

---

Envoyé par Serge Tahé

Bah... Je croyais que c'était obligatoire. Tu me démontres que non. Au temps pour moi. Pour NHibernate, c'est obligatoire car les méthodes sont redéfinies par NHibernate. J'ai peut-être extrapolé un peu vite pour EF5 ?

---

Apparemment oui :p EF5 ne redéfinit aucunes méthodes des entités. En tout cas encore une fois très bon boulot la dessus, j'ai parcouru en vitesse et je pense que c'est à la portée de tous donc pour ceux qui n'ont pas encore lu, dépechez vous. ;)

Le mot clé virtual n'est a utilisé uniquement pour les associations, pour le reste pas besoin, sinon vous risquez d'avoir des soucis au chargement des données (genre la collection toujours à Null).

Code:

---

1 2 3 4 5 6 7 8 9 10

public class MaTable {   public String MonTitre {get; set;}   public virtual MonAutreTable MonAssociation {get; set;}   public virtual ICollection<MonAutreTable> MaCollection {get; set;}   }

---

Citation:

---

Envoyé par acesyde

Le mot clé virtual n'est a utilisé uniquement pour les associations, pour le reste pas besoins, sinon vous risquez avoir des soucis au chargement des données (genre la collection toujours à Null).

Code:

---

1 2 3 4 5 6 7 8 9 10

public class MaTable {   public String MonTitre {get; set;}   public virtual MonAutreTable MonAssociation {get; set;}   public virtual ICollection<MonAutreTable> MaCollection {get; set;}   }

---

---

Je ne vois toujours pas ce que ça apporte... une collection ne doit pas être égale à "null" je suis d'accord mais je ne pense pas que le mot clé "virtual" apporte grand chose ici. De plus, tu peux avoir aussi des association qui peuvent être "null".

Exemple de ce que je trouve plus propre et une association qui peut être "null":

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public class MaTable { public int ID { get; set; } public string Name { get; set; } public int? RelationID { get; set; }   public MonAutreTable Relation { get; set; } public ICollection<EncoreAutreTable> Values { get; set; }   public MaTable() { if(Values == null) Values = new HashSet<EncoreAutreTable>(); } }

---

Pas de virtual... et pleinement fonctionnel ;)

Je suis d'accord avec toi pour le constructeur avec l'initialisation.

Par contre j'ai trouvé pas mal de questions d'utilisateurs sur le web du "pourquoi ma collection est toujours vide".

La réponse est toujours "rajoute le virtual devant" et l'utilisateur à réussit à retrouver ses infos.

Pourquoi ?
Ca je ne sais pas :mouarf:

Citation:

---

Envoyé par SoBaKa

Je ne vois toujours pas ce que ça apporte... une collection ne doit pas être égale à "null" je suis d'accord mais je ne pense pas que le mot clé "virtual" apporte grand chose ici. De plus, tu peux avoir aussi des association qui peuvent être "null".

---

À vous lire on dirait que vous n'êtes pas au courant de l'utilité du mot clef virtual sur les propriétés de navigation. :aie:

Donc pour infos le mot clef virtual lorsqu'il est défini sur les propriétés de navigation permet de bénéficier de la fonctionnalité de chargement à la demande (lazy loading) dans l'approche Code First (bien sûr si le développeur ne l'a pas désactivé explicitement dans le code) :ccool:

Citation:

---

Envoyé par acesyde

Je suis d'accord avec toi pour le constructeur avec l'initialisation.

Par contre j'ai trouvé pas mal de questions d'utilisateurs sur le web du "pourquoi ma collection est toujours vide".

La réponse est toujours "rajoute le virtual devant" et l'utilisateur à réussit à retrouver ses infos.

Pourquoi ?
Ca je ne sais pas :mouarf:

---

Ok donc je viens de trouver pourquoi ;)

Donc je pense que Serge a en partie raison sur le fait de "l'obligation" de mettre des propriétés en virtual et surtout les collections comme tu l'as dit.

Le fait de mettre le mot clef "virtual" sur les collections permet de profiter du Lazy Loading avec EF5 (et depuis EF 4.1 si j'ai bien vu ^^) donc dans ce cas la EF va bien redéfinir les propriétés en virtual.

Pour informations :
Dans la partie "Turning off lazy loading for specific navigation properties"

Et le pourquoi du comment: lorsque tu fais du LazyLoading ou que tu utilises du TrackingChanges, EF (et NHibernate) utilises des proxy (des classes dérivées du type original) pour redéfinir lesdites propriétés :)

Ah ui, c'était marqué dans ton lien :aie:

Merci pour cette presentation

Merci pour cette présentation, elle m'a été très utile.

Par contre je rencontre un souci avec Oracle et code first.

Peut-être pouvez vous me renseigner.

Je suis sur une application MVC 3 avec Oracle.
Dans votre tutoriel vous parlez de changer le providerfactory à la page 137.

Mais en MVC 3 je n'ai pas la possibilité de le modifier du coup j'ai une erreur dès que j'essaie de lire ou modifier des données dans mon contexte qui me dit :

Code:

---

Une valeur Null a été retournée après l'appel de la méthode « get_ProviderFactory » sur une instance de fournisseur de magasins de type « Oracle.DataAccess.Client.OracleConnection ». Le fournisseur de magasins risque de ne pas fonctionner correctement.

---

Savez-vous comment configurer code first et oracle avec MVC ?

Merci

@durnambule

Je ne connais pas ASP.NET MVC mais lorsque je génère un tel projet, je vois qu'il y a un [Web.config]. Donc vous pouvez mettre votre configuration EF dedans puis l'exploiter, comme il est fait dans le document avec une appli asp.net webforms. Non ? Je ne suis pas sûr de comprendre le problème.

ST

Très beau travail, bravo.

Si je peux me permettre une critique, je trouve que la différence entre code first et database first aurait mérité plus d'explications. Tel quel, l'article peut laisser croire qu'il s'agit d'un détail technique et que de toute façon la référence est le modèle de données :

Citation:

---

Les entités doivent refléter les tables de la base de données. (p.25)

---

Or ce n'est clairement pas le but de l'approche code first (que si j'ai bien compris vous avez été obligé d'utiliser pour des raisons de compatibilité ?) où on va typiquement d'abord construire son modèle objet en essayant de le garder le plus "pur" et le plus dénué possible de toute logique de persistance.

@Luckyluke34

Je suis d'accord avec vous. Je pense qu'on pourrait dériver les entités de persistance du modèle pour montrer clairement la séparation.

Merci pour ce dactitiel.

Le Binding WPF Semble avoir changé. ( par rapport a EF 3.5 ) : j'ai une ereur qui me dit de binder avec des DbSet .
Pourrais je avoir des liens et des exemples de binding WPF et EF5.0.
Malgrés des recherches je ne trouve rien .

Encore meci Anthride

Citation:

---

Envoyé par anthride

Merci pour ce dactitiel.

Le Binding WPF Semble avoir changé. ( par rapport a EF 3.5 ) : j'ai une ereur qui me dit de binder avec des DbSet .
Pourrais je avoir des liens et des exemples de binding WPF et EF5.0.
Malgrés des recherches je ne trouve rien .

Encore meci Anthride

---

Je te suggère d'ouvrir un autre sujet sur ce forum, qu'on puisse analyser ton problème. :ccool:
Mais à première vue, non, rien n'a changé sur le binding en WPF !

Bonjour et bravo pour cet article.

Simplement une petite remarque de DBA: vous utilisez à tord le terme champ lors de la description de vos tables côté SGBD...
Or une table contient des colonnes...

@iberserk

Citation:

---

Simplement une petite remarque de DBA: vous utilisez à tord le terme champ lors de la description de vos tables côté SGBD...
Or une table contient des colonnes...

---

C'est noté. Merci. Je le savais et je ferai davantage attention aux termes la prochaine fois.

Cordialement.

C'est un bel article, sur un sujet définitivement intéressant ;)

Bravo !

Merci pour cet article qui est de 1 de bonne qualité et de 2 très intéressant.

Je rencontre un problème avec PostgreSQL. J'ai bien compris que le composant Npgsql ne peut pas créer le modèle dans la base de donnée à partir du code. Cependant est-il possible de créer une ddl avec ObjectContexte.CreateDatabaseScript. De mon côté, je n'ai pas réussi et je n'ai pas trouvé d'info sur le web.

Je vous remercie d'avance pour vos réponse.

Voir ici

http://www.developpez.net/forums/d12...t-spring-root/

Cordialement.

Bonjour,

Je remercie l'auteur du tutoriel. Je l'utilise pour apprendre l'utilisation d'Entity Framework.

Je recherchais un moyen de spécifier dans le code la contrainte d'unicité de la table RV.
Je n'ai pas trouvé comment faire.

Mais je suis tombé sur la possibilité de spécifier une clé primaire composé dans la classe "RdvMedecinsContext" dans la méthode "OnModelCreating". Personnellement, je trouve dommage de spécifier la clé composé dans le contexte plutôt que dans l'entité.

Au niveau conception, s'agit il d'une solution convenable ? (autrement dit, n'ai je pas fais une faute de conception)

Elle est spécifiée par le code suivant :

Code:

---

1 2	modelBuilder.Entity<Rv>().HasKey(r => new { r.Jour, r.ClientId });

---

Cependant, je ne vois pas comment manipuler cette clé composé. J'ai donc pensé à cette solution.
En modifiant l'entité Rv pour que l'id ne soit pas une clé primaire mais plutôt un hashcode défini
ci-dessous :

Code:

---

1 2 3 4 5 6 7

[NotMapped] public virtual int? Id { get { return this.jour.GetHashCode() + this.clientId.GetHashCode() ; } }

---

Il s'agit juste d'une solution théorique que je propose et dont j'aimerais avoir des critiques...

Pour ceux qui aiment l'approche Code First il existent des outils de Reverse Engineering à partir d'une base de données existantes.

Un grand merci pour ce super tuto sur EF ! Il m'est très utile pour mon apprentissage :)