Support .net framework / EF6 ?

[ThibautRappet]

Est-ce envisagé de mettre à disposition un Web en .net framework avec une infra qui a comme dépendance du EF6 ?

[rducom]

Clairement non, Rdd bien qu'étant netstandard est adossé à aspnet core. Qui lui n'a pas vocation à target le .Net 4.xx. Hors EF6 n'est pas compatible aspnet core.
Donc c'est techniquement impossible. Et je pense stratégiquement non souhaitable pour une étape de migration intermédiaire vers Rdd 3.x

[nfaugout-lucca]

Oui au final ça revient à dire que RDD aurait pu ne targeter QUE .NetCore.

@rducom d'ailleurs est-ce qu'il y aurait un intérêt à ne targeter que .NetCore ? Perfs ? Autre avantage ?

[Poltuu]

Je suis pas très calé sur le sujet, mais je doute que la compilation ou truc du genre, sachant qu'elle target netcore au lieu de framewoek, fasse des optimisation qqconques

[ThibautRappet]

Pour détailler l'idée dont après j'ai discuté avec Raph, c'était effectivement d'imaginer une étape de transition vers du RDD v3 dans le monolithe avant de pouvoir en sortir.

Par contre le fait d'avoir du .net core obligatoire ferme un peu l'évolution des WS en rdd V1, où il faut forcément engager un gros chantier avec triple migrations (RDD V3 + EF core + .net core)

[rducom]

Netcore 2.1 expose une surface d'API plus grande que NetStandard2, en particulier autour des Span, Pipeline, qui sont des primitives orientées performance. Donc oui il existe un intérêt sur ces features, et non des moindres.

Ceci étant dit, il est important je pense que le Domain reste en netstandard, de façon à ne pas fermer la porte de la possibilité pour des dev de partager leur domain entre des applis netcore et net legacy. C'est de toute façon une couche qui n'aura pas vocation à utiliser ces nouvelles primitives

[GMouron]

Par contre le fait d'avoir du .net core obligatoire ferme un peu l'évolution des WS en rdd V1, où il faut forcément engager un gros chantier avec triple migrations (RDD V3 + EF core + .net core)

Ouais alors, pour avoir tenté de monter CC de Rdd v1 vers Rdd v2, c'est déjà une tâche énorme, donc au final, je pense que c'est quasiment plus simple de réécrire.
Après, CC était dans une version "early" de Rdd v1, donc peut-être qu'une utilisation un peu plus tardive rendrait la transition plus facile, je ne sais pas.

[nfaugout-lucca]

Je me vois mal mettre RDD dans le monolithe, car l'injection & co serait commune à tout le monolithe, et ce serait trop risqué en termes de régressions potentielles. Et je trouve que ça n'incite pas à en sortir du coup !

Reste en effet les projets hors monolithe qui ne sont pas en .netcore, mais pour eux j'ai aussi envie de dire que passer à .netcore est un mal pour un bien, et que personne ne va regretter de passer à .netcore.

Donc à partir de là, dire que la v3 de RDD est .netcore only me semble une contrainte saine, surtout si y'a des nouvelles features qu'on peut utiliser.

[ThibautRappet]

Je me vois mal mettre RDD dans le monolithe, car l'injection & co serait commune à tout le monolithe, et ce serait trop risqué en termes de régressions potentielles. Et je trouve que ça n'incite pas à en sortir du coup !

L'idée étant de faire étape par étape, avant de sortir du code du monolithe il faut découpler tout le code métier du code métier, fixer les nombreux anti pattern du monolithe, etc ... et je me suis dit qu'une transition rdd3 dans le monolithe pouvait être une option.

Reste en effet les projets hors monolithe qui ne sont pas en .netcore, mais pour eux j'ai aussi envie de dire que passer à .netcore est un mal pour un bien, et que personne ne va regretter de passer à .netcore.

Juste passer en core c'est simple normalement, mais RDD V3 + EF core + .Net core, c'est un gros chantier.
Le fait d'avoir un framework fait que le code est fortement couplé à celui-ci, et accélère la dette technique... Je pense que c'est assez simple de passer en .net core pour les WS qui ne sont pas sous RDD.

[nfaugout-lucca]

Pour faire étape par étape, je vous suggérerais plutôt d'isoler un BoundedContext (genre les reportings par ex), puis de sortir uniquement cette sous partie de Cleemy (comme Figgo est en train de le faire avec Figgo.Report). Ainsi, le scope métier à refactorer est bien précis, et du coup vous pouvez vous permettre un plus gros gap technologique : RDD v3, NetCore, EFCore.

Sur Bulp par ex où l'API des users est inextricable du monolithe (je me vois mal essayer de faire du refacto dessus), on va sortir d'abord la mire de login (BC d'authentification), donc avec une certaine "idée" de ce qu'est un user, puis l'import, puis ... jusqu'à avoir tout sorti.

Perso je préfère cette approche que d'essayer de refactorer tout le métier DANS le monolithe d'un coup, avec tous les risques de régression que ça peut entraîner en prod sur tout Cleemy, vs des risques uniquement sur des modules bien précis une fois que tu branches le front sur tes nouvelles API/routes