Discussion :

[flo62]

Bonjour à tous,

Je vais me lancer dans la création d'une application Web ASP.NET.
Comme dans la plupart des projets, je dois concevoir une base de données.
Ma base de données comporte une dizaine de tables.

Cependant, j'ai cherché les ORM à utiliser en .NET et je suis donc tombé sur plusieurs technologies : Linq to SQL, Linq to Entities, Entity Framework, ADO.NET.

J'aimerais bien savoir les différences entres toutes ces technologies. J'ai commencé à faire des exemples avec Linq to SQL et Linq to Entities, je ne vois pas de grande différence...
Après je me suis aperçu de l'existence de l'Entity Framework, qu'apporte-il concrètement ?
Concernant ADO.NET, j'ai l'impression que c'est un peu come JDBC en Java.

Venant plus du monde Java, j'aimerais savoir si il est possible de générer des sessions beans et entities bean comme en Java ?

Ça serait sympa si des personnes pouvaient m'éclairer en quelques lignes.

Merci d'avance pour votre aide

Flo62

[meziantou]

http://www.developpez.net/forums/d10.../conseils-dal/

[iberserk]

Linq to Entities, Entity Framework

Idem...

Partez sur du Entities... LINQ TO SQL est dépassé, sorte de 'coup d'essais' avant LTE...

Votre base est déjà modélisée?
Mieu elle le sera, plus facile et efficace sera votre MAPPING côté code client.

[Bluedeep]

Idem...

LINQ TO SQL est dépassé,.

Il n'est pas seulement dépassé, il est (et a toujours été) surtout inutilisable : en effet, il crée des entités pour les tables de liaisons [M,N] ce qui aboutit à un modèle objet exposé absurde.

[flo62]

Merci pour vos réponses

Effectivement, je me suis penché sur Entity Framework et Linq to Entities. Je trouve ça vraiment pas mal. J'arrive assez facilement à faire toutes les opérations de CRUD.

Cependant j'ai une question : Dans la plupart des exemples sur le net, les requêtes ont lieu dans le code behind. Est-ce vraiment une bonne pratique ?
Ne faudrait-il pas créer une couche purement métier ?

Si quelqu'un pourrait m'éclairer sur la structuration d'un projet Web avec Entity Framework.

Encore merci de votre aide

[iberserk]

il crée des entités pour les tables de liaisons [M,N] ce qui aboutit à un modèle objet exposé absurde

+1

[Nathanael Marchand]

Merci pour vos réponses

Effectivement, je me suis penché sur Entity Framework et Linq to Entities. Je trouve ça vraiment pas mal. J'arrive assez facilement à faire toutes les opérations de CRUD.

Cependant j'ai une question : Dans la plupart des exemples sur le net, les requêtes ont lieu dans le code behind. Est-ce vraiment une bonne pratique ?
Ne faudrait-il pas créer une couche purement métier ?

Si quelqu'un pourrait m'éclairer sur la structuration d'un projet Web avec Entity Framework.

Encore merci de votre aide

Dans l'idéal il faudrait en effet créer une couche d'accès aux données et une couche métier.

[calagan99]

Désolé, squattage de topic

Je suis en train de loucher sur EntityFramework.
Je pense l'utiliser pour un projet perso nécessitant une bdd contenant 5 à 10 tables, pas vraiment de contraintes en terme de performances et un stockage de données a priori peu lourd.
EntityFramework me semble adapté mais j'avoue ne pas vraiment savoir par où commencer.

Avec les quelques informations que je donne, EF vous semble-t-il approprié ?
Si oui (et même si non à vrai dire), pouvez-vous me conseiller un "tutoriel" en ligne qui décrive son utilisation par la pratique ?

D'avance merci

[B.AF]

Bonjour à tous,
Venant plus du monde Java, j'aimerais savoir si il est possible de générer des sessions beans et entities bean comme en Java ?

Ça serait sympa si des personnes pouvaient m'éclairer en quelques lignes.

Merci d'avance pour votre aide

Flo62

Le plus proche restera bien sur NHibernate. Il n'existe pas de spécification comme JPA en .Net. En revanche, l'équivalent est WCF qui va avoir deux grands principes :
- L'operation contract qui est l'équivalent du session bean
- le data contract qui est l'équivalent de l'entities bean

Dans tous les cas, il n'existe pas d'encaspulation ou d'injection native en WCF.
- WCF ne spécifie pas l'appel d'un service par un service
- L'instanciation des singletons
- La mise à disposition de l'entity manager
Tout ça est à gérer à la mano..
Un data contract signifie juste que l'objet est serialisable et transportable. L'operation contract ne jouera aucun rôle dans sa persistence.

Concernant la session, par défaut WCF est stateless, en revanche, il est beaucoup plus ouvert qu'ejb et permet de nombreux mode de gestion de session.
Le mode par défaut (sans session) est le plus proche du stateless EJB. Chaque appel crée une instance du service.
Il existe aussi des modes ou une session est requise, avec des modes qui permet d'initier un dialogue, similaire à l'ejb statefull, là encore avec moins d'encapsulation et plus de paramètrage à faire.
Enfin le singleton existe soit en service (instance unique partagée), soit directement dans le framework (static).

La logique est relativement similaire, puisque les attributs [attributs] en .Net sont équivalents aux annotations @annot en Java.

Globalement, le framework est plus riche qu'ejb3, mais moins mature et avec des usages moins normés.

Quoi qu'en dise les "experts" avec des exemples à 3 tables, le choix d'un ORM est structurant en .Net du fait justement de l'absence d'une spécification commune. Attention aussi à la sérialisation qui peut être un sujet complexe.
La serialisation native est ...lente, peu souple. Il y a des alternatives, mais là encore, il faut faire de la plomberie.