Y a-t-il quelque chose comme fluent-Nhibernate pour le Java Hibernate d'origine? Sinon, pourquoi pas? Y a-t-il des limitations spécifiques à la langue? P>
3 Réponses :
Je pense que fluent-NHibernate repose sur les belles caractéristiques fournies par Linq en C # 3.0 si je ne me trompe pas. Java implémente les expressions Lambda, etc. Je ne pense pas que nous verrons couramment l'hibernation. P>
Je pourrais me tromper cependant. :) p>
bon point. Je me concentrais sur l'interface de style fluide et je me demandais si ceci est un problème et que cela ne pouvait en trouver aucun. Mais à l'intérieur des appels concatérés, il y a des expressions Lambda, Doh!
De la bouche des chevaux (je suis le promoteur principal sur Nhibernate fluide): la raison pour laquelle Hibernate fluide n'existe pas est exactement à cause du manque d'expressions Lambda. Ce n'est pas seulement le manque de lambdas de base, mais la capacité d'analyser ces expressions que FNH repose fortement sur; Sans lequel vous auriez besoin de recourir à des cordes et ce n'est pas meilleur que XML à mon avis. C'est toujours une possibilité pour l'avenir.
@James: Lorsque vous utilisez Lambdas, les données sont cool, je trouve que la cartographie basée sur la convention est ma motivation principale pour l'utilisation de FNH. C'est incroyablement facile de "obtenir quelque chose de travail", puis de verrouiller le schéma plus tard. Le seul problème que je vois est le fait que le modèle de fermeture imbriquée est utilisé dans toute la FNH; Bien que cela fonctionne bien avec C #, Java n'a pas de prise en charge des méthodes anonymes (bien que vous puissiez créer des foncteurs via des cours anonymes). Je pense que Hibernate fluide fonctionnerait assez bien à Scala, et cela pourrait bien travailler en Java.
Un an après avoir fait mon commentaire, mes pensées mirent à peu près le vôtre. Si vous avez envie de discuter plus loin, déposez un message sur le Liste de diffusion FNH .
@James - Comment cela pourrait-il être fait à Scala? Afaik, c'est plus que les lambdas qui sont nécessaires à l'analyse des expressions et à la recherche d'une représentation d'objets de l'AST. Dans Scala, vous pouvez créer une Lambda, mais seulement l'exécuter et ne pas l'examiner. J'imaginerais que FNH regarde quelque chose comme Foo => Foo.bar et peut voir que l'expression représente l'accès à la propriété nommée "bar" qu'elle utilise dans ses mappages. N'est-ce pas possible à Scala / Groovy?
@Owen - Je ne suis pas assez familier avec Scala ou Groovy pour vraiment dire si vous pouviez reproduire la partie "réflexion statique" de la FNH; Vous êtes correct dans vos hypothèses cependant, FNH utilise des objets d'arborescence code> d'expression code> de .NET, qui vous permettent d'inspecter une structure d'une méthode anonyme sans l'exécuter. J'ai écrit un peu un résumé sur ce sujet il y a quelques années: Introduction à statique Réflexion
Quelle est la réponse à la fin de 2018?
Groovy prend en charge les expressions Lambda (bien qu'ils appellent plutôt conforblement des fermetures) et les classes groovy sont directement accessibles depuis Java. Peut-être que les mappages des applications Java pourraient être écrits à Groovy. P>
Juste une pensée. P>
Scala prend en charge la Lambda, à droite (je suis totalement NEWBIE SCALA). Et il est complètement interopérable avec Java au niveau de la compilation statique. Il semble que Scala + Hibernate activerait couramment le côté Java. P>
Pour être complètement pédant, cela permettrait "couramment" du côté JVM.