BOnjour,
Je souhaiterais savoir ce qu'apporte Entity Framework par rapport à Hibernate car pour pour le moment, je ne vois pas vraiment de différence dans tous les articles que j'ai lu.
Je vous remercie de votre aide.
Version imprimable
BOnjour,
Je souhaiterais savoir ce qu'apporte Entity Framework par rapport à Hibernate car pour pour le moment, je ne vois pas vraiment de différence dans tous les articles que j'ai lu.
Je vous remercie de votre aide.
-Intégration de Linq
-Des outils pour faire le mapping très performant et bien intégré a visual studio
-Ce n'est pas uniquement pour les base de données et a terme peut etre utiliser pour se mapper à n'importe quel type de source de donner
- c'est une base d'acces au données qui sert a d'autres outils très intéréssant comme par exemple astoria
- une orientation plus RAD
- Certaine option de tracking des modification (mais moi j'aime pas mais d'autres si)
Je pense qu'il y a d'autres choses j'ai pas encore utiliser sur un projet de A a Z
Après tout n'est pas rose et nhibernate a aussi des avantages comme le fait d'être "Persitance Ignorant" ou encore d'avoir un cache plus configurable
Pour faire l'avocat de NHibernate :
* Plus abouti (car plus ancien)
* Très utilisé, compatible avec beaucoup de solutions tierces
* Une communauté beaucoup plus importante
J'ai découvert EF très récemment, mais il semble que Microsoft va le pousser en avant : "We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios."
Traduction : nous investissons beaucoup dans l'Entity Framework, afin que ce soit la solution compatible LinQ recommandée pour tout ce qui est accès aux données dans .Net 4.0.
Source : ADO.Net team blog, 29 oct 2008
http://blogs.msdn.com/adonet/archive...s-roadmap.aspx
Sinon pour ceux qui voudraient un aperçu technique de Entity Framework, je conseille vivement le tutoriel de Paul Musso tutoriel de Paul Musso
De ce que je me rappelle, tu as surtout une difference de philosophie entre les deux...Citation:
Envoyé par gregb34
Apres, effectivement, de ce qu'il me semble, NHibernate est, a l'heure actuelle, toujours le plus abouti des deux ;)
Au niveau du mapping, si je me rappelle bien, tu as un tres joli outil de mapping graphique pour EF, mais je crois que le revers de la medaille, c'est une impossibilite de faire des merge efficaces au niveau du controleur de code source (et puis de toute facon, tant qu'on bossera avec VS 2005, EF n'est pas une option..)
Si je puis me permettre, pour une meilleure compréhension des choses par les nouveaux arrivants à EF et/ou à NHibernate qui ont besoin de "faire un choix", j'aimerais dire que les réponses à la question initiale sur ce fil sont assez justes à mon avis, mais qu'il y a une dimension à ne pas perdre de vue : les "scopes" (portées) respectives des deux "technologies" ou simplement "librairies" si vous préférez.
En effet, on a coutume de dire qu'il convient toujours d'essayer de comparer ce qui est comparable.
Or, comparer NHibernate (initialement, un portage de l'éprouvé Hibernate Java, qui maintenant évolue avec .NET lui même) et EF, qui semble être une autre brique satellite majeure dans l'arsenal de la plate-forme .NET, à côté de WCF, WF, etc, c'est un peu comparer un ferry avec un paquebot de luxe.
Ainsi, NHibernate (le ferry, qui transporte des gens sur les flots), a été historiquement et reste **dans une large mesure** un **ORM** : "mapper" Objet-Relationnel ; et il remplit très honorablement sa fonction, pour l'avoir mis en oeuvre dans des projets importants, jusqu'en version 1.2. A ce titre, c'est surtout "juste" une librairie parmi tant d'autre, pour répondre au besoin de "mapper" les graphes d'objet .NET avec les "nuages" conceptuels et physiques d'entités-relation que l'on doit gérer du côté de la persistence (SGBD/R, transactionnels ou non).
Je n'ai fait que "jouer" avec EF (le paquebot, plus "luxueux", plus équipé que le ferry) mais j'ai assez vite vu que sa portée est beaucoup vaste :
c'est ce que j'appellerai un "vrai" sous-framework du .NET FX, qui va vouloir titrer parti de beaucoup de choses à la fois : le runtime .NET lui même bien sûr, mais aussi les APIs d'extensibilité dans Visual Studio, les ajouts aux langage C# 3.0 (LINQ), puis C# 4.0, (dynamicité), etc.
C'est pour cela que je vois EF plus comme quelque chose à mettre au même niveau d'indentation que WCF, WF, WPF, etc, qui se veulent tous clairement bcp plus que des librairies, en voulant aussi être des "fournisseurs" interactifs pour l'outil de modelisation dans l'EDI (qu'il soit MS VS, CodeGear, etc) tandis que NHibernate est beaucoup plus "agnostique" quant à l'utilisation qui en est faite dans les outils de développements.
Sauf erreur de ma part, un élément très révélateur est qu'NHibernate n'a par exemple pas (du tout?) besoin de custom attributes pour "fonctionner" (seuls ses fameux mappings ".hbm.xml" suffisent), ce qui est exactement le contraire dans tous ces autres "sous-frameworks" de .NET FX dont EF fait partie.
My two cents.
Citation:
Envoyé par pvialatte
Autant pour moi, j'ai omis de préciser pourquoi je considère que c'est revelateur de la difference de portée entre les deux, ce qui n'est à priori pas évident :Citation:
Envoyé par lysiandad
NHibernate, pour son boulot de mapping objet-relationnel, fait un usage intensif de System.Reflection et des mappings declaratifs en XML ; et ça lui suffit, parce qu'il n'a pas à se préoccuper de s'intégrer facilement dans un designer visuel de l'EDI hôte ; la durée de vie d'NHibernate c'est seulement le "run time" de l'appli (en tout cas, dans 99% des usages qu'on fait de lui).
en revanche, EF, comme WCF, WPF, WF, ont besoin des custom attributs "marqueurs" pas seulement au run time (pour serialization des graphes d'objets ou autres) mais aussi au moment du design time et du compile time ; au sens strict, les custom attributs ne sont pas absoluments necessaires quand on veut developper de tels frameworks, mais ils sont tres pratiques (car intégrés au langage C# et son compilateur) et "découvrables" par l'EDI visuel au moment ... du design time ou compile time, justement.
(rappelez vous que meme quand vous ne faites que taper du code dans l'editeur C# de VS, ou que vous utilisez un designer, visual studio fait souvent des compilations "en temps reel" a notre insu, ne serait ce que pour les besoins de l'intelli sense ; c'est là que les custom attributes, compilés en catimini rende un IDE visuel comme studio aussi utilisable ; s'il devait se reposer uniquement sur System.Reflection, réputé couteux en tant d'execution CPU, quand bcp de types doivent etre inspectés, visual studio serait... plus lent à reagir en terme d'interactivité ; enfin, de toute façon, les custom attributes rendent l'ecriture des designers / serializers bcp plus faciles, d'une maniere generale ; c'etait un objectif de conception majeur de C# dès sa version 1.0)
"CQFD" ;)
Je me permet de commenter un peu ta réponse, vu que je travaille actuellement sur un projet basé sur EF :
* EF n'est pas encore un paquebot de luxe. Si la version actuelle est fonctionnelle, l'interface graphique pour gérer son modèle mérite encore du travail.
Vivement la prochaine version ;)
* EF ne nécessite pas l'utilisation d'attributs.
Pour être précis : si attributs il y a, ils sont placés tout seuls dans les classes générées par EF. Le développeur ne les voit jamais.
Le principe de base de EF c'est que le développeur créé un modèle (de mapping) qui s'appuie sur sa source de donnée, et EF s'occupe de créer des classes partielles qui contiendront la logique de persistance. du coup le code du développeur est très épuré puisque qu'il ne contient que le code du développeur et rien d'autre (pas même un attribut).
C'est effectivement une différence majeure avec NHibernate qui travaille essentiellement au runtime (comme le disait très justement lysiandad)
* Un inconvénient majeur (à mon sens) de cette classe générée, c'est qu'on ne peut pas lui définir d'héritage. Elle hérité déjà d'une classe du framework EF, ce lui fait perdre un peu de souplesse.
ex : pour implémenter son propre MembershipUser, on doit hériter de MembershipUser donc il faudra coder 2 classes pour le mapper avec sa base en utilisant EF.
* En revanche l'un des développeurs principaux de l'Entity Framework a annoncé qu'ils travaillaient ferme à ne plus forcer cet héritage. On parle de Persistence ignorance.
Detail ici si vous lisez l'anglais
* LinQ + EF ça roxx ! Ca c'est indéniable. Une fois passé la frustration de ne pas pouvoir faire d'héritage maison sur ses ptites entités, et après avoir galéré sur l'interface graphique, ce n'est plus que du bonheur.
Ma seule interrogation, c'est pour le travail en équipe. Je n'ai pas encore testé ça sur un projet multi-développeurs, à voir.
Ah, merci pour ces précisions :) et j'avoue que j'avais manqué de voir cette prise de conscience (cf votre lien) de l'équipe EF pour aller vers une implémentation EF dans l'esprit "POCO", plutôt que implémentation avec classes de base "intrusives".
Je pense en effet que c'est une bonne nouvelle, la bonne approche, même si, afin d'éviter le hors sujet, je ne vais donner ici mes arguments dans cette direction, que je ne fais que partager avec bcp d'autres par ailleurs de toute façon (il suffit de "googler" pas plus de 2 minutes sur les nombreux articles en faveur de l'approche POCO (C#) ou POJO (Java) sur les strategies de conception des frameworks).
Ok, vu : donc, effectivement les custom attributes EF sont transparents pour le design time (puisque générés dans du code que le développeur n'ira pas retoucher à priori), ce qui confirme qu'ils sont surtout là pour faciliter le boulot au run time d'EF, très probablement pour des raisons de performances d'execution de la serialization, des lookups, etc.
Pour ce qui est de l'impact sur les processus de travaille en equipe, je vous rejoins entierement : il y aura probablement des etudes interessantes a faire (a posteriori) sur les travers insoupçonnés (en clair, les "frottements" générés dans les plannings projets, pendant le developpement d'applis pas du tout triviales / importantes utilisant EF, genre... à partir de plus de 100 et quelques classes "feuilles" liées au métier) ... ce qu'on ne manquera pas de faire tot ou tard, je suppose.
En guise d'epilogue a mes precisions et les votres, on (je, en tout cas) ne repetera jamais assez le "genie" si on peut dire d'Anders et les autres chez MS d'avoir une fois pour toute introduit au sein du runtime (CLR) et de la syntaxe du langage source (C#, VB.NET, etc) ces metadata, elles-memes orientees objet (puisque classes a part entiere) qui ont donné lieu à tant de cas d'utilisation differents. Sur ce coup la, ils ont vraiment vu juste... meme Java a fini par s'y mettre... ;) (euh... pas de polemique, svp ;) )
Bon certes, le concept de metadata n'etait clairement pas nouveau en informatique logicielle, y compris en 99/2000 quand MS preparait son bebe codenamed "NGWS" a l'epoque (le ".NET" a venir en release), mais, sauf erreur, c'est la premiere fois que des concepteurs et developpeurs d'un runtime oriente objet, et ceux des langages de la meme veine, et ceux des compilateurs de ces derniers, ont eu l'idée et ont assumé jusqu'au bout (y compris dans les 1eres specs) ce choix.
Presque 10 ans après, ma foi, je suis tenté de dire que c'était le bon pari, non ? :)
Citation:
Envoyé par Mose
En fait, ce n'est pas tout à fait vrai... il n'y a aucune obligation d'hériter de EntityObject, la seule contrainte est d'implémenter les interfaces IEntityWithKey, IEntityWithChangeTracker et IEntityWithRelationships. Par contre, si on utilise le designer, les classes générées héritent de EntityObject... Donc, pour ne pas avoir cette contrainte d'héritage, on peut toujours faire le mapping à la main, sans le designer, mais ça doit être assez casse-bonbons :aie:Citation:
Envoyé par Mose
Oui, très certainement pénible, pour le moins, au-delà de "quelques" classes !Citation:
Envoyé par tomlev
Je sais pas pour vous, mais ma relation avec les "designers" dans les EDIs est largement manichéenne :
a) trop "magiques" et mal conçus en ergonomie... on a envie que d'une chose : pouvoir s'en débarrasser facilement, pour mettre les mains dans le "cambouis" du code, si nécessaire... et si le code qu'ils génèrent est alors "imbuvable", alors on se met à les détester ;
b) mais quand ils sont bien ergonomiques et "compréhensibles" dans le boulot qu'ils nous épargne, alors on ne peut plus s'en passer, et à moins de vouloir vraiment faire du reverse engineering de curiosité, on se fiche presque éperdument comment ils font ce sale boulot... ;)
Avec Delphi depuis 1995, je dois dire que j'ai largement apprécie que ce sympathique outil tombe dans le cas (b)... Pour ce qui fut de VS.NET 2002/2003, ce fut également très proche de (b), mais sensiblement moins qu'avec le bon vieux Delphi... Heureusement, VS.NET 2005 et 2008 font maintenant aussi bien, à mon goût (même si c'est assez différent techniquement entre Delphi et MS VS, comme on sait).
Pour (a), j'ai bien eu des experiences malheureuses, mais pas la peine de citer de noms d'outils/d'editeurs... bah, pas envie de lancer une polemique qui est rarement constructive... ;)
Plus qu'à espérer donc que ça continuera avec EF dans l'EDI MS Visual Studio et ailleurs, puisqu'il semble qu'il a de bonne chance de s'imposer au final...
Merci donc pour vos infos via ce fil en tout cas, je réalise qu'il va falloir que je retourne voir régulièrement où EF en est, effectivement. :)
Que tu prennes l'un ou l'autre tu seras confronté aux mêmes problèmatiques.
La différence et que tu trouveras beaucoup plus de pattern et d'expérience sur Nhib et c'est normal vu son expérience que sur EF.
On aime où on aime pas, mais Linq, même si une fois de plus on va encore me dire que je casse EF n'a rien à voir avec EF.
Ils ont des différences significatives sur :
Les mappings sont plus complexes sur EF (3 contre un), et le designer n'apporte pas suffisamment de souplesse --> C'est un peu un faux débat parce que finalement, c'est plus de la productivité que de la qualité d'ORM.
L'objectcontext fait tout (difficile d'appréhender le stateless en EF), alors que nhib a une notion dissociée de factory et de session.
Dans le cas 1, tu as des problèmes de partage et d'attach, dans le cas deux tu as des problèmes d'état de session. C'est plus une question de philosophie et goût.
Nhibernate a deux niveau de cache distinct et disposant de beaucoup de connecteurs, probablement qu'EF en aura autant d'ici peu
Le track changing n'est pas facile sous EF, puisqu'il s'agit d'avantage d'un framework que d'un outillage, sous nhibernate, c'est plus simple, mais ça passe par des proxys transparents castle ce qui n'est pas toujours évident
Linq est plus simple que HSQL et plus maintenable mais ne gére pas du tout les stratégies de fetch ( tu gagnes en productivité et lisibilité, mais tu peux perdre en transparence et en performance)
Il manque des connecteurs de DB dans EF (ça arrive aussi)
La question des classes simples, c'est un débat de chapelles : Ca permet plutot de faire un design entité "sans contraintes", mais les proxys transparents ça a ses inconvénients aussi.
Je doute qu'un jour on puisse trouver un user group qui réponde autant et aussi bien que l'équipe de Fabio Maulo sur le groupe Nh-Users.
Ce n'est pas là une critique d'EF, mais la réalité entre choisir une techno propriétaire et une techno open source.
De même si EF bug, difficile de brancher les sources pour trouver l'endroit qui fait mal et mieux comprendre : tu restes dans une logique d'utilisateur.
D'un point de vue purement professionnel, EF est un excellent outil pour faire du client serveur et du RAD.
Pour faire des architectures logicielles plus évoluée, il reste encore trop jeune et trop de plomberie à faire.
Voilà. Je te conseillerai surtout de regarder d'autres ORM, car les deux outils (EF et Nhib) ont des réponses très spécifiques, et d'autres outils ont des réponses différentes et intéressantes (EUSS Evaluant et LLBL par ex.)
Hmm... Merci pour le conseil, tout cela a bien du sens.Citation:
Envoyé par B.AF
Mais, à vrai dire (amha), il y a même une 3ème (ou est une 4ème, etc?) approche alternative à l'ORM "éprouvé, designer-agnostic" (genre, NHib, oui, qui est une implementation solide, appuyée/supportée par une communauté importante) et au framework "multi-purpose" (genre, EF, comme MS tente de le faire)...
... ce que j'appelle "DSL * .NET"
Mais je ne vais pas ici continuer en dérivant dans ce qui serait pour le coup carrément hors sujet ; cela fera bien l'objet d'autres discussions "ailleurs" sans aucun doute ;)
La preuve par neuf que tu n'es pas tant hors sujet :
NBusiness
Et je l'ai utilisé, c'est très bien fait.
Là, aucune objectivité, je trouve l'idée géniale, et en plus par défaut c'est Linq Enable --> CLR...
Et en plus ,c'est vraiment novateur dans le concept.:D
Et hop, je t'évite le hors sujet !
Wow. Bon, là, je me demande comment j'ai fait pour passer à côté de ça... Shame on me! ... Un très grand "Merci", donc ! Je viens de lire les docs de cette ressource codeplex et je me dis maintenant que je devrais définitivement me rapprocher d'eux, rapport à leurs futurs objectifs et l'état actuel de mes propres recherches persos et prototypes...Citation:
Envoyé par B.AF
Dans leur meta modèle de DSL textuel (leur "E#" ), je vois en effet qu'ils ont adressé des problématiques que je n'adresse pas encore... et inversement ! Et idem pour la partie génération de code...
Ex.ce.ll.ent ! Merci pour l'info ! :)
Tu peux aussi regarder ça :
ActiveWriter
Sculpture
Quant à NHibernate, voilà quelques ressources dessus qui te permettront de mieux évaluer le produit :
Burrow - Converstation + Exemple
Validation
Tagging sans mapping
Fluent Nhib
Sur EF :
EF + Ntiers
Contrib EF
Je crois que si tu fais le tour de tout ça, il ne te reste quà regarder Ninjectet spring pour avoir quelques certitudes sur la démarche à adopter et réduire le coût de changement de ton ORM.
Good luck!:aie:
J'allaius oublier NORMA aussi !
Merry christmas
Ca va vraiment t'aider ça dans le concept.
Merci à nouveau, mais mes recherches actuelles portent moins sur comment implémenter et assumer le choix d'une solution ORM à travers l'arsenal de tooling utilisé par les architectes (en l'espèce, surtout via l'EDI MS VS) que de rendre le(s) DSL(s) métiers ou middleware définis et implémenté par ces architectes (à nouveau, dans leur tooling préféré) indépendants de ce choix.Citation:
Envoyé par B.AF
Mon point, dans son aspect le plus fort, et je terminerai là dessus (je crois? ...), c'est que personne ne doute de la grande largeur de l'éventail de solutions (NHib, NHib + aspects/injection, NHib+attributs, EF, etc) offertes aux architectes pour mettre en oeuvre concretement et assez rapidement des software factories dans le cadre du développement de projets de grande envergure.
Mais... pour ce que j'en ai vu jusque là... le couplage technique/technologique entre les toolings qu'ils peuvent inventer/organiser/mettre en oeuvre pour leurs développeurs et ces solutions reste... très fort (sans parler de l'adhérence à une certaine version de C# ou de la CLR).
Idéalement, je voudrais m'orienter vers une stratégie de mise en oeuvre de ces solutions ORM (et l'ORM n'est qu'un composant, mais il y a aussi les moteurs de regles, les caches, etc), voire de combiner facilement leur techniques, quand elles sont orthogonales, en aidant à la definition du tooling, et au moins sans remettre en cause complètement les patterns d'architecture que je sais adaptés à mon(nos) domaine(s), et/ou la partie génération de code, et/ou le design visuel de couches (présentation/métier/services/persistance, pour ne citer que les plus importants).
C'est en cela que ta communication à propos de cet NBusiness, dans lequel je vois, au moins, un couplage faible envers le composant ORM (grâce à une approche de génération de code adaptive/agile), comme je l'expérimente moi aussi entre autres, m'a intéressé au plus haut point. :)
Tu es en train de faire le travail qu'ai fait il y a 3 mois environ quand nous avons décidé de travailler sur un nouveau produit.
Malheureusement, NBusiness a de grosses limitations, même si l'esprit y est.
Le couplage faible avec l'ORM est un vrai mirage; du fait que le couplage n'est pas rendu fort par les entités, mais bien par le moteur de persistence.
Globalement, tu finis par écrire des surcouches (bref un framework de framework).
IMHO, le vrai couple lâche entre l'orm et la couche métier/service n'est possible qu'au travers d'un comportement générique qui te borne in fine à produire une implémentation technique pour chaque composant.
Finalement, il s'est révélé plus intéressant de :
A - Développer une persistence sur mesure
Ou
B - Sélectionner l'outil présentant le plus de qualités et le moins de risque d'adhérence.
Sachant que dans la politique d'accès aux données, ta stratégie de services n'est pas neutre.
En plus méfies toi de la génération, comme dit très justement un développeur de mon équipe : le générateur, il génére du code, pas de la logique business.
Et le pire ennemi du développeur dans l'ORM, c'est bien la récursivité et les graphs objets.
Ah, ben au moins, je vois qu'il y a des précédents dans cette volonté que j'ai eue fin 2007, qui n'est donc peut-être pas totalement farfelue. Mais je vois que tu élabores, plus avant... donc, voyons :Citation:
Envoyé par B.AF
Oui et non. Clairement, "oui", car j'aimerais pouvoir considérer dans mon tooling, intégré à VS, l'usage de couches comme WCF, EF, WPF vs Winforms, etc, pour une solution particulière comme des "composants intègres" ( ou "entiers" si vous préferez ) sur lesquels j'applique des "transformations" et/ou je configure des "méta propriétés" via un designer en fonction de patterns d'architectures cibles que l'architecte connait déjà et qu'il a choisis, parce que déjà mis en oeuvre dans des projets anterieurs "faits à la main".Citation:
Envoyé par B.AF
Et c'est aussi, "non", car je ne souhaite pas non plus, en effet, ré-inventer l'eau chaude en les rendant plus génériques qu'ils ne sont déjà. WCF, EF, etc, sont à la fois ouverts et fermés : ouverts car extensibles et customizables dans leur semantique au runtime, et fermés car ce sont aussi des librairies de composants compilées prêtes à emploi "out of the box", au moment du design, dans les cas applicatifs raisonnablement simples, que je continue de croire être les plus courants, en pratique.
[ EDIT ]
Cette propriété d'ouverture-fermeture de ces briques, au runtime comme au design-/compile-time (dans des EDI), est ce que nous appelions tous de nos voeux dès la fin des 80's / debut des 90's quand "tout le monde" pressentait que le paradigme objet etait la voie unificatrice a suivre pour la construction des programmes informatique. Avec Java un peu avant la mi-90's, puis .NET dans la même veine, a la fin 90's/2000, la nécessité d'avoir une concrétisation "objet" juste au dessus de l'OS est devenue réalité. C'était nécessaire mais toujours pas suffisant ; Java et .NET ont un scope certes toujours plus vaste dans les libs fournies "out-of-box" (i.e., resp. par Sun et MS et autres), mais l'existence même de solutions (libs externes) concurrentes pour adresser l'interop, l'ORM, les IHMs, etc, demontre que le scope a un instant T, de ces frameworks "à machines virtuelles" est, par construction, limité, et de toute façon toujours strictement inférieur a tous les besoins de toutes les architectures imaginables. Pourtant, un non informaticien pourrait se dire legitimement (en fait, je l'ai déjà entendu...), puisque c'est technique et non métier : "ah bon ? cette brique, ça vient pas avec .NET de base ?"
Pas le choix alors : l'outil de production (EDI, build, configuration, source control), pour être aussi moderne et utile pour nous que ces Java et autres .NET sur lequel il s'appuie, devra bien tôt ou tard être suffisamment souple pour limiter au moins, à défaut de rendre nulle, la probabilité d'une remarque de tes développeurs, à laquelle je réponds plus bas...
Oui. Ce point a en effet toute mon attention dans ma réflexion actuelle. Pour laquelle je n'ai pas encore de conclusion (ou stratégie) suffisamment claire pour être partagée utilement.Citation:
Envoyé par B.AF
Tout à fait. Mais, à partir de C# 2.0 au moins, avec les classes partielles, sans que tous les problèmes soient résolus evidemment (notamment en matière de génération de code couplée a un design "two-ways", avec vas-et-viens entre design et code généré puis augmenté par le développeur) il nous est tout de même plus facile de maitriser la scission-jointure claire et non-ambigue entre ce qui est code métier (règles, pre/post-conditions, invariants des entités) et code technique (accès à l'ORM, accès à la couche de configuration, etc)Citation:
Envoyé par B.AF
Tout à fait également.Citation:
Envoyé par B.AF
Mais justement, j'ai la faiblesse de croire que si le tooling intégré à l'EDI permet à l'architecte ou aux développeurs expérimentés de "zapper" sensiblement plus facilement entre l'usage de tel ou tel ORM, telle ou telle couche de liaison (.NET remoting, ou WCF, ou COM+ via interop, etc), telle ou telle couche de service (WS ou REST) ce sera précisément autant de temps de gagné qu'ils pourront ré-investir dans l'évaluation des performances des différentes implémentations, sans devoir revoir de fond en comble, par ré-écriture fastidieuse, leurs "toolkits" / "middlewares" / "frameworks maison".
Pour une echelle donnée, un tooling qui permettrait d'effectuer ce genre de tentative / évaluation / validation des briques en quelques jours au lieu de quelques semaines aurait déjà un intérêt énorme en phase d'initiation de projet / prototype / "v0".
J'ai une trop grande expérience de certains projets où tout se passait bien avec les samples, POCs, etc qui utilisaient telle ou telle technologie, telle ou telle librairie, etc, mais où les problèmes ont commencés avec la montée en charge après quelques mois de production et où on s'aperçoit alors qu'il n'y a plus d'argent pour revoir/adapter son architecture parce que trop de code est développé avec un couplage trop fort entre le métier et la technique.
Que se passe-t-il alors ? Le projet meurt, on maintient l'application en production tant bien que mal en développant verrue sur verrue, soit pour corriger les defects, soit pour de nouvelles fonctionnalités qui sont recettées dans la douleur avec des régressions a forte probabilité à chaque cycle, tandis que tout le monde appelle de ses voeux la "nouvelle génération" (dans un an ou deux, en espérant que le concurrent ne va pas se munir d'une informatique plus "performante" d'ici là), une "NG", qui utilisera donc une nouvelle architecture, pour laquelle il faudra tout ré écrire de zéro, et on est partit pour un an ou deux de plus...
L'industrialisation du hardware est faite depuis longtemps maintenant. Si on est vraiment honnête avec soi même, force est de constater que nous en sommes encore loin avec celle du logiciel, et même si c'est lié, cela n'est pas seulement dû à l'échec relatif et objectif de la plupart des efforts de standardisation de grande envergure (sauf bien sur pour quelques belles reussites, peu nombreuses, comme XML ou XSLT) malgré des comités de normalisation qui travaillent sur le long terme... dans les deux sens du terme : longtemps avant de "sortir" les standards, longtemps avant que tout le monde soit "compliant".
Savoir ce qu'on veut et dans quels délais est le premier pré-requis. Le second étant de se munir de tous les outils nécessaires et suffisants (plateforme, langages, outils, méthodes) pour assister et/ou encadrer les humains liés de près ou de loin à la production du soft, dans leur volonté de respecter ces délais, en plus des spécifications.
Mon sentiment est que dans notre domaine, on passe souvent --mais pas tout le temps dieu merci, et de moins en moins a vrai dire, surtout depuis Java puis .NET-- "nous" passons encore trop de temps, donc, en batailles "de chapelle" / "religieuses" a propos des langages, plateformes, librairies, patterns, notations, standards, etc dont on discute l'usage et la mise en oeuvre (quand ce n'est pas la pertinence), ce qui est autant de temps que l'on gâche au lieu de concentrer son effort sur des outils concrets pour assumer nos choix mais également nos changements d'avis concernant l'architecture, les technologies, et les environnements. Je pense que c'est un travers humain, qui n'a rien avoir ni avec la technique, la motivation, ou les compétences.
Cependant, accepter et prendre en compte ce travers, précisément, pour permettre a l'outil d'etre suffisamment souple envers les velleitudes des "girouettes" humaines, est amha une piste intéressante à explorer, dans la mesure où le niveau d'abstraction et de complexité des architectures ne fait que croitre et ce n'est pas près de s'arreter (tant les "non informaticiens" / les gens du marketng sont prompts a s'imaginer que c'est toujours plus facile, puisque "eh, le concurrent X l'a déjà mis en ligne, lui !", le "YAKA !" syndrome, même si personne ne sait rien de la qualité/robustesse du code du fameux concurrent, etc), pour des applications toujours plus riches et qui se veulent toujours plus interoperables.
Euh, pardon pour la longueur. Je dois vraiment m'arreter là maintenant. :oops:
C'est ce qu'a essayé de faire l'équipe de sculpture globalement ou des outils comme tiers developper.
Ils fournissent des plugins de génération qui permettent de créer des composants distinct en fonction des couches qu'ils appellent.
Disons simplement que le pire de la POO pour moi, et l'ORM en est le plus représentatif c'est que cela s'est démocratisé (au sens adoption massive) en même temps que ce sont développées les fonctions que je nomme "para informatique", à savoir la MOA, le QA, le project management.
Or la POO pour être correctement exploitée doit avant tout passé par une responsabilisation du développeur.
Le tooling est accessoire, puisque finalement, il devient une étape naturelle : une fois que les taches systèmatiques et dont l'utilisation répond à un pattern approuvé alors elles se doivent d'être systèmatisées.
Souvent je lis des articles sur le concept d'architecture d'applications, comme tout, l'architecture logicielle n'est pas une matiére abstraite. Même finalement, elle ne dépend que d'une chose : le progiciel.
Or la définition d'un progiciel ne dépend que d'une chose : la connaissance du métier qu'il adresse.
Or l'ORM est typiquement l'outil qui est à contre usage :
On devrait partir d'un DD qui persiste, surtout aujourd'hui avec la possibilité de faire des classes partielles, l4ESB WCF par exemple qui pemret de se poser la question a posteriori de la distribution de services.
Mais non : tout le monde fait des tables, et fait un mapping en générant du code.
Bien souvent, les tables sont mal pensées (représentation relationnelle) par rapport au model objet, et je ne parle même pas des relations, des clefs, des indexes.
Et donc, quoi que tu veuilles faire, aucun ORM n'a la possibilité d'inspecter ton schéma pour vérifier si dans ta logique business ca fait du sens de limiter le graph à 2 en profondeur.
Enfin, grand sujet, mais là on va finir par se faire taper sur les doigts!!!!:aie::mouarf: