Discussion :

[kunfuka]

Bonjour à tous,

Tout est dans le titre. Quelles sont les différences entre Hibernate et les DataSet ?

Merci

[Maniak]

Quand il y a des DataSets dans les parages, c'est généralement pour les retrouver passés directement de la base à l'interface via databinding. C'est facile, c'est sûr. C'est pas la peine de prétendre faire de la séparation de couches par contre. Sans parler de l'absence de typage, à moins de passer par des DataSets typés lourdingues.

Avec Hibernate, tu as des *objets* représentant *clairement* le domaine, tu n'as plus (trop) à te préoccuper des accès à la base et la gestion/navigation entre les objets en question est lumineusement simple.
Et tu es obligé de séparer ces objets de ce qui se retrouve dans l'interface (particulièrement en web, vu que HtmlEncode & co). Ça fait plus de code, ceux qui veulent des trucs qui se montent en 2 clics ne s'en approcheront jamais, mais ça fait du code bien plus propre que la bouillie infâme qu'ils pondent.

Bref, ça n'a rien à voir, c'est pas la même façon de faire, et la seule façon de vraiment voir les différences c'est d'essayer en vrai.

[neguib]

http://kpixel.developpez.com/NHibernateEg/Tutorial1A/

[kunfuka]

Merci messieurs, je vois maintenant la différence

[mkm]

Il ne faut pas oublier que Hibernate est une techno à part entière le mapping o/r très complet (connexion, transaction, chargement, concurrence…..)
Donc ça demande un apprentissage pour l’appréhender et la comprendre et surtout de mieux l’utiliser (performance, design….)
Derrière ses aspects simples (session.find(toto)) se cache un framework très évolué qui exige un style de programmation et de configuration pour avoir toute sa puissance (Ntiers, POJO, fichier de mapping…) donc il faut le comparer plutôt a ADO.NET d’une certaine manière, par ce que Dataset ce n’est qu’une fonctionnalité après tout.
Mais rien de bien méchant un peu de volonté et de courage (pour allez comprendre vraiment le fonctionnement ne vous arrêtez pas aux exemples simple et facile trouver sur le net) vous allez ne plus vous en séparer.
En tous cas je vous conseille un livre qui m'a beaucoup aidé :
Hibernate
http://www.amazon.fr/exec/obidos/ASIN/2744019399/qid=1137238088/sr=10-/ref=sr_10_9_/402-4644532-3270569
C’est la traduction du fameux « Hibernate in Action » la référence en la matière ça tombe bien par ce que ce livre destiné a la version 2.1 celle qui est porté en .NET Nhibernate 1.0.
NB : Ce livre est destiné à la plate forme JAVA (exemple de code en JAVA)

[Maniak]

Derrière ses aspects simple (session.find(toto)) se cache un framework très évolué qui exige un style de programmation

Juste de la POO et de la séparation de couches, pas du dév monolithique vers lequel le DataSet peut pousser.

et de configuration pour avoir toute sa puissance (Ntiers,POJO,fichier de mapping…)

POJO en .NET, ça risque d'être dur :)

Rien à ajouter sinon :)

[mkm]

Derrière ses aspects simple (session.find(toto)) se cache un framework très évolué qui exige un style de programmation

Juste de la POO et de la séparation de couches, pas du dév monolithique vers lequel le DataSet peut pousser.

et de configuration pour avoir toute sa puissance (Ntiers,POJO,fichier de mapping…)

POJO en .NET, ça risque d'être dur

Quand je dis POJO apparenté bien sur au monde JAVA je veux dire:
« Utiliser un modèle objet simple (facile à développer, centré sur l'applicatif plus que sur le technique) et sans dépendances avec telle API ou tel framework. » Comme ex DataSet
http://rr0.org/java/POJO.html
Enfaite c’est les objets du model métier (client, article…) qui sont transversal a toute l’app que Hibernante utilise (grâce a leur fichier de mapping) pour les mappé sur la base
Et c’est ce design qui a étais choisi par Hibernate 8)
En JAVA on appelle ca POJO en .NET ?

[Maniak]

Quand je dis POJO apparenté bien sur au monde JAVA :oops: je veux dire:
« Utiliser un modèle objet simple (facile à développer, centré sur l'applicatif plus que sur le technique) et sans dépendances avec telle API ou tel framework. » Comme ex DataSet

Mmh... J'ai du mal à faire rentrer le DataSet dans cette définition. À moins que tu prennes le DataSet comme l'exemple inverse de ta définition, auquel cas la suite de ce post tapera à côté :)

Enfaite c’est les objets du model métier (client, article…) qui sont transversal a toute l’app que Hibernante utilise (grâce a leur fichier de mapping) pour les mappé sur la base
Et c’est ce design qui a étais choisi par Hibernate 8)
En JAVA on appelle ca POJO en .NET ?

Ben en Java il avait fallu leur donner un nom par opposition aux Java Beans. En .NET, pas de Beans, donc pas besoin de nom :)
POJO en Java, ce sont des objets bêtes et méchants en .NET :)
*Mais*, des objets qui correspondent au domaine. Client, Facture, Commande, tout ça.

Un DataSet, c'est un gros conteneur générique (à l'ancienne, non-typé :), qui n'a pas de *sens* tout seul. Ce sont ses données qui ont un sens, et le code n'a pas moyen de le savoir si le développeur ne caste pas dans tous les sens. C'est aussi un gros conteneur qui est d'un côté directement mappé sur la base et de l'autre directement plaqué dans l'interface (si on parle des usages les plus basiques/courants de la chose). C'est pas vraiment sans dépendance :)

[mkm]

[quote]

Quand je dis POJO apparenté bien sur au monde JAVA je veux dire:
« Utiliser un modèle objet simple (facile à développer, centré sur l'applicatif plus que sur le technique) et sans dépendances avec telle API ou tel framework. » Comme ex DataSet

Mmh... J'ai du mal à faire rentrer le DataSet dans cette définition. À moins que tu prennes le DataSet comme l'exemple inverse de ta définition, auquel cas la suite de ce post tapera à côté

Exact je voulais parlais du DataSet typé en faite, mais en tous cas je ne suis pas spécialiste ni fan des dataset ils ont leur utilités certes mais bon
Pour POJO je ne cherche pas un nom pour .NET c’est juste pour donné un aperçue des quelque technique mise en avant par Hibernate avec un nom évocateur
En tous cas merci pour les explications