Salut
Que conseilleriez vous comme OR Mapper gratuit ?
Version imprimable
Salut
Que conseilleriez vous comme OR Mapper gratuit ?
Nhibernate
Connais ... un peu "complique" non ? ;);)Citation:
Envoyé par oyigit
La première fois c'est peut être pas évident, mais ça reste largement accessible. En plus y'a pas mal de documentation sur le Web, et l'équivalent en JAVA existe. Et pour finir, ça doit être certainement l'un des outils de mapping objet relationnel les plus répandu...
La gratuité est vraiment une nécessité absolue?
Pour des trucs perso oui ...
sinon je suis egalement currieux sur les or payant .... :mrgreen:
J'utilise aussi nhibernate et j'en suis assez satisfait.
Je regrette que l'on ne puisse pas utiliser directement des collections BindingList<T>. Il faut faire sa propre implémentation, c'est faisable mais c'est un peu galère...
J'attends de voir ce que donnera linq to entities... :P
Sinon si tu veux du simple(iste) il y a Castle ActiveRecord, il s'agit d'une surcouche de nhibernate qui permet de faire des mapping de maniere vraiment aisé (une approche dans le style de ruby on rail)
voici le site : http://www.castleproject.org/
Up ! :aie:
Tu t'es décidé à payer pour une solution commerciale entre temps?
Faut voir ... eventuellement ... :lol:
Dans ce cas, laisse-moi t'assurer que cet outil est l'une des plus grosses merveilles que le monde dotnet a à t'offir.
Personnellement je trouve qu'il est des kilomètres devant tout ce qui se fait ailleurs.
http://www.llblgen.com/defaultgeneric.aspx
As tu regardé du côté d'Entity Framework ?
Il faut connaitre cette technos, car c'est la solution actuel et future proposé par MS, quitte par la suite faire un choix différent ... La version 2 est prévu pour la fin de l'année ...
ça ne supporte toujours que SQL Server ?Citation:
As tu regardé du côté d'Entity Framework ?
Ah non, on trouve actuellement des providers pour toutes les bases des grands acteurs du marché (DB2, Oracle, PostgreSQL, MySql ...)Citation:
Envoyé par Papy214
Pourquoi ?Citation:
Dans ce cas, laisse-moi t'assurer que cet outil est l'une des plus grosses merveilles que le monde dotnet a à t'offir.
Personnellement je trouve qu'il est des kilomètres devant tout ce qui se fait ailleurs.
1) Ca s'appuie sur du code généré, pas de reflection
2) Tu formes des requêtes à partir de code c# avec autocomplétion et vérification à la compilation. Des requêtes de n'importe quelle compexité (aggrégat, sous-requêtes dans where, requête corréléé etc...). Pas de pseudo-SQL façon hibernate.
Donc 100% de ton code est checké en compile time.
3) Toutes les entités générées disposent de leur propre algo de sérialisation qui est 3/4 fois plus rapide que le standard. Idéal pour le remoting.
4) Support des requêtes linq, des units of work, et possibilités exhaustives de gestion de transaction.
5) Tu as le support des développeurs de l'outil en personne sur le forum, ils répondent dans les 3 heures.
Et encore, je mentionne que le minimum, y'a aussi de l'injection de dépendance, de la sécurité... etc...
Je devrais essayer...
mais quand tu dis que ça génère du code, tu veux dire que les entités métiers sont générées en fonction de ce que tu as en base de données (un peu à la manière Linq to entities) ou alors il crée du code "intermédiaire" entre les classes métiers existante et la bdd? (ce qui me plairait beaucoup plus...)
Mouai.....C'est pas totalement vrai non plus.Citation:
Envoyé par _skip
C'est un bon soft, très bon même, mais Frans a les idée trop arrêtées sur plein de choses. Nous on l'a acheté et on a arrêté parce que sur certains sujets, impossible d'avoir satisfaction.
Enfin bon, c'est le principe d'acheter le composant : A moins d'avoir les sources (et là souvent ils ne garantissent pas le résultat), un composant open source n'est pas biaisé par le discours marketing.
En gros avec WCF, on a souffert mais BIG TIME, et le moteur de requête est horrible. Alors oui il y a le support Linq depuis la derniére version, mais c'est pareil, en distribué, passé l'aspect sex du langage, on se heurte comme avec les autres aux questions de graph.
pour obtenir :Citation:
ResultsetFields fields = new ResultsetFields(2);
fields.DefineField(CustomerFields.ContactName, 0);
fields.DefineField(new EntityField2("Total",
(OrderDetailsFields.Quantity * OrderDetailsFields.UnitPrice), AggregateFunction.Sum), 1);
RelationPredicateBucket filter = new RelationPredicateBucket();
filter.Relations.Add(CustomerEntity.Relations.OrderEntityUsingCustomerId);
filter.Relations.Add(OrderEntity.Relations.OrderDetailsEntityUsingOrderId);
GroupByCollection groupBy = new GroupByCollection();
groupBy.Add(fields[0]);
DataTable table = new DataTable();
using(DataAccessAdapter adapter = new DataAccessAdapter())
{
adapter.FetchTypedList(fields, table, filter, 0, null, true, groupBy);
}
[QUOTE}
SELECT c.contactname, SUM(quantity * unitprice) AS TotalOrders
FROM customers c INNER JOIN orders o
ON c.customerid = o.customerid
INNER JOIN [ORDER details] od
ON o.orderid = od.orderid
GROUP BY c.contactname
[/QUOTE]
Je suis d'accord, le moteur de requêtes est super pratique...
Ton problème de fond est peut être plutôt que si le principe de Nhib, donc d'hibernate, donc fondamentalement du principe d'ORM (bah oui quand même), c'est que peut être un ORM n'est pas l'outil que tu cherches.
C'est pas un discours commercial que je recrache mais une bonne expérience que j'ai faite.
On a développé durant 1 an un projet multi-site utilisant le remoting .net avec llblgen et devexpress le tout sur postgresql. Franchement ça c'est super bien passé. Surtout que les modifications dans la base de données étaient hyper fréquentes.
On se mettait d'accord sur les nouvelles tables et 20 minutes après on était en train d'insérer des données dedans.
Notre couche client demandait les entités au serveur en passant les filtres en paramètre, c'était très performant et très convenable à coder.
Si on avait du se mettre à introduire des strings SQL ou HQL ou autre partout je pense qu'on s'en serait difficilement sorti. Alors que là, pouvoir compiler le code était déjà une quasi-certitude certitude de la non-régression des couches inférieures.
Quand je vois d'autres produits ou tout passe par de la reflexion et des fichiers XML, ou l'on doit écrire des pseudo-requêtes en chaînes de caractères qui doivent être parsées, mappées, puis transformées en SQL je me dis que finalement ce choix se défend quand même.
C'est vrai qu'il existe des alternatives open source, mais faut aussi considérer qu'on n'a pas forcément plus de garantie.
Pour ton projet tu as peut être pas le temps d'attendre sur le bon vouloir d'une communauté si tu rencontres un problème ou un bug. Quant au fait que tu puisses disposer du code... Ben est-ce que ton but c'est de passer tu temps sur ton projet ou de le passer à adapter et débugger un ORM ?
Nous avons acheté devexpress dans sa formule avec le code source, la vérité est qu'on n'a pas ouvert une seule fois ce code parce que nous ne sommes pas des développeurs de composants.
C'est quand même sympa de pouvoir s'appuyer sur un produit éprouvé qui fournit plein de fonctionnalités testées "out of the box" et pour lequel tu as un support très actif de la part du développeur (même si c'est vrai qu'il se montre légèrement borné par moment).
Notre but était de ne pas se casser la tête sur notre couche d'accès au données et de pouvoir s'affranchir de toute la complexité et la difficulté de maintenance qu'elle engendre, et on a largement eu ce qu'on a demandé.
J'oserai presque dire qu'entre vs2008, devexpress, llblgen et resharper on était aussi productif qu'avec un l4g.
@maa : ça te génère les entités et les composants pour tout ton requêtage. Par contre ça ne crée pas de façades si c'est ce à quoi tu penses.
DevExpress et ReSharper je suis d'accord avec toi.
Encore que DevExpress en mode unbound, on a regardé le source pour les séquences de paint.
LLBL est très bon, mais je crois aussi que tu ne vois que ça, tu as dit des trucs énormes :
Faudrait peut être que tu te penches sur ICriteria, c'est exactement ce que ça fait :Citation:
2) Tu formes des requêtes à partir de code c# avec autocomplétion et vérification à la compilation. Des requêtes de n'importe quelle compexité (aggrégat, sous-requêtes dans where, requête corréléé etc...). Pas de pseudo-SQL façon hibernate.
Donc 100% de ton code est checké en compile time.
En plus pour les deux, tout est contrôlé en compil c'est faux, puisque le nom des fields pour les 2 produits reste en string.Code:
2
3
4
Donc si je lis ce que tu as dis, c'est juste qu'il y a un outil dont vous savez vous servir et pas l'autre.
Mais tu peux demander à n'importe lequel de mes développeurs quel mode de requête il préfére, ils ont tous utilisé les deux longtemps.
C'est pareil, c'est une vision du produit qui se borne à un tutorial grand débutant fait par un stagiaire. Si tu avais bossé sur un mapping très complexe, il y a longtemps que tu aurais modéré ou oublié de faire ce genre de remarque.Code:
2Quand je vois d'autres produits ou tout passe par de la reflexion et des fichiers XML, ou l'on doit écrire des pseudo-requêtes en chaînes de caractères qui doivent être parsées, mappées, puis transformées en SQL je me dis que finalement ce choix se défend quand même.
Le modèle de mapping de LLBL est propriétaire et imbuvable.
Entity Framework utilise des mappings
Nhibernate utilise des mappings ET une interface fluent (attributs de propriétés)
Donc tes avis sur le sujet sont très immatures, prouvent que tu n'as pas du tout évalué les solutions et que ton avis sur LLBL est un parti pris.
D'ailleurs je pense que même Frans, le concepteur de LLBL te dirait que tu as dit énormmément de connerie sur Nhibernate vu qu'il s'intéresse lui-même à NHibernate.
C'est pas un ORM dont tu as besoin, c'est d'un mapper.Citation:
Surtout que les modifications dans la base de données étaient hyper fréquentes.
On se mettait d'accord sur les nouvelles tables et 20 minutes après on était en train d'insérer des données dedans.
Moi j'ai besoin d'un ORM au sens pro, pas au sens, "je veux pas faire de SQL".
Tu parles de performance, tu ne sais même pas qu'il est possible nativement de brancher 6 moteurs de cache distribué dans Nhibernate et de spécifier dans le mapping la façon dont nh doit les gérer.
Tu parles de support actif, as-tu déjà posé une question sur le user-group nh ? Sans rien payer, tu as une réponse des dévelopeurs du produit dans la 1/2 heure.
Quand tu parles de réflection, tu ne comprends pas plus ton sujet, vu que LLBL s'en sert aussi.(je suppose qu'il n'est plus utile de parler de reflector ou de chose comme ça....).
Et que la réflection dont tu parles dans Nh, c'est de l'émission de IL. (Tu sais emit...). Qu'il y a 3 modes pour garantir les compatibilités avec les frameworks.
Enfin bref, tu parles et tu dénigres le travail d'excellents développeurs, et pire, parce que
1 - tu n'as pas sur t'en servir
2 - tu ne t'en ais même peut être pas servi
3 - tu n'as pas compris qu'un ORM est utile pour gérer un domain objet et contrôler les graph versus la base, et pas de créer les tables puis de générer du code.
4 - tu cherches un outil qui te permet d'oublier de penser, c'est bien, mais autant que je me rappelle, LLBL et NHibernate sont très mauvais pour comprendre à la place d'un développeur les dépendances fonctionnelles dans le graph objet. Ce qui fait cette liaison s'appelle un mapping (quelle que soit sa matérialisation d'ailleurs.). Vouloir utiliser un ORM dont tu ne maitrise pas le comportement au chargement du graph objet, c'est une grave erreur de jugement et de compréhension.
Et comme tu l'as remarqué, oui c'est deux produits que je trouve bon, très bon même, dont je connais la plupart des auteurs, et je ne supporte pas de lire une telle liste de connerie à leur sujet.
Parce qu'en plus dans ce que tu dis, tu relègues LLBL au "jouet", qui fait boite noir en aveugle.
Non il le fait en mode wizard, pour les petits joueurs qui font des petits projet (un site naruto quoi).
Mais il peut faire bien plus.
Mais qui te dit que parce je dis du bien de llblgen forcément je sous-entend du mal de nhibernate? Deja celui avec lequel nous avions commencé à la base étaient XPO, que nous avons vite laché.
Puis les fields en llblgen ne sont pas des string mais des EntityField, enfin bon ça sert à rien de discuter avec toi, tu me fais dire ce que j'ai pas dit.
Puis il existe une API de cache pour llblgen, tout comme il est possible de contrôler le chargement des graphes d'objets...
Ca aurait pu être vachement intéressant de causer de ce genre de chose, mais pas de cette façon, pas dans cet esprit. C'est pas une flamewar de technologie.
Si tu penses que nos projets étaient de petites conneries, ben grâce à elles on a bien gagné des sous et bien mangé, je regrette vraiment que tu prennes ça sur ce ton.
Ce qui est sûr c'est que j'ai posté dans le but de poser un témoignage sur un framework qui m'a donné d'excellents résultats, si ça te gêne je m'en fous.
_skip, ton témoignage m'intéresse. Je ne suis pas un pro des ORM et je ne connais pas très bien leur fonctionnement interne. Quand tu parles de façades, tu fais référence à ça: http://www.dofactory.com/Patterns/PatternFacade.aspx ? Ou c'est carrément autre chose ?
J'utilise Nhibernate et ce que je trouve pratique est que tu peux faire les classes indépendamment de la bdd, en utilisant les propriétés et les types que tu veux. A la limite tu as une application existante, une bdd existante tu peux quasiment sans modification implémenter nhibernate.
En revanche la création de fichiers de mapping est pénible et pour ma part je dois souvent exécuter plusieurs fois le projet pour éliminer les erreurs qu'il contient. J'aurais aimé avoir un outils pour générer graphiquement les fichiers de mapping, ou du moins pour produire une première ébauche... mais je n'ai rien trouvé sur le web. :(
Il est vrai que l'utilisation des requêtes linq serait un aussi un plus, mais il y a un projet linq to nhibernate. Je ne l'ai pas encore testé, mais j'espère que ce projet va prendre de l'ampleur.
Sinon j'ai regardé un peu devexpress que je ne connaissais pas. Ca à l'air d'être un paquet d'outils en tout genre. Mais quels avantages principaux y vois-tu pour la productivité ?
B.AF :
Je me suis mis à NHibernate il y a quelques mois, en me basant sur l'expérience java d'un collègue qui ne disait que bien de hibernate.
J'avoue que c'est un super outil. Il ne lui manque qu'une seule chose, c'est un manuel d'utilisation bien foutu. Parce que j'ai vraiment eu du mal à intégrer ce truc là, malgré plusieurs années de programmation à mon actif. Et je n'utilise qu'une toute petite partie de nhibernate, faute d'avoir pigé comment aller plus loin. Si tu regardais mon code, tu seerais sans doute éffaré :) . Tu parles de cache à paramétrer, il faudra que je cherche où ça se trouve ;-)
J'apprécie tout particulièrement les ICriteria qui permettent de faire des requètes complexes très facilement. Je ne suis pas allé dans le détail mais j'ai tout de même lu qu les performances sont parfois pas terribles. Est-ce vrai ? Pour l'instant, l'application qui l'utilise n'a que très peu de données et je ne peux pas juger.
maa :
Il y a
http://www.mygenerationsoftware.com/portal/default.aspx
et celui-là dont je n'avais pas retrouvé le nom plus tôt :D
http://www.nconstruct.com/App/NConst...aspx?PageId=12
très intéressant.
Tu les as testés. Lequel préfères-tu ?
C'est un facile de critiquer sans fondement.Citation:
Envoyé par _skip
Si la discussion est inintéressante, c'est parce que tu ne comprends pas la technologie dont tu parles, et tu te bornes à des fonctionnalités triviales.
Je ne fais pas le "flameware" d'une techno ou d'une autre, je respecte et suffisamment frans et suffisamment le travail qu'ils ont tous fourni pour ne pas laisser dire une telle tétrachiée d'inepties.
Tu n'as abordé AUCUN des points qui justifient l'ORM.
Juste de points ridicules comme un designer, ou autre artefacts qui n'ont d'utilité que dans des développements RAD, mais aucune valeur ajoutée sur l'arcitecture ou le couplage.
C'est effectivement un sujet très intéressant à condition d'en parler avec des gens qui le maitrise.
Je me fous qu'on pense que je fais du pro-technologie, je ne supporte pas
qu'on dénigre le travail d'EXCELLENTS développeur par fainéantise.
Oh...Il y a pas un wizard avec 3 boiboites et faut que je comprenne comment mes objets vont persister...Ah bah l'outil est pas bien alors.
Ah, et puis je peux pas écrire de requêtes mal faites, comme ça si je les teste pas avant et que je veux pas le faire, le compilo va me le dire.
C'est en gros la substance premiére de ton raisonnement.
Autant dire qu'effectivement, et ça c'est un vrai jugement de valeur, je doute fondamentalement que tu sois capable avec ça de porter un jugement de fonds sur la valeur de l'outil.
Les performances d'un ORM ne sont pas dues à l'ORM directement, mais à la façon dont on construit le graph objet et de comprendre comment les ORM (là l'API n'importe laquelle) gère son identity map.Citation:
Envoyé par Papy214
Dans le cas de Nh, elle est composée de deux éléments :
La SessionFactory qui contient les informations de mapping et qui est la "productrice" de domain
La Session qui correspond à :
- soit un Unit Of Work, dans lequelle existe un cache dit de niveau stockant l'ensemble des entités chargées.
- soit une session "Stateless" qui se "contente" de faire ce qu'on lui dit sans appliquer de politique de changement.
Tous les produits ont une logique dite de chargement
- Lazy
Un objet est initialisé avec tout ou partie de ses relations exitentes
Certains outils (EF par ex) utilises un lazy explicite
--> EF n'a pas de unit of work, donc il existe toujours un context où trouver les données
D'autres (Nh) utilises un lazy implicite
--> La session étant un unit of work en elle même, un proxy se substitue à la relation, son appel déclenchant le chargement
Chaque mode a autant d'avantage que d'inconvénients.
Dans le cas 1, il y a une maitrise à posteriori du chargement, donc un graph inutilement chargé potentiellement, dans le second, il y a un risque d'anémie et de "sur sql"
Donc et c'est valable pour TOUS les ORM, si tu prends une table telle que
TOTO {id,name,parent_id}
ou chaque id peut être dépendante d'une autre id;
La plupart des générateurs vont traiter la relation ainsi (graph simplifié)
Imaginon maintenant que 3 éléments existent en base :Code:
2
3
4
5
6
7
8
9
1;Toto1;null
2;Toto2;1
3;Toto3;1
Dans chaque cas, et par défaut, un chargement eager va produire le résultat suivant :
Une instance de Toto contenant :
Les propriétés de Toto; une liste de 2 Totos(Toto2,Toto3)
Toto2 va contenir
Les propriétés de Toto2; une référence vers Toto1 (parent)
Toto3 va contenir
Les propriétés de Toto3; une référence vers Toto1 (parent)
Chaque Toto1 dans Toto2 et Toto3 va véhiculer le premier Toto1.
L'ORM saura juste qu'il a chargé une entité Toto1, donc ne sollicitera pas la base, mais potentiellement, une simple table avec un mapping ORM inapproprié peut provoquer une récursivité monstrueuse
Le contrôle du graph est donc de la stratégie de chargement (si tu prends Nh, tu peux gérer 72 mappings d'une table si tu le souhaites) sont les fondamentaux de l'utilisation correcte d'un ORM.
Si tu ne sais pas précisemment quelles données tu vas charger et quel graphe elles vont générer et sans nécessairement provoquer d'overhead dans la base, tu es dans une situation où l'ORM te dessert.
D'où l'importance vitale pour qui se sert d'un ORM professionnellement d'avoir un moyen standardisé de contrôler l'interaction de l'ORM avec la base.
Ce sont les mapping NH;EF et LLBL (oui LLBL mappe aussi...)
Pourquoi il y a un tel "activisme" des dba contre ses outils ?
Parce que les développeurs s'en servent mal dans la majeure partie de cas pour les raisons ci-dessous.
Donc fut un temps où principalement en Java (le principe d'ORM a vraiment vu le jour grâce à Java) les DBA remontés de listing SQL de 40 pages produits par ses outils; et forcémment, ça n'a pas joué en faveur de ces outils.
Autre point qui est souvent un "bloated controller" c'est la gestion des sessions et de la sécurité. Si chaque ORM expose des transactions ou permet de faire des transactions systèmes, c'est parce qu'encore aujourd'hui en 2009, les ORM sont utilisés commes des mappers.
Donc à contre nature; puisqu'en gros, l'usage moyen que l'on voit et en fait d'écrire des procédures stockées en objet plutôt qu'en SQL.
Donc l'ORM c'est souvent appellé le vietnam de l'informatique pour ceux que le sujet intéresse, c'est compliqué, et quel que soit l'outil, aucun n'est une réponse magique à la gestion de la base.
Dans certains cas ils sont même contre productifs.
Aucun développeur ne devrait utiliser un ORM dans un sujet qu'il n'arriverait pas à traiter en SQL.
Je suis en train de bosser sur un tuto d'architecture distribué basé sur un ORM (NH et EF) pour justement montrer en quoi un défaut dans les fondamentaux d'implémentation d'un ORM peut induire un défaut en chaine dans l'architecture logicielle.
Si tu trouves trivial le fait qu'un maximum de code (notamment les requêtes) soit checkée à la compilation afin d'éviter des régressions lorsque le schéma de la BDD évolue, ben ok...Citation:
Oh...Il y a pas un wizard avec 3 boiboites et faut que je comprenne comment mes objets vont persister...Ah bah l'outil est pas bien alors.
Ah, et puis je peux pas écrire de requêtes mal faites, comme ça si je les teste pas avant et que je veux pas le faire, le compilo va me le dire.
C'est en gros la substance premiére de ton raisonnement.
Et puis oui, la productivité ma foi c'est le critère no 1 là ou je bosse, la vitesse de développement et les coût de maintenance moindre c'est ce qu'on nous demande. Donc forcément, on alterne prototypage et refactoring, les phases de tests sont très très courtes. J'aimerai bien que ce ne soit pas le cas, hélas si.
Ma première réaction en temps normal serait de te dire que ton opinion de moi je m'en tape. Mais d'une certaine façon t'as raison, je ne suis pas Dieu, j'ai fait des choix architecturaux au cours de certains de mes projets qui aujourd'hui me déplaisent fortement mais je suis toujours à la recherche de concepts et d'idées du moment que ces dernières sont compatibles avec les exigences du milieu RAD à flux tendu dans lequel j'évolue.Citation:
Autant dire qu'effectivement, et ça c'est un vrai jugement de valeur, je doute fondamentalement que tu sois capable avec ça de porter un jugement de fonds sur la valeur de l'outil.
Donc si jamais tu veux ouvrir une discussion sans m'attaquer personnellement je suis ton homme, par contre si c'est pour me scier ben on parle d'autre chose.
Oui parce que ça veut dire que les modifications de domaine ne sont pas maitrisées. Autrement dit, cette situation n'arrive que si et seulement si le modèle n'est pas maitrisé parfaitement, ce qui relêve de la conception logicielle (rien à voir avec toi dans l'absolu au fait).Citation:
Envoyé par _skip
Et ces problèmes doivent être surtout levés par des tests unitaires.
Moi non plus je ne suis pas Dieu, j'ai entre autres défauts celui d'être sanguin et passionné par mon job.Citation:
Envoyé par _skip
Voilà.
Quand je donne mon avis, c'est pas toujours diplomatique, soit, mais c'est sans rancune et c'est honnête.
Et moi aussi je me suis trompé dans des choix, j'en regrette certains, j'aurai pu faire mieux aussi si j'avais su.
Mais sur ce sujet là en particulier qui est une vraie patinette géante pour développeur, je trouve très important déjà que tous les développeurs puissent comprendre que l'important c'est que tous les ORM répondent au même pattern et de façon standard.
Ce qui diverge, c'est l'outillage et les extensions (bon parfois le core, mais ça reste très similaire dans le résultat)
Un développeur qui échoue à l'usage d'un ORM n'aura pas plus de chance de réussir avec un autre. Un bel outillage (l'éditeur d'entité de LLBL est excellent par exemple, même si il lui manque un aspect collaboratif) peut induire un développeur en erreur.
Pour comprendre ce genre d'outils, il faut admettre de le faire "a mano" au début. Quand les automatismes sont mis en place, dans ce cas on peut choisir l'outil.
C'est comme tu dis, on a besoin de plus de tests et de plus de temps pour développer. Mais je suis sûr que tu te rends compte à quel point ce genre de chose peut devenir problématique lorsqu'on veut tenir un rythme de livraison très serré tout en s'assurant que chaque livraison amène son lot de nouveautés et sa valeur incrémentale.Citation:
Envoyé par B.AF
Bah tu sais on est sur un forum, forcément il manque la nuance, les malentendus sont vite arrivés autant pour moi. Oublions ça. ;)Citation:
Moi non plus je ne suis pas Dieu, j'ai entre autres défauts celui d'être sanguin et passionné par mon job.
Voilà.
Quand je donne mon avis, c'est pas toujours diplomatique, soit, mais c'est sans rancune et c'est honnête.
Je pense que ça fait partie de ce métier, on est amené à faire des choix sur des choses susceptibles d'évoluer, avec toutes les contraintes de délais imposées (sans forcément vouloir toujours se cacher là derrière ça reste un facteur de poids).Citation:
Et moi aussi je me suis trompé dans des choix, j'en regrette certains, j'aurai pu faire mieux aussi si j'avais su.
Mais être capable de porter un jugement sur son projet fini puis de se rendre compte de ce qui a bien fonctionné et là où ça a pêché, c'est important.
Ca fait un peu cheap talk mais la remise en question est souvent nécessaire.
Je m'autorise à penser que dans la mesure où les délais ont été respectés, que la satisfaction du client est là et que la maintenance n'est pas trop complexe, il faut croire qu'on a pas tout fait faux.Citation:
Un développeur qui échoue à l'usage d'un ORM n'aura pas plus de chance de réussir avec un autre. Un bel outillage (l'éditeur d'entité de LLBL est excellent par exemple, même si il lui manque un aspect collaboratif) peut induire un développeur en erreur.
En revanche, je sais que certains aspects de notre architecture sont très criticables bien qu'en partie défendables, je pense honnêtement que si il existait des solutions miracles dans ce domaine ça se saurait.
Je ne compte pas le nombre de fois où nous avons été tiraillé entre l'envie d'avoir des couches métier et BDD bien séparées et le besoin de pouvoir quasiment micromanager nos chargements de données... Les compromis ont vraiment été difficiles sur certains points, puis l'incertitude du choix architectural aussi.
maa :
A vrai dire, j'ai commencé avec mygeneration mais comme c'était mes tous début avec NHibernate, quand j'ai vu tous les templates proposés, j'ai été un peu perdu.
L'avantage de nconstruct, même en version lite, est sa simplicité d'utilisation. Il a quand même tendance à créer des hbm pas trop light.
Mon expérience s'est donc limité à générer des fichiers lors de ma découverte de NHibernate histoire de voir rapidement à quoi ça pouvait ressembler. J'ai ensuite regardé la doc d'un peu plus près et j'ai repris les fichiers générés pour les adapter à mon cas, en enlevant des choses inutiles, en rajoutant d'autres choses, ce qui m'a permis de comprendre un peu mieux le fonctionnement des fichiers de mappings. Pour les classes C#, il n'y a rien de sorcier.
B.AF :
Tout d'abord, merci de ton explication. Tu sembles connaitre particulièrement le sujet.
J'aurais aimé que tu sois dans le coin quand j'ai découvert NHibernate. :D
Tu parles du lazy loading. Je me suis heurté à ce truc là au début, n'ayant pas construit mon mapping correctement, avec les relations qui allaient bien.
Je me retrouvais souvent avec des objets non chargés qui plantaient sauvagement mon programme.
C'est là que je me dis que, si j'avais pu trouver une doc plus "claire" sur le sujet, j'aurais pu gagner du temps.
Attention, loin de moi l'idée de dénigrer le travail des auteurs de la doc.
C'est un peu comme quand on connait la route pour aller chez soi et qu'on l'explique à des amis qui doivent venir à la maison.
On a tellement l'habitude de rentrer chez soi que ça parait tout simple. ;). Ca l'est souvent moins pour les "étrangers".
Puisque tu es en contact avec les auteurs de nhibernate, je vais me permettre une question:
Il me semblait avoir vu au début des outils en ligne de commande pour générer des hbm et des classes C#.
Impossible de me souvenir où j'avais vu ça. Ais-je révé ?
Enfin, si tu veux garder mon adresse email dans un coin pour me prévenir de la disponibilité du tuto que tu prépares, ça serait sympa.
Question subsidiaire: Que penses-tu de l'idée qui consisterait à demander la création d'une rubrique ORM sur le forum C# ?
bon petit thread ;)
Juste en passant, @ Papy214, pour la doc, je te conseille de jeter un oeil sur le livre NHibernate in Action
http://dotnet.developpez.com/livres/...L9781932394924
Sinon, tu as nhforge.org, qui contient une tonne d'infos sur nhibernate.
Pour revenir sur la question d'origine (un orm gratuit/pas cher pour C#), je plussoies pour NHibernate, si le but est d'utiliser un mappeur objet relationnel, ou peut-etre LightSpeed chez les "pas cher"
Si l'idee est plus d'avoir un mappeur pour faire une relation 1/1 entre les tables et les objets, et eviter de faire du SQL, Subsonic est tres bien et gratuit (et dans le cadre d'une problematique RAD, ca depotte)
Ahhh...bien interesse, la...Citation:
Je suis en train de bosser sur un tuto d'architecture distribué basé sur un ORM (NH et EF) pour justement montrer en quoi un défaut dans les fondamentaux d'implémentation d'un ORM peut induire un défaut en chaine dans l'architecture logicielle.
Avec des sagas et tout et tout ?
Ben oui, par étape quoi; montrer qu'avec le même socle de service, on peut avoir n dal sur n fournissuers, et une distribution en web serv, wcf et remoting, avec un client lambda.
Du quotidien quoi!
Super, si t'as besoin de bêta lecteur ^^Citation:
Envoyé par B.AF
++ :DCitation:
Envoyé par rad_hass
J'ai enfin lu totalement ton article et je vais te dire ce que j'en pense sur le bon thread ... ^^Citation:
Envoyé par pvialatte
Je vous le sortirai au prochain ALT.NET, vu qu'il y a de l'AOP:mrgreen: