Discussion :

[maa]

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)

Quelle sont les différences entre un ORM et un mapper ?

[Philippe Vialatte]

Quelle sont les différences entre un ORM et un mapper ?

ok, c'est pas clair (mais c'est normal, c'est vendredi...)

L'idee, c'etait d'essayer d'introduire une difference entre un outil qui fait du mapping 1/1, par rapport a un outil comme EDM/Nh/LightSpeed, ou tu peux avoir des entites qui vont mapper une ou plusieurs tables

[B.AF]

Et surtout l'entité n' a pas de responsabilitées propre, pas plus que la maniére d'accès aux données.

Fowler :
Mapper :

layer of mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself

C'est clair !!!!

En gros un mapper ne sert qu'à transformer du SQL en objets et vice versa, bref, c'est une couche et une encapsulation.

Un ORM, ça sert à définir des domains et surtout il n'existe plus de couche SQL réelle.

Disons qu'un ORM c'est un mapper avec plus d'intelligence, plus centré sur le modèle objet et capable d'offrir plus de services.

[_skip]

plus centré sur le modèle objet

Je crois que je vois ou se situe ton désaccord avec le système d'entité llblgen.
Maintenant la grosse question serait aussi de se demander jusqu'à quel point on peut assumer du full OO (donc une abstraction forte du monde relationnel) tout en restant suffisamment flexible dans sa façon de charger et persister ses données.

C'est un débat qui est beaucoup revenu sur le forum du support, déjà simplement de savoir si les entités pouvaient être passées entre les tiers ou non, et aussi si fondamentalement elles pouvaient assumer en tant que telles le rôle d'objets métier.

[maa]

Regardez ce qu'il vient de sortir :

http://code.google.com/p/nhlambdaext...2.0.1.4000.zip
Quelqu'un à testé ? C'est du sérieux ?

[B.AF]

Je crois que je vois ou se situe ton désaccord avec le système d'entité llblgen.
Maintenant la grosse question serait aussi de se demander jusqu'à quel point on peut assumer du full OO (donc une abstraction forte du monde relationnel) tout en restant suffisamment flexible dans sa façon de charger et persister ses données.

C'est un débat qui est beaucoup revenu sur le forum du support, déjà simplement de savoir si les entités pouvaient être passées entre les tiers ou non, et aussi si fondamentalement elles pouvaient assumer en tant que telles le rôle d'objets métier.

Et surtout il ne faut pas oublier que si d'avoir une persistence orientée objet, cela va aussi avec une base, donc des questions de schémas se posent.

D'où pour moi l'indispensable possibilité de contrôler la conversion d'un objet en élément de la base et de façon très fine.