Discussion :

[Louis-Guillaume Morand]

Bonjour tout le monde,

J'aimerais connaitre votre avis sur les APIs / bonnes pratiques les plus utilisées sous .NET.

Je pourrais vous dire par exemple que sous J2EE les APIs ou les concepts les plus utilisées sont ( sans avoir la prétention de vous dire quelque chose d'exact, ce n'est que du feeling ) Struts, Hibernate, Spring, EJB..

Quels sont les équivalents en .NET selon votre expérience qui ont autant de popularité que ceux-là sous J2EE ?

ADO.NET par exemple, peut substituer Hibernate.. Mais qu'en est-il des framework tels Spring ? Qu'en est-il des frameworks type MVC comme Struts ? et ADO.NET permet-il de faire tout ce qu'hibernate propose ? ( avez-vous peut-être rencontré une entreprise qui a utilisé une solution alternative ? )

Merci d'avance pour vos réponses !

[Maniak]

ADO.NET par exemple, peut substituer Hibernate..

euh... non, carrément pas

Mais qu'en est-il des framework tels Spring ?

Spring.NET

Qu'en est-il des frameworks type MVC comme Struts ?

MonoRail

ADO.NET permet-il de faire tout ce qu'hibernate propose ?

Oui, si tu codes tout toi-même. Heureusement il y a NHibernate :)

[KiLVaiDeN]

Merci pour ces infos précieuses

J'ai arrêté le developpement .NET depuis un bout de temps, et je n'ai participé qu'à des projets J2EE suffisament larges pour utilises les APIS que j'ai cité. En .NET je n'ai jamais eu besoin encore d'utiliser de telles APIs, donc me mettre à jour était nécessaire !

Penses-tu que Sprint.NET, Monorail et NHibernate soient les plus utilisés ? Connais-tu des alternatives populaires ?

Merci

[Maniak]

Penses-tu que Sprint.NET, Monorail et NHibernate soient les plus utilisés ? Connais-tu des alternatives populaires ?

S'il y a des alternatives populaires, ce sont celles-là (parce que justement, portages de Spring/Rails/Hibernate).

Ce sont probablement parmi les plus utilisées chez ceux qui ne se contentent pas des outils 'de base', mais de là à dire que c'est *très* utilisé, il y a un pas que je ne franchirai pas :)
Les dévs (ou pseudo) qui gravitent autour des technos MS semblent être beaucoup moins au courant des projets open source que les autres (genre, au hasard, Java :)
Moins au courant, pas intéressés, contents de l'usine à gaz que l'éditeur peut leur pondre en deux clics, ou n'ayant juste pas le niveau de bosser avec du vrai code. Au choix :)

[Keihilin]

Oui bon, après il faut encore voir les effets de mode et les débats d'architectes...

Il est vrai que les framework issus d'un portage de java sont assez appréciés; simplement parce qu'on a un retour d'expérience en comparant avec java...

Cela dit, et je reviens à l'effet de mode, chaque framework à ses supporters et ses détracteurs...Pour chaque architecte qui te dira que, au hasard, log4net est un truc génial, je t'en trouverai un tout aussi qualifié qui te dira que c'est une infâme usine à gaz.

Il en va de même pour tout ce qui touche à MVC...Alors que cette architecture était considéré comme un standard, elle est de plus en plus décriée depuis quelques mois...

Bref, ces divergences et ces changements d'avis souvent véhiculés par des architectes de renom n'incitent pas vraiment à adopter massivement tel ou tel framework.

Pour finir, je ne suis pas convaincu que le temps d'apprentissage de certains outils comme NHibernate vaille vraiment la peine au regard du temp gagné en développement...

[KiLVaiDeN]

J'ai quelques questions à te poser :

1) Tu dis que l'architecture MVC est de plus en plus décriée, en faveur de quoi ? Des webservices ? Ayant travaillé sur plusieurs projets utilisant MVC, je t'avouerais que je suis assez fan de cette architecture, elle permet d'avoir un code propre et structuré, et étendue par un framework transversal comme Spring, elle permet de vraiment bien séparer les couches présentation et métiers. Quelle alternative vois-tu ?

2) Comme tu dis, un énorme avantage à l'utilisation des APIs tels que Spring ou NHibernate est que ça permet aux personnes de se réunir autour de technologies très utilisées également sous J2EE. De plus, ces APIs ont fait leur preuve, et de nombreux projets sont écrits avec, de nombreuses personnes ont de l'experience avec. Je voudrais seulement te poser une question, par rapport à ta remarque sur NHibernate. Tu dis que tu ne vois pas forcément le gain en temps de développement par rapport au temps d'apprentissage, mais il est quand même important d'avoir un mapping Objet/Relationnel lorsque le modèle de l'application est orienté objet : c'est là qu'hibernate ( ou NHibernate ) est très puissant, et prend toute son ampleur, on peut continuer à utiliser un langage purement objet, sans se soucier du coté relationnel qui est géré par Hibernate. Le gain de temps est à mon avis colossal, car du coup, non seulement tu n'as plus à te soucier à l'avenir de mapper tes objets manuellement comme ça serait le cas sans Hibernate, mais en plus tu peux capitaliser une "couche" de bas niveau, qui contiendrait des objets exploitables par plusieurs projets ! Peux-tu peut-être m'éclairer et me dire en quoi tu trouves que le gain est mineur ? Peut-être connais-tu des techniques en ADO.NET par exemple qui te font également gagner du temps... Je suis à la recherche d'informations sur les bonnes pratiques en .NET, si tu pouvais me donner des pistes par rapport à celles que tu penses être les meilleures, ça serait très sympa

A+ !

[Maniak]

Pour chaque architecte qui te dira que, au hasard, log4net est un truc génial, je t'en trouverai un tout aussi qualifié qui te dira que c'est une infâme usine à gaz.

Là je souscris (pour le moment :)
Mais c'est aussi par manque de temps pour vraiment voir comment ça marche. Et parce que l'intérêt dans mon cas est encore à démontrer pour justifier ce temps.

Il en va de même pour tout ce qui touche à MVC...Alors que cette architecture était considéré comme un standard, elle est de plus en plus décriée depuis quelques mois...

Décriée je sais pas. C'était pour ainsi dire le seul pattern 'connu' pendant un moment, maintenant il y en a davantage (notamment MVP, qui n'est jamais qu'une légère variation de MVC).

Pour finir, je ne suis pas convaincu que le temps d'apprentissage de certains outils comme NHibernate vaille vraiment la peine au regard du temp gagné en développement...

Et là par contre, toujours pour mon cas, si, ça le vaut :)
Le temps d'apprentissage (pour un usage 'basique') est très court, et ça suffit à ne quasiment plus avoir besoin de passer du temps sur la partie d'accès aux données. Temps qui peut être consacré aux parties plus 'importantes'.

Maintenant j'insiste, c'est dans mon cas. Il ne faut clairement pas généraliser, mais essayer soi-même dans sa propre situation pour déterminer si l'intérêt est bien présent.

Spring.NET, j'ai rapidement essayé, pas eu vraiment d'utilité jusque là, pas utilisé plus que ça.
MonoRail, c'est en cours d'étude.
NHibernate, là je suis définitivement vendu.
.NET2 (dans un sens, c'est la même catégorie) pareil, vendu. Rien que pour les templates. Repasser en 1.1 serait très douloureux :)

[Keihilin]

1) Tu dis que l'architecture MVC est de plus en plus décriée, en faveur de quoi ? Des webservices ? Quelle alternative vois-tu ?

C'est à peu prêt ça oui, c'est la tendance SOA qui remet en cause MVC...
Et on en revient aux effets de mode parce que SOA c'est de loin pas une idée révolutionnaire; c'est une idée remise au goût du jour.
Quant aux alternatives, il y en a plusieurs selon les cas. Maniak a déja cité MVP (Model View Presenter), mais il y en a d'autres qui répondent à des problématiques bien précises.

Je t'invite à lire les différents articles de Martin Fowler (www.martinfowler.com), tu découvriras qu'il n'y a (hélas) pas une "vérité", mais des "vérités"...

Tu dis que tu ne vois pas forcément le gain en temps de développement par rapport au temps d'apprentissage, mais il est quand même important d'avoir un mapping Objet/Relationnel lorsque le modèle de l'application est orienté objet

Le débat peut être complexe...Je pense que l'intérêt des outils de mapping dépend de la manière d'aborder une application.
Dans une approche "Top-Bottom", une approche ou l'on conçoit d'abord le domaine d'objets, les outils de mapping sont très utiles car la base de données est considérée comme un simple "repository" d'objets.
Mais il y a des cas où l'on doit aborder une application avec une approche "Bottom-Top" parce que la base de données est l'éléments le plus important du système et qu'en plus elle va être partagée entre plusieurs systèmes. Si dans un tel cas on se retrouve avec des problématiques d'optimisations poussées dans la construction des requêtes SQL, l'outil de mapping soit atteint ses limites, soit perd de son intérêt quant au temps gagné.

mais en plus tu peux capitaliser une "couche" de bas niveau, qui contiendrait des objets exploitables par plusieurs projets !

Je ne pense pas que ce soit un argument...Avoir une couche d'objets de données réutilisables c'est pas le top à l'heure de SOA et de l'échange de messages plutôt que d'objets (effet de mode, effet de mode )

Le temps d'apprentissage (pour un usage 'basique') est très court, et ça suffit à ne quasiment plus avoir besoin de passer du temps sur la partie d'accès aux données. Temps qui peut être consacré aux parties plus 'importantes'.

Le mot est laché : "utilisation basique". Voilà le problème à mon sens...Désolé, mais je n'ai pas la chance de devoir produire des applications "basiques"...

[KiLVaiDeN]

MVP n'est rien de plus qu'une tentative d'IBM pour s'approprier du concept MVC en soi-disant ajoutant un concept qui était déjà présent en MVC, enfin c'est mon avis

[KiLVaiDeN]

Tu as fait une remarque interessante par rapport à l'approche Top-Bottom ou Bottom-Top, j'ai d'ailleurs été confronté à une approche Bottom-Top avec Hibernate, et en effet, lorsqu'on est amené à faire des relations complexes par rapport à un modèle de données existant, on peut se demander quel est l'avantage d'utiliser un mappeur objet/relationnel.

Mais même dans ce cadre là, ça a été utile pour une chose cruciale à mon sens : grace à hibernate on a crée la couche "basse" qui était un ensemble d'objets ( un objet par table en gros ) et que toutes les applications ont pu importer via CVS, résultat : il n'y avait plus qu'à déployer les "services" correspondants aux requêtes necessaires par les applications, et le tout était capitalisé, pas besoin de connaitre particulièrement le modèle de données pour récupérer une liste d'enregistrement membre par exemple, on souhaitait récupérer un dossier -> getDossier(int idDossier) nous retourner un objet contenant des collections d'objets correspondant aux tables sujettes aux contraintes d'intégrité. Tu me diras que tout ça aurait pu se faire en SQL, mais bon, après comme tu dis ça devient un débat où chacun a un point de vue relatif à son experience, et où très peu de choses peuvent faire pencher la balance dans un sens comme dans l'autre. Dans ce cas là, il a été difficile et fastidieux de produire la couche basse ( même si il y a des outils puissants comme MiddleGen qui prémachent une grande partie du travail ! ) mais après, que du bonheur !

Pour ma part je ne suis pas un fanatique des effets de mode : SOA c'est sympa, mais il ne faut pas remettre en cause des architectures éprouvées comme MVC rien que parce que le SOA est en tête des tous les journaux informatiques du moment ! J'ai participé à plusieurs projets assez complexes où nous n'avons jamais eu à mettre en place une architecture orientée services : un grand avantage des services est de permettre un "transport" des données efficaces et multiplateforme/multilangage, mais quand on a pas besoin de ce genre de fonctionnalité, ça ressemble plus selon moi à déployer une usine à gaz pour ne pas profiter pleinement des vrais "avantages" des services ( encore je dis à mon avis ! ).

L'utilisation de "services" existe sous plusieurs formes, dans un système multi-couche par exemple, on peut aussi dire que chaque couche rend un "service" à la couche supérieure. Donc en faisant du Spring, on fait du SOA, et en mettant hibernate sur une couche basse, on fait tout aussi bien du SOA, c'est juste une question de point de vue, c'est dangereux je trouve d'utiliser des termes aussi "génériques" ! Voila, je trouve ce débat interessant.. Merci en tout cas pour vos remarques qui sont précieuses !

[Maniak]

Mais il y a des cas où l'on doit aborder une application avec une approche "Bottom-Top" parce que la base de données est l'éléments le plus important du système et qu'en plus elle va être partagée entre plusieurs systèmes. Si dans un tel cas on se retrouve avec des problématiques d'optimisations poussées dans la construction des requêtes SQL, l'outil de mapping soit atteint ses limites, soit perd de son intérêt quant au temps gagné.

Cas existant, certes, mais j'aurais tendance à dire qu'il n'est pas *si* fréquent que ça (du moins dans le contexte de nouvelles applis, et pas de reprise d'existant).
Et de toute façon, pour pouvoir déterminer si un outil de mapping peut ou non atteindre ses limites dans un cas particulier, il faut avoir essayé pour savoir quelles sont ses limites :)
Ça demande d'investir du temps en exploration de la chose, mais si on ne le faisait jamais, on se limiterait toujours à ce qu'on a de base avec l'éditeur (et ça fait pas lourd) en se faisant tout le reste soi-même (et c'est très probablement moins bien que ce qui existe déjà depuis plus longtemps, avec plus de dévs et d'utilisateurs).

C'est une bête question de temps à la base.

Je ne pense pas que ce soit un argument...Avoir une couche d'objets de données réutilisables c'est pas le top à l'heure de SOA et de l'échange de messages plutôt que d'objets (effet de mode, effet de mode :wink:)

SOA peut-être, pour le reste (au hasard, DDD :), moins :)

Le temps d'apprentissage (pour un usage 'basique') est très court, et ça suffit à ne quasiment plus avoir besoin de passer du temps sur la partie d'accès aux données. Temps qui peut être consacré aux parties plus 'importantes'.

Le mot est laché : "utilisation basique". Voilà le problème à mon sens...Désolé, mais je n'ai pas la chance de devoir produire des applications "basiques"...

T t t, qui a parlé d'applications basiques ? :)
J'ai parlé d'usage basique de NHibernate, et avec un usage basique de NHibernate on fait... ben... à peu près tout en fait. Le reste est plus du domaine des besoins très spécifiques, genre adaptation à une base existante pas forcément très amicale.

Un usage basique de NHibernate, ça couvre le mapping de toutes les tables, les relations, les mises à jour, la gestion automatique du polymorphisme, ...
Largement de quoi faire des applications complexes. C'est d'ailleurs pour ces applis-là qu'on gagne le plus de temps, puisqu'on peut se consacrer sur les parties complexes plutôt que perdre du temps à se faire sa propre gestion de persistence :)

Après forcément, si on fait une application qui a des besoins très tordus vis-à-vis de la base et des contraintes de performances très fortes, faut réfléchir avant. Sachant que NHibernate permet de repasser à du SQL 'direct' quand on en a besoin, sans pour autant sacrifier la simplicité des méthodes 'normales' pour le reste du temps.


De toute façon on ne peut pas généraliser, c'est toujours du cas par cas au final. NHibernate c'est bien, mais c'est pas non plus une formule magique. Faut pas sauter sur un outil et laisser les neurones au placard :)

[Keihilin]

L'utilisation de "services" existe sous plusieurs formes, dans un système multi-couche par exemple, on peut aussi dire que chaque couche rend un "service" à la couche supérieure. Donc en faisant du Spring, on fait du SOA, et en mettant hibernate sur une couche basse, on fait tout aussi bien du SOA, c'est juste une question de point de vue, c'est dangereux je trouve d'utiliser des termes aussi "génériques" !

Juste une remarque concernant ce dernier point :

De même qu'un certain nombre de paradigmes définissent ce qu'est la POO, il y a des règles qui définissent une architecture SOA.
L'une de ces règles est que les services partagent des shémas (et non des classes) et échangent des messages.
Partant de là, les exemples que tu donnes ne rentrent pas dans le cadre de SOA...
Donc oui, le concept de "service" est très générique, mais les concepts englobés dans l'appelation SOA sont bien définis.

[Maniak]

MVP n'est rien de plus qu'une tentative d'IBM pour s'approprier du concept MVC en soi-disant ajoutant un concept qui était déjà présent en MVC, enfin c'est mon avis :)

...
comment dire...
oui oui ? :)

Tu as fait une remarque interessante par rapport à l'approche Top-Bottom ou Bottom-Top, j'ai d'ailleurs été confronté à une approche Bottom-Top avec Hibernate, et en effet, lorsqu'on est amené à faire des relations complexes par rapport à un modèle de données existant, on peut se demander quel est l'avantage d'utiliser un mappeur objet/relationnel.

Faire le pont entre le modèle existant dans la base et le modèle du domaine développé dans le code.

Il y a des limites aux possibilités de ce pont, forcément, ça dépend de l'état de la base existante. Mais toute étape permettant de s'éloigner d'une appli qui raisonne en fonction d'une BDD et de s'approcher d'une appli qui raisonne en fonction du domaine, c'est plutôt positif :)

Top/Down, Bottom/Up, même combat. C'est juste que sans framework de persistence, Down/Bottom c'est le système de persistence qu'on doit se faire manuellement. Avec un framework de persistence, Down/Bottom est le niveau au-dessus. Tout dépend d'à quel point un framework de persistence est adapté au cas présent. Mais plus le temps passe, et plus les frameworks en question s'adaptent bien :)

L'utilisation de "services" existe sous plusieurs formes, dans un système multi-couche par exemple, on peut aussi dire que chaque couche rend un "service" à la couche supérieure.

Cf Hexagonal Architecture pour une version plus étendue du même principe :)

[Keihilin]

Après forcément, si on fait une application qui a des besoins très tordus vis-à-vis de la base et des contraintes de performances très fortes, faut réfléchir avant. Sachant que NHibernate permet de repasser à du SQL 'direct' quand on en a besoin, sans pour autant sacrifier la simplicité des méthodes 'normales' pour le reste du temps.

Sans même chercher des contraintes de performances trop poussées, la problèmatique principale des outils de mapping est la même dans tous les framework : la gestion des relations 1-n et surtout n-n.
Les approches peuvent être différentes pour gérer ça, mais elles ne sont jamais "optimales" et terme de perfs.

Toujours sur les performances, l'utilisation des attributs, et donc de la reflection a forcément un coût non-négligeable...

Bref, même si la différence peut être légère dans beaucoup de cas, les perfs ne sont pas en faveur des outils de mapping. Maintenant au niveau du gain de temps; est-ce que pondre des fichiers xml au kilomètre est vraiment un gain de temps ? (sans ironie hein, je pose juste la question).

[Maniak]

Sans même chercher des contraintes de performances trop poussées, la problèmatique principale des outils de mapping est la même dans tous les framework : la gestion des relations 1-n et surtout n-n.
Les approches peuvent être différentes pour gérer ça, mais elles ne sont jamais "optimales" et terme de perfs.

Optimales non, suffisantes probablement.
Pour les rares cas où ça a besoin d'être optimal, on peut toujours le faire à la min. Pour tous les autres, on utilise ce qui est fourni. Dans tous les cas, ça se situe tout en bas des couches, sans impact sur le reste du code. Ce qui permet notamment de ne pas avoir à se préoccuper de chercher des perfs optimales tant qu'il n'a pas été démontré que c'était nécessaire :)

Toujours sur les performances, l'utilisation des attributs, et donc de la reflection a forcément un coût non-négligeable...

Pas d'attributs avec NH, mais de la réflexion, forcément. Cela dit, une solution de mappage perso est rarement d'une légèreté phénoménale, en plus d'être plus compliquée à mettre en place.

Bref, même si la différence peut être légère dans beaucoup de cas, les perfs ne sont pas en faveur des outils de mapping.

Heureusement, la différence est mineure (vraiment), donc dans beaucoup de cas, on s'en fiche royalement :)

Maintenant au niveau du gain de temps; est-ce que pondre des fichiers xml au kilomètre est vraiment un gain de temps ? (sans ironie hein, je pose juste la question).

S'il fallait en pondre au kilomètre, probablement pas.
Mais vu que ce n'est pas le cas, si, c'est un gain de temps.

Ce n'est pas une perte de temps en premier lieu parce que même avec une solution perso, il faut bien de la config quelque part, et c'est un gain de temps ensuite parce qu'on n'a grosso modo rien d'autre à faire :)

Je craignais la même chose que tout ce que tu décris là quand j'ai commencé à jeter un oeil sur NHibernate, mais j'ai été (très) agréablement surpris. Je ne sais pas dans quel état c'était dans les premières versions, mais actuellement, ça tourne vraiment très bien, la config n'est pas vraiment lourde, franchement ça va :)

C'est pas tout rose, forcément, mais jusque là je n'ai pas encore rencontré de problème tellement important que je regrette de m'y être mis. Et quand j'en rencontrerai un (ça viendra forcément), il sera temps d'étudier les fonctionnalités plus étendues de NH. La solution sera peut-être déjà couverte. Et sinon... vu que NH n'empêche pas de taper directement dans la base si nécessaire... :)

[KiLVaiDeN]

J'ai jeté un oeil plus approfondi sur le sujet de NHibernate.

Je connais Hibernate pour l'avoir utilisé ( en version 2 et 3 ) et je vois que NHibernate est un clone de la version 2 de Hibernate. Il a donc un peu de retard.

J'ai également jeté un oeil sur des alternatives, et j'ai trouvé Wilson.ORmapper ( http://Ormapper.net ) ce qui amène à une piste dénommée "Object Spaces" qui sera livrée avec Windows Longhorn et son nouveau File System WinFS. Apparement Object Spaces sera intégré dans le système, et sera donc le mappeur "officiel".. Une bonne idée ? Qu'en pensez-vous ? Avez-vous des infos sur le sujet ? Object Spaces s'appelle maintenant DLinq ( Dont voici une description au format word )

Pour ma part, je compte approfondir :

Pour la phase Build/Test/Deploy : CruiseControl, nAnt, nCover, nUnit, fxCop
Pour le mapping O/R : NHibernate
Pour la structure du code : recommendations Microsoft
Developpement : Visual Studio .NET ( Que pensez-vous de SharpDevelop ? )
Langage : C# ( que pensez-vous de VB.NET ? je sais qu'il y a un débat ouvert à ce sujet, pas la peine de m'y orienter )

Merci pour vos commentaires !

[Pierre Henri Kuate]

Il est important de ne pas oublier que chaque outil vise à résoudre un certain nombre de problèmes, pas TOUS les problèmes... Donc toute technologie est parfaite sur un point de vue et nettement insatisfaisante sur un autre.

Et les "bonnes pratiques" ne s'appliquent pas à toutes les situations; il faut comprendre quels sont leurs (dés)avantages et faire des compromis pour définir la solution idéale à un problème donné.

Je pense qu'utiliser un ORM pour une application de moins de 10 tables/entités peut ne pas être une bonne idée, surtout si on ne maitrise pas l'ORM en question (sauf s'il s'agit de s'exercer...)

Enfin, la plus part des technologies ne deviennent profitable qu'après une (plus ou moins) longue période d'apprentissage; qu'il s'agisse de Windows, du C# ou d'une librairie quelconque.

Bref, même si la différence peut être légère dans beaucoup de cas, les perfs ne sont pas en faveur des outils de mapping. Maintenant au niveau du gain de temps; est-ce que pondre des fichiers xml au kilomètre est vraiment un gain de temps ? (sans ironie hein, je pose juste la question).

Un bon ORM peut permettre de gagner en performance grâce à des techniques comme le "lazy loading" (chargement retardé), le "batch fetching" (chargement par lots) et toutes les autres techniques de caching et de fetching. Mais évidemment, il existe des situations où il vaut mieux ne pas s'en servir (example classique: lorsqu'on doit traiter une énorme quantité de données d'un coup).

Je ne comprend pas le problème: "pondre du XML"...
Le XML est un "langage" comme les autres; lorsqu’on y est habitué et qu'on a les bon outils, on peut être très productif. Et je ne connais pas beaucoup d'alternatives pour définir ces informations; il y'a bien le mapping grâce aux attributs .NET qui a son lots d’avantages et de désavantages.
Et ces méthodes ne posent pas de réels problèmes au niveau des performances parce que l’analyse (la reflection) n'est faite qu'au "démarrage" de l'application (une forme de compilation).


Je ne ferais pas de commentaires sur (D)Linq puisque c'est une technologie en cours de développement; d'ici qu'elle sorte elle aura surement beaucoup évoluée (et les autres ORMs aussi).
J'imagine même qu'elles pourraient devenir inter-opérables. A suivre...


Je te propose d'ajouter les outils d'AOP à ta liste (comme AspectSharp) et toutes les libraries du projet Castle

[Keihilin]

Bref, même si la différence peut être légère dans beaucoup de cas, les perfs ne sont pas en faveur des outils de mapping. Maintenant au niveau du gain de temps; est-ce que pondre des fichiers xml au kilomètre est vraiment un gain de temps ? (sans ironie hein, je pose juste la question).

Un bon ORM peut permettre de gagner en performance grâce à des techniques comme le "lazy loading" (chargement retardé), le "batch fetching" (chargement par lots) et toutes les autres techniques de caching et de fetching.

Non, ce ne sont pas des gains de performance...Faire du "lazy loading" ou du "batch fetching" manuellement et selon les nécessités de l'application, c'est un comportement normal. Encore heureux que les outils de mapping utilisent ces techniques.

Je ne comprend pas le problème: "pondre du XML"...
Le XML est un "langage" comme les autres;

Non, XML n'est pas un langage au même titre que C# ou Java, mais bon passons. Certains outils nécessitent un fichier xml par classe persistente afin d'effectuer le mapping...Ma question est donc de savoir si écrire ces fichiers XML est véritablement un gain de temps par rapport à l'écriture de classes "manager" (par exemple) qui se chargeront du mapping.

[Pierre Henri Kuate]

Certains outils nécessitent un fichier xml par classe persistente afin d'effectuer le mapping... Ma question est donc de savoir si écrire ces fichiers XML est véritablement un gain de temps par rapport à l'écriture de classes "manager" (par exemple) qui se chargeront du mapping.

Franchement, je ne vois pas comment écrire des classes "manager" peut être plus rapide que d'appliquer des attributs sur des objets ou d'écrire une ligne XML par objet/champ

Mais, je ne pense pas que la rapidité d'écriture doivent entrer en compte. Le temps de conception et de débogage est généralement largement plus long que le temps d'écriture du programme. Et ce sont des étapes qu'un bon ORM peut énormement simplifier.

[RamDevTeam]

J'ai jeté un oeil plus approfondi sur le sujet de NHibernate.

Pour ma part, je compte approfondir :

Pour la phase Build/Test/Deploy : CruiseControl, nAnt, nCover, nUnit, fxCop
Pour le mapping O/R : NHibernate
Pour la structure du code : recommendations Microsoft
Developpement : Visual Studio .NET ( Que pensez-vous de SharpDevelop ? )
Langage : C# ( que pensez-vous de VB.NET ? je sais qu'il y a un débat ouvert à ce sujet, pas la peine de m'y orienter )

Merci pour vos commentaires !

Connaissez vous ECO de Borland ?
Quel différence par rapport à NHibernate ? (en dehors du coût ;-) )