Discussion :

[dogua]

Bonjour à tous,

Entity Framework est assez nouveau pour moi, et j'ai du mal à comprendre certains concepts.

Donc en faite voila, j'ai éffectuer mon analyse, et produis un diagramme de classe. J'ai maintenant une librairie de classe qui me sert de model pour mon application.

Mais voilà, comment générer mon model Entity Framework depuis mes classes c# ?

Merci,

[dogua]

Bon ben j'ai trouvé une idée qui me semble satisfaisante...
D'un côté j'aurais mon entity model, de l'autre côté mes classes métier et entre les deux je vais implémenter un pattern DAO...

Qu'en pensez-vous?

[anthyme]

Pas super comme idée, l’intérêt d'entity framework c'est justement de mapper ton model sur la base pas de multiplier les models.

si tu as déjà fait tes classes c'est que tu as une approche "code first" cette approche est possible avec Entity Framework 4.1 qui gère le code first, il devrait t'aider à mapper tes objets sur une base de données.

[EMC51]

Quelle version de Visual Studio utilises-tu ?

En 2010, tu peux créer ton modèle (edmx) et générer ensuite la base de données associée.

Tu auras ainsi créé la couche d'accès aux données.

[dogua]

Quelle version de Visual Studio utilises-tu ?

En 2010, tu peux créer ton modèle (edmx) et générer ensuite la base de données associée.

Tu auras ainsi créé la couche d'accès aux données.

J'utilise bien VS2010...
Mais si j'utilise les classe générée par EF, je perds toute la logique de mon diagramme de classe...

Je comptais donc implementer un pattern DAO entre les deux

[EMC51]

Justement tu aurais du faire le contraire.

Par exemple crée un modèle Entity avec une entité Bipede qui a comme propriété Id, Nom, Prénom (le bipède de base).

On nomme le Namespace BipedeSpace.

Ensuite, tu crée une classe partielle qui va venir enrichir ton entité par des méthodes ou autres, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
namespace BipedeSpace
{
    public partial class Bipede
    {
        bool BienSaisi()
        {
            return (this.Nom != "") && (this.Prenom != "");
        }
    }
}

Par contre, je n'ai pas encore vu que l'on puisse transformer un classDiagram en EntityModel, à moins de réussir à créer une BD SQL par du reverse et de créer ensuite le modèle depuis la BD...

Tu as beaucoup d'entités dans ton modèle ?

[iberserk]

Quelle version de Visual Studio utilises-tu ?

En 2010, tu peux créer ton modèle (edmx) et générer ensuite la base de données associée.

Tu auras ainsi créé la couche d'accès aux données.

C'est une très mauvaise pratique qui a amené bien des projets basé sur des ORM dans le mur...

Modélisez votre base dans les règles de l'art (primary key , foreign key, contraintes not null et d'unicité etc.)
Et vous verrez que votre modèle edmx généré à partir sera nickel...

[EMC51]

C'est vrai que je commence aussi pas créer une BD correcte, mais rien n'empêche de commencer le modele EDMX et d'apporter les modifications nécessaire à la base générée.

[anthyme]

C'est une très mauvaise pratique qui a amené bien des projets basé sur des ORM dans le mur...

Modélisez votre base dans les règles de l'art (primary key , foreign key, contraintes not null et d'unicité etc.)
Et vous verrez que votre modèle edmx généré à partir sera nickel...

Ca a amenée bien des projet dans le mur alors que la techno a 1 an ?

La génération de modèle physique par EF4 est très correct et peu bien sûr être optimisé dans certain cas comme pour l'héritage.

[iberserk]

Ca a amenée bien des projet dans le mur alors que la techno a 1 an ?

LINQ TO ENTITES un an???? la V2 peut-être...

Et je parlais des ORM en général pas seulement LINQ TO ENTITIES.

[anthyme]

EF ne génère la base de données que depuis la v4 soit il y a 1 an.

Ensuite EF est un outil d’accès a la base qui permet de faire des choses tres propres et performante.

J'ai vu beaucoup de personne dire que les applications EF sont lente et que ca serait beaucoup plus rapide en Procstoc.

Et je vois ces personne faire uniquement des procstoc de select* qui sont post filtré dans l'application ou encore des getbyid fait une 20ene de fois pour récupérer tout un graph d'objet

[iberserk]

J'ai vu beaucoup de personne dire que les applications EF sont lente et que ca serait beaucoup plus rapide en Procstoc.

Et je vois ces personne faire uniquement des procstoc de select* qui sont post filtré dans l'application ou encore des getbyid fait une 20ene de fois pour récupérer tout un graph d'objet

J'utilise personnelement tous les jours LTE puisque je suis responsable du développement BDD et de l'intégration des couches basses sur des applicatifs .NET: j'abonde dans votre sens quant aux mauvaises pratiques des développeurs LAMBDA sur l'accès aux données c'est une catastrophes, ils ne percoivent la base de données que comme un simple moyen de stockage de leurs données...

LINQ TO ENTITES, ORM déjà très avancé leur permet de s'éloigner encore d'avantage des problématiques SQL.

Et vive le lazyloading dans des foreach avec à la clé un nombre exponentielle de requète pour afficher une grile :-)


En fait les problèmes de performances liées à LTE sont surtout dûes au UPDATE/INSERT/DELETE qui ne sont pas fait de manière ensembliste...

[anthyme]

Je suis ok pour ce coté là, clairement EF n'est pas fait pour les bulk insert et c'est assez dommage car ce n'est pas si dur à implémenter.

Dans ces cas la le mieux est de le faire en sql.