Discussion :

[Targan]

Bonsoir,

je débute en .NET et notamment sur la séparation de couche DAO, métiers, présentation.

J'ai une appli à faire en winform, et je me demandais si il était mieux de mapper la base de données avec iBatis ou avec NHibernate.

Qu'en pensez vous ?

Avez vous de bons liens (tuto ?) sur le principe de fonctionnement ?

Merci.

[cinemania]

Si tu es sous Visual Studio 2010 et que ton projet est en dotnet 4, alors il est possible d'utiliser ADO.NET Entity Framework 4, et le pattern T4 (extension .NET POCO ENTITY GENERATOR).

Sinon si tu veux vraiment un framework tiers alors NHibernate est ta seule alternative viable. En effet, la solution iBatis est arrivé en fin de vie et n'est plus développée, maintenue, il vaut donc mieux l'oublier.

Techniquement les afisionados de NHibernate te dirons de prendre NHibernate, et les apôtres de Entity Framework, comme moi, t'encourageront à utiliser EF car il fait partie intégrante de Dotnet 3.5/4.0 alors qu'NHibernate est un framework tiers.

Quoi qu'il en soit, le résultat est assez proche. Bon ya des différences, comme le fait que les classes générées par EF4 et T4 possèdes une batteries de propriétés dont tu n'a peut être rien à faire, mais qui sont très importantes pour l'utilisation avec WPF.

[meziantou]

J'utilise moi aussi EF4 car la puissance des T4 permet de générer tout le code voulu (entités, context, WCF, ...)

[Nathanael Marchand]

Pour l'utiliser intensément au boulot sur un gros projet, nhibernate est pas mal mais très mal documenté! hibernate est plutot assez documenté mais il manque toutes les spécificités pour .Net dans la doc nhibernate.
La doc msdn à coté c'est une rolls

[B.AF]

Pour l'utiliser intensément au boulot sur un gros projet, nhibernate est pas mal mais très mal documenté! hibernate est plutot assez documenté mais il manque toutes les spécificités pour .Net dans la doc nhibernate.
La doc msdn à coté c'est une rolls

A côté il y a juste un groupe google qui répond à toutes les questions par les mecs qui le développent ce qui est loin d'être le cas des gens qui font EF..., la possibilité d'avoir les sources et de trouver des infos super facilement. Mais bon, il y a juste une doc mise à jour et un site communautaire...On n'arrêtera jamais la fainéantise des utilisateurs microsoft.

Bref, nous ne sommes pas tous pareils, et voilà une réponse de quelques années d'expérience et de travail sur ce sujet :

IBatis est différent : c'est un mapper. C'est à dire qu'il n'intégre pas de logique objet ou de pattern particulier, il converti des objets en SQL et vice versa. C'est le plus simple à appréhender.

EF et Nhibernate sont des ORM, complexes à utiliser et à mettre en oeuvre pro.

Pour les T4, c'est une infra bouse qui va te donner de très mauvaises habitudes de travail mais qui donne l'impression à des gens que de générer du code depuis une base pour faire du mapping relationnel objet c'est le fin du fin (ca l'est si tu veux que ça marche mal en même temps). D'une maniére générale, si tu n'as jamais utilisé d'ORM de ta vie ou de ta carriére de développeur, tout ce qui est génération de code est à proscrire, tu passeras ton temps à régler des dysfonctionnements dus à la génération que tu n'aurais pas rencontré en connaissant le fondement du concept.

En termes de génération de code, puisque le T4 sert à cela, il y a d'autres solutions, mais le mapping contient aussi la vraie essence de l'ORM. Donc la comprendre c'est un vrai plus. En fonction des ORMS il y a soit des fichiers de mapping, soit des classes, soit des attributs et parfois tout.

Dans tous les cas, le choix de l'ORM est un choix comme un autre, dont tu dois te moquer éperdument. Simplement, il ne faut pas tomber dans l'erreur du débutant qui se dit "Tiens je vais utiliser un ORM comme ça, plus de problème de SQL !".

L'ORM est un outil complexe, avec des possiblités larges et des drawbacks en conséquence :
- La gestion de l'état (Charger / Décharger / Réaliser des transactions / Distribuer les transactions)
- La gestion de la récursivité (la collection de B dans A ou chaque A reférence son B et en continu qui fait que tu arrives à poser un question sur un forum parce que stack overflow)
- La gestion du graph objet (Ce n'est pas parce que tu fais une table qu'elle doit représenter un objet)
- La gestion du contexte de persistence
- La gestion des clefs en multi db est un bonheur inégalé, de même que les clefs composites objet (ça aussi c'est une erreur de débutant d'ailleurs)
- Les objets restent idiots donc tu dois raisonner en services atomiques
(Tu vas découvrir le bonheur de l'objet sans méthode métier que tous les "grands développeurs objets" nomment...objet métier; en effet, si ton object A dispose d'une propriété qui dépend de données que tu dois récupérer dans un contexte propre - de la logique métier quoi - tu ne pourras pas le faire dans l'objet directement...)

Le meilleur conseil ?
Faire du DDD
- Fais ton modèle objet pur
- Si tu as l'intention d'utiliser tes objets directement dans un client quelconque en utilisant le binding .Net : INotifyPropertyChanged. C'est précieux de savoir que ça existe (le même pour les collections existe aussi)
- Pour chaque objet, pense à implémenter un égalité rapide et exploitable.(IEquatable)
- Généralises par des interfaces les propriétés communes (eg : IBaseObject qui va contenir une propriété Id et Description); plus tard tu en seras content
- Préféres la composition à des graphs lourds en créant des DTO qui pourront fournir les données importantes à la demande
- Fais ton modèle d'objets non métier (Eg : les combo box, c'est idiot, mais ça existe et avec un ORM, ça peut vite devenir un enfer)
- Définis les types nécessaires à ton implémentation
- Pas d'énumération, sauf à ce que tu veuilles casser l'intégrité relationnelle (ce qui est un choix finalement)
- Assures toi que ton modéle soit testable sans accèder à la base

Implémenter ta base
- Au regard des tes objets, interroges toi sur la façon de les persister :

• Modéle physique
• Indexation des données
• Trigger ou pas
• Procédures stockées ou pas

Nota : si quelqu'un te dit qu'il n'y a pas besoin de comprendre le SQL pour se servir d'un ORM, pars en courant, il n'y comprend probablement pas grand chose !
- Si tes tables sont conçues; passes à l'étape exploitation

• Définis les vues dont tu as besoin (read only)
• Vérifies avec des jeux de données que ton indexation est pertinente en vérifiant tes plans d'exécution
• Vérifies que les règles d'intégrité sont bonnes entre les tables
• Définis clairement toutes les requêtes que tu auras besoin de gérer dans l'ORM (c'est très important j'y arrive après)

Implémenter l'ORM
- Mapper ta base avec les objets quel que soit l'ORM
- Conserver un accès "plain old SQL"; utiliser un ORM c'est parfois bien, maintenant s'il s'agit d'aller récupérer un couple 'Id/Nom' sur 3000 tuples, c'est de l'idiotie caractérisée !
- Ne jamais ouvrir de contexte / session longue. Rester dans un contexte atomique est disposable
- Ne jamais utiliser un ORM sans logger les requêtes SQL- Ne jamais utiliser un Linq sans connaitre les critère d'indexation des données dans la BASE (en local avec un petite base de 2 Go , ça marche toujours, en prod avec 500Go, ça marche jamais enfin si, mais ça fait des dead locks ou des time out) - Genre 'String.Contains("dlkdkfk",InvariantCultureIgnoreCase) - NE JAMAIS TE LAISSE LEURER PAR LA FACILITE APPARENTE !
- Faire des mesures de performance pour te donner un exemple, sur n'importe quel ORM juste ne changeant les paramètres, la même requête sur la même base dans les mêmes conditions peut prendre 1 seconde ou 150ms.
- Ne pas utiliser un ORM si tu ne comprends pas comment celui-ci :

1. Gére les états (Self Tracking; Proxy Tracking; Versioning Tracking)
2. Gére le chargement
3. Gére le chargement différé (proxy, interface, ghost..)

Un fois que tu en sera là, tu devrais avoir compris l'utilisation d'un ORM et pouvoir choisir convenablement le framework approprié et éventuellement t'outiller en génération de code.

Surtout n'oublies pas : Utiliser un ORM et passer un objet sur le tuyaux WCF, c'est à la portée de n'importe qui, la vraie complexité, c'est d'exposer une couche de service qui utilise des données de façon intelligente et propose autre chose que du crud. (Ce qui en soit ne demande pas d'ORM mais un data set qui fera ça super bien, plus vite et mieux).

Bon courage, et si tu as besoin d'aide, n'hésites pas; je serai ravi de t'aider et de te donner des snippets si cela t'aide.

Je te conseillerai aussi de jeter un oeil au Framework Spring.Net qui a une librairie d'accès aux données plutôt bien faire et intelligente et aussi au l'Enterprise Library de Microsoft qui posséde une couche donnée.

@+

[Targan]

J'avais lu ton post CineMania sur un sujet similaire, ce qui je l'avoue m'avait ouvert un peu les yeux sur le pk du comment de l'existence de certains O/R et l'intérêt d'utiliser ou non la librairie initiale de ADO.NET.

J'ai développé longuement en Delphi, en utilisant du requetage pur et direct, donc le passage sous .NET avec tous les changements d'architecture ne se fait pas sans difficulté.

Merci aussi à toi B.AF, ta réponse est très intéressante et assez complète même si je ne comprends pas tout :p
Je vais continuer de me renseigner, et surtout je vais me mettre sur du code pour faire des tests car à la longue je commence à m'y perdre un peu.

Mon souhait est vraiment de coder "proprement" sans avoir une usine à gaz.

Dans cette optique, j'aimerai faire un projet (peu importe sa taille) de test pour bien appréhender ces architectures n-tiers avec séparation des couches que ce soit en winform ou en ASP.NET.
J'avoue que sous Delphi, il n'y avait pas vraiment cet aspect....c'était bien plus direct, mais bien plus lourd à maintenir et déployer.

A terme, je voudrais faire une petite appli qui me permette d'appréhender la séparation de la couche DAO du reste (donc en gros pouvoir utiliser n'importe quelle SGBD voir même passer sur des fichiers à plat style XML), et séparer la couche présentation pour pouvoir réaliser ce mini projet en winforms, en asp.net classique ou MVC.

Je présume que cela doit être réalisable (non sans mal) pour bien aborder toutes ces histoires d'architectures.


Si vous avez d'autres infos, ou des conseils, ou des liens pour m'aiguiller et voir par où commencer je suis preneur ^^

Merci.

[Nathanael Marchand]

A côté il y a juste un groupe google qui répond à toutes les questions par les mecs qui le développent ce qui est loin d'être le cas des gens qui font EF..., la possibilité d'avoir les sources et de trouver des infos super facilement. Mais bon, il y a juste une doc mise à jour et un site communautaire...On n'arrêtera jamais la fainéantise des utilisateurs microsoft.

Sans ironie, je recherche toujours une référence NHibernate à la MSDN (index des classes triés par assembly)
Si tu as l'adresse je suis preneur!

[Targan]

En effet, la solution iBatis est arrivé en fin de vie et n'est plus développée, maintenue, il vaut donc mieux l'oublier.

A vrai dire ce n'est pas vraiment ce qui est dit sur leur site....Le projet change de nom, et le groupe s'est fait racheté.
Mais ca semble toujours "en vie".

Qqun a des retours d'xp sur le framework proposé ?

Merci.

[mermich]

Salut,

Avant de faire le match nhibernate vs entity vs ibatis vs ken vs ryu vs guile il serai bon à mon sens d'indiquer quelle sgbd tu vas attaquer car autant de le dire tout de suite entity ne supporte pas oracle tandis qu'nhibernate très bien.

meme si ils disent tous qu'ils sont multi sgbd, entre une base oracle et sqlserver, ton orm sera plus ou moins performant.

[Targan]

Je débute vraiment que ce soit en JAVA ou en .NET, et encore plus sur les frameworks/ ORM / Architecture MVC & co.

J'ai toujours codé de façon "oldschool" dans un langage procédural, et où tout était codé à la mano (notamment les requetes SQL).

Bref je voudrais découvrir, "tester" et monter en compétences.

Mon objectif est de mettre en œuvre une architecture plus ou moins complexe.

A l'heure actuelle, je comprends bien qu'iBatis n'est pas un ORM à proprement parler.
Du fait qu'il n'était plus maintenu était finalement un raccourci pour tester directement un ORM.

Maintenant, je vois qu'à priori le projet semble toujours en vie.....donc pk pas d'abord tester un mapping simple avant d'aller tester un NHibernate ou un EF.

Enfin, effectivement, ca ressemble bien à crosoft de se débrouiller pour favoriser les produits crosoft en l'occurrence SQL Server.
Cela ne me dérange pas plus que cela pour le moment....même si à terme il est vrai que j'aimerai me faire un petit projet multidb (oracle, SQL Server, PostGre).

[mermich]

Re,

Ce n'est que mon point de vue, mais en entreprise je n'ai jamais vu de changement de base de données: "on y est on y reste", donc le multi db c'est le cadet de mes soucis.

Ensuite si c'est juste pour toi, je dirai qu'il vaudrait mieux commencer avec dataset typés et une archi n couches.

Avant de taper la ferrari commence par la twingo, qui sera peut etre moins performante mais bien plus simple à démarrer.