Discussion :

[davcha]

Depuis quelques temps, je développe à mes heures perdues un outil de mapping o/r.
Et régulièrement, comme ce soir, je me demande si cela vaut vraiment la peine.

Je teste de temps en temps les possibilités de "concurrents", comme Linq-to-SQL ou EF, dernièrement. Et je ne suis jamais réellement convaincu. Il y a toujours quelque chose qui manque. D'un côté les relations many-to-many, l'héritage de multiples tables, de l'autre la génération de la base de donnée, les relations 1-1 reflexives, et j'en passe...
De même chez NHibernate, même s'ils sont parvenus à quelque chose de vraiment sympathique, je trouve leur outil bien lourd, pas simple à utiliser et donc difficile à maintenir.

Cependant, il y a encore de gens qui travaillent à améliorer leurs produits, je pense à EF2 ici, du coup, je doute sur l'intérêt de développer sa propre solution.

[tomlev]

Les ORM existants ne sont pas parfaits évidemment... mais ils sont quand même de très bonne qualité (à mon sens en tous cas), et comme tu l'as dit, EF va probablement s'améliorer encore.
Maintenant, si vraiment ça ne convient pas à tes besoins, tu peux toujours faire ton propre ORM, mais soyons réalistes : crois-tu vraiment pouvoir réaliser, seul et même pas à plein temps, quelque chose de mieux que les équipes de EF ou NHibernate qui bossent dessus depuis des années ? Si tu y arrives, tu es mon idole

[anthyme]

moi a ta place je prendrai le problème dans l'autre sens :

nhibernate et EF sont de très bon ORM et tu auras du mal a faire quelque chose d aussi bien... mais malgré tout cela ne correspond pas a tes besoin donc pourquoi ne pas, justement, étendre les possibilités de ces framwork la ou cela ne répond pas a tes besoins.

par exemple ajouter un générateur de base de données pour EF ou créer un plugin visual studio pour nhibernate ? (on a sa en commun dans les manques )

[davcha]

Je me vois mal ajouter des fonctionnalités comme les relations 1-1 réflexives ou des notions d'héritage multiple à EF...

J'avoue que j'espérais quelques encouragements en écrivant ce message

Enfin bref, je crois qu'en fait, la source de mes doutes, quant à l'intérêt de ce projet, est un poil plus complexe que "y'a beaucoup de concurrence, installée depuis plus longtemps".

Je me demande souvent durant ces moments de doutes si le projet va dans la bonne direction, et comme je fais ça tout seul dans mon coin... Evidemment, je sais que ce que je produis répondra à mes besoins, mais j'aimerais aussi pouvoir proposer quelque chose qui pourra être utile pour davantage de développeurs.
Et là, il est clair qu'il me manque beaucoup de retours (j'ai aucun retours, puisque j'ai seulement commencé un blog là-dessus hier soir...)

[anthyme]

Je me vois mal ajouter des fonctionnalités comme les relations 1-1 réflexives ou des notions d'héritage multiple à EF...

Qu'est ce que tu veux dire par relation réflexive ?
Sinon pour moi l'héritage multiple dans une architecture objet en C# me semble etre une abération

J'avoue que j'espérais quelques encouragements en écrivant ce message

désolé ...

Le truc c'est que aussi bon soit il, ton orm arrive un peu tard dans le monde .net car nhibernate est installé depuis des années et les partisans du "on évite les lib tier pour garder une cohérence" ont maintenant les outils de MS.

Et là, il est clair qu'il me manque beaucoup de retours (j'ai aucun retours, puisque j'ai seulement commencé un blog là-dessus hier soir...)

Donne le lien ici et t aura quelques retours

[tomlev]

Sinon pour moi l'héritage multiple dans une architecture objet en C# me semble etre une abération

+1
Vu que .NET ne supporte pas l'héritage multiple, ça n'a pas de sens de vouloir le faire dans un ORM .NET...

[davcha]

Le truc c'est que aussi bon soit il, ton orm arrive un peu tard dans le monde .net car nhibernate est installé depuis des années et les partisans du "on évite les lib tier pour garder une cohérence" ont maintenant les outils de MS.

Ca, j'en suis bien conscient (d'autant plus que d'une manière générale, je fais partie de ces partisants du "tout microsoft"), d'où mes doutes qui reviennent régulièrement.
J'avais pensé à proposer l'orm à microsoft (sait-on jamais ?...) mais vu qu'ils ont déjà EF, ça paraît aussi compromis.

Sinon, concernant l'héritage multiple et le blog...

L'héritage multiple auquel je pense n'est pas vraiment de l'héritage multiple au sens où on l'entend habituellement, là, il s'agit plus d'une construction qui permet de manipuler les même données vues sous des angles différents.

Par exemple, avec EF, en supposant que j'ai une classe "client" qui hérite de "personne", je n'ai pas trouvé le moyen de créer un client à partir d'une personne. Soit on crée un client, soit une personne, mais une fois que le type est déterminé, il ne bouge plus.
C'est un peu dommage, parce qu'en définitive, si je complexifie un peu en ajoutant une classe "fournisseur" et/ou "employé" qui héritent de "personne", on voit bien qu'un fournisseur ou employé peut devenir un client un jour.

Et le blog, pour le moment, il n'y a qu'une petite présentation très succinte, vous pouvez cliquer sur le bouton "www", vous arriverez dessus.

[anthyme]

Ce dont tu parle c'est plutot du changement de type d'un objet.

Si dans certain langages (dynamique) comme le python on peut simplement changer le type d'un objet en changeant une des propriétés (__type__ en python), ce n'est pas le cas en C# donc encore une fois ça irai contre le fonctionnement de de C#.

J'avoue avoir déjà eu ce souci en LTS ... mais je n'ai pas trouvé de solution efficace pour le contourner...

Bon courage pour la suite

[B.AF]

Je vous rassure, encore 2/3 semaines et peut être qu'on va enfin pouvoir publier notre générateur de code Nhibernate en open source...Enfin si la boite est d'accord.

Pour la terminologie; Nhibernate est lourd pour ceux qui font du relationnel; quand tu pars du domaine objet, c'est un pur bonheur.

Pour EF; c'est un mappeur; mais certainement pas un ORM.

Quant à faire ton ORM ; tu peux le faire; regarde Evaluant, tout seul un dieu du code l'a fait : EUSS Evaluant; qui est un excellent ORM !

Franz bouma a démarré LLBL seul aussi.

Et microsoft a acheté Subsonic...

Alors tous les rêves sont permis.

Pour l'héritage je comprends ce que tu veux dire, et c'est exactement ce qui fait que nhibernate est un ORM et pas EF.
Nhibernate a cette notion ou l'objet prévaut sur la/les table(s).

Good luck.

[Paul Musso]

Pour EF; c'est un mappeur; mais certainement pas un ORM.

B.AF, est-ce que tu dis ça uniquement parce que EF ne supporte pas les classes POCO ? (obligation de faire hériter les classes métiers d'interfaces).

Certes les classes métiers sont couplées à des classes du framework, mais cela ne les couple pas pour autant à la structure de la base de données ... Le schéma de liaison (MSL) permet de garantir cette indépendance.

Je dis pas que cette conception est un avantage lorsque les classes métiers existent déjà, bien au contraire ...

[B.AF]

Non, mais j'en parlai justement avec un architecte de ms hier :
Le designer d'EDM cache la vraie puissance du moteur.

Mais bref, je ne prends plus le risque de citer EDM.

[Paul Musso]

Ok ^^

C'est clair qu'il restreint pas mal de possibilités comme par exemple les types complexes et l'utilisation de classes personnalisées.

La version 2 arrangera pas mal de choses à priori.

[tomlev]

C'est clair qu'il restreint pas mal de possibilités comme par exemple les types complexes et l'utilisation de classes personnalisées.

Pour les classes personnalisées, ce n'est qu'à moitié vrai... comme les classes générées par le designer sont déclarées comme partial, tu peux très bien les compléter avec du code à toi qui ne sera pas écrasé par le designer. Par contre tu ne peux évidemment pas les faire hériter de la classe que tu veux, mais tu peux toujours implémenter des interfaces.

[B.AF]

Oui clairement, le dsign POCO n'a pour moi d'utilité que dans la possibilité de pouvoir substituer le moteur sans toucher au design du domain.

En plus, a priori MS a créé un adapter poco pour EF donc a tenu compte de cela.

Voilà.

Maintenant, le designer tient compte du fait que souvent l'ORM est utilisé depuis la base vers l'objet et non l'inverse.

Et il encapsule pas mal de complexité de l'outil; mais il cache beaucoup trop de choses à mon goût. Je crois que maitrisé EF passe aussi par la maitrise des mappings et leur compréhension, comme tout ORM, et qu'une fois qu'un pattern est trouvé et correspond au cas d'utilisation, un designer ou un outil de génération fait du sens.

[davcha]

Oui clairement, le dsign POCO n'a pour moi d'utilité que dans la possibilité de pouvoir substituer le moteur sans toucher au design du domain.

Les POCO sont aussi intéressantes quand tu dois faire du n-tier. Se trimbaler des classes qui implémentes des membres relatifs à l'accès aux données dans la couche de présentation, par exemple, c'est pas super.

Sinon, c'est surtout qu'un design non-poco ne permet pas toujours de faire tout ce qu'on veut avec le domaine.
Genre des classes qui héritent d'autres classes, des collections choisies pour les relations, des structures (je ne parle pas de structs) qui permettent de simuler des "changements de type", etc.

[B.AF]

Oui mais (allez, j'ouvre un hors sujet) c'est que finalement, passer sur le tuyau des entités de la DB, c'est bien pour une application "simple"

Si la logique business est complexe, c'est impossible, tu es obligé de dissocier.

Maintenant , on peut mixer les deux aussi, il n'y a pas de vérité absolue en architecture.

Mais effectivement le Design Poco simple est bien adapté au N-Tiers sur la forme.
Dans le fonds, tu finis toujours pas avoir des questions d'états de session, de time out, de change tracking...

PS: Tu cherches pas du taf ???????????

[davcha]

Ca fait un bail, j'avais même pas vu ta dernière intervention, B.AF.

Pour ce qui est du change tracking et compagnie, à l'époque où j'avais écrit ce post, j'avais réalisé un système dans cet "orm" qui permettait de faire ce genre de chose de manière totalement transparente.

En fait, pour faire simple, disons que suivant la configuration du mapping, les modifications de valeurs au niveau d'un client pouvaient être automatiquement répercutées sur le serveur et broadcastées à tous les autres clients connectés au serveur.
Enfin bref...

Pourquoi cette question concernant la recherche de taf ? Tu avais un truc à proposer à l'époque ? :p

[Archeone]

Comme je te l'ai dis par MP moi aussi je me suis lancé dans l'aventure de création d'un ORM.

Ce genre de projet est très instructif et permet de toucher a des parties du framework que l'on utilise pas dans les projets habituels...(Reflexion, génération de MSIL...).


Je viens de poster un petit descriptif de mon ORM dans la section projet.
http://www.developpez.net/forums/d79...m/#post4552794