Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
O/R : NHibernate ou iBatis ?
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.
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.
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
Retrouvez moi sur :
Mon Espace Developpez.com-------------------------------
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.Envoyé par PitMaverick78
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
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 :
- Gére les états (Self Tracking; Proxy Tracking; Versioning Tracking)
- Gére le chargement
- 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.
@+
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.
Je te conseille de regarder les exemple de code livrés avec SPring .Net, ils sont très clairs et te donneront une bonne base pratique (que tu utilises spring ou pas)
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!
Retrouvez moi sur :
Si je ne m'abuse, tu dois avoir toute la doc disponible sous Visual Studio d'après ce qui est raconté sur ce lien : NHibernate
Je n'ai pas testé encore, donc dsl si cela ne répond pas à tes attentes.
C'est là...
Svn Nh
Le code est documenté, les fichiers XML de doc sont produits, si tu veux mettre un coup de NDoc vas y, mais le but du jeu est surtout de pouvoir allez regarder ce qui se passe dans le code.
ok, c'est noté... D'ailleurs, faut que je me renseigne sur spring également, car je ne pige pas trop ce que cela fait et comment ca peut intervenir sur n'importe quelle couche....
Mais ca reste un framework référence en java, donc forcément ca doit être intéressant :p
Spring te permet de définir des objets à priori de l'usage et donc de réduire ton volume de plomberie.
C'est à dire que tu vas définir ton objet, ses valeurs (propriété, constructeurs...) et que Spring va charger ces "objets pré paramétrés" dans un registre. Sachant qu'il va créer des instances, tu vas disposer d'objets déjà créé, qui demanderons moins de code dans les objets.
Ca te permet de créer une factory d'objets, correctements initialisés et instanciés. C'est très simple, il suffit de regarder les exemples.
Dans la même logique il ont crée des outils de connection / utilisation de SGBD qui se configurent et s'injectent.
C'est intéressant, quoi qu'en .Net, unity est très bien, Spring étant resté souvent très java, donc tirant peu parti des avantages .Net, et je ne sais pas si tu as déjà pu mettre le nez dans le code source de spring en Java...Ca fait peur (mais ça marche, et je crois que même les gens de spring le reconnaissent).
Merci infiniment pour ces explications ^^
Je n'ai pas encore regardé les exemples, mais je compte bien le faire prochainement. Malheureusement (ou heureusement lol), actuellement professionnellement, je suis en train de bosser sur des projets JAVA ou je n'ai que très peu de compétences également...
Bref avec un peu de chance je pourrais voir cela en java, ou voir les différences d'utilisation.
Néanmoins, j'adore tes explications qui je trouve utilise un vocabulaire très imagé, très simple et qui permet vraiment de dégrossir rapidement le sujet ^^
De rien, on a tous commencé un jour.
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.
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.
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).
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.
Même si je change de langage, le DataSet en gros je connais....
Si on part sur des phrases métaphoriques, on peut aussi dire qu'il est intéressant de tester la Ferrari pour savoir ensuite ce que la Twingo ne peut pas faire (et vice versa :p) ^^
Non plus sérieusement, je ne cherche pas forcément à faire (ou ne pas faire) que ce qui se fait en entreprise.....parce que sinon je ne ferais rien (ou presque) quand je vois sur quoi je tombe depuis que j'ai commencé de bosser :p
Comme dit et redit, je souhaite apprendre, tester, utiliser dans un cadre perso pour ensuite pouvoir faire des choix en fonction du besoin: multidb ou non, perfs/maintenance/modularité/evolution, etc....etc...
Rien que pour l'histoire des multidbs, suffit de bosser dans une boite qui se positionne comme éditeur pour en avoir le besoin. C'est sur qu'en SSII, les projets bougent peu ou ont moins ce besoin.
[edit] j'en reviens au sujet initial : iBatis ou MyBatis now....qqun a testé récemment ? c'est tjs viable ? ca a tjs un intérêt ? merci.
En java oui, en .Net non, ça fait un moment que les dev sont stoppés.
Rien ne t'empêche de l'essayer, l'existant est stable, mais si ce que tu cherches c'est de rester un peu "close to the metal", tu peux regarder ça qui est équivalent et même un peu mieux foutu (plus léger et maintenu)
BLToolkit
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager