Fable: Suggestion d'architecture alternative

Cela va être difficile car je travaille sur Mac avec Visual Studio Code, donc je n'ai absolument aucune idée de comment fonctionnerait cette infrastructure VS pour la gestion des dépendances :wink: Fable ne peut pas compiler un projet s'il ne sait pas comment résoudre les appels, ceci est destiné car vous ne voulez pas que les appels échouent au moment de l'exécution dans JS.

Mon conseil serait de créer un projet distinct dans votre solution qui ne contient que le code censé être compilé en JS. Cela peut inclure des fichiers partagés avec votre projet de serveur (par exemple des types définissant votre modèle de domaine, etc.) mais ne devrait pas avoir de dépendance d'assemblys pour le serveur (ASP.NET, WebAPI, Entity Framework...).

BTW, la façon de compiler plusieurs projets et références change dans 0.7. Vous pouvez voir quelques instructions préliminaires dans #522.

De cette façon, nous utilisons l'infrastructure VS pour la gestion des dépendances. Je comprends que cela semble un peu gênant et peut ne pas être multiplateforme, etc., mais cela pourrait quand même être une solution.

Créer un couplage étroit avec un [mauvais] éditeur particulier et un [mauvais] système d'exploitation particulier n'est une solution à rien. Une telle réflexion est une des raisons pour lesquelles nous sommes en place, nous sommes [.Net est mort. ]

@alfonsogarciacaro , merci pour les conseils, je pense que ça va marcher.

@Krzysztof-Cieslak , ha-ha-ha, je suis développeur .Net à temps plein d'applications Web d'entreprise. Donc, ma vision est un peu différente.

@alehro En effet, c'est comme l' a dit FeathersJs avec Fable actuellement uniquement pour le frontend et cela ressemble presque aux applications précédentes avec suave et aussi asp.net core .

Clôturant le problème, n'hésitez pas à le rouvrir si vous avez d'autres questions.

Je pense que @alehro a soulevé un sujet absolument raisonnable.
Ce serait extrêmement bien d'avoir un seul fsproj pour le front-end et le back-end ASP.NET Core.
Peut-être que cela peut être fait avec une compilation conditionnelle, n'est-ce pas ?

Merci de ne pas mélanger le code frontend et backend...

Par exemple, si vous utilisez Elmish, quelle partie du code voulez-vous mixer ? Les genres ? Pourquoi la vue et le serveur auraient-ils besoin des mêmes types ? Probablement juste pour la partie interface oui, donc une bibliothèque de classes commune ferait le travail.

En outre, vous pouvez avoir une communication facile entre le serveur et le client. Voir cet article

Je n'utilise pas Elmish car cela ne me semble pas expressif. Je ferais mieux d'utiliser XAML + C# et de les transformer en HTML + JavaScript car je les connais mieux et je peux les visualiser dans le concepteur.

Pourquoi la vue et le serveur auraient-ils besoin des mêmes types ?

Oui.

Probablement juste pour la partie interface oui, donc une bibliothèque de classes commune ferait le travail.

C'est possible mais pourquoi suis-je limité à tout composer en un seul projet ?

En outre, vous pouvez avoir une communication facile entre le serveur et le client. Voir cet article

Suave est trop lent et avoir un routage en un seul endroit n'est pas pratique. De plus, il ne prend pas en charge quelque chose comme ASP.NET API Versioning .

Fable n'est lié à aucune bibliothèque spécifique comme Suave ou Elmish, vous pouvez utiliser tout ce qui correspond le mieux à vos besoins :smile: Côté serveur, vous pouvez utiliser n'importe quel langage de programmation d'ailleurs. Le principal avantage de l'utilisation de F# à la fois à l'arrière et à l'avant est que vous pouvez partager des types et que vous disposez également d'outils pour faciliter la communication, comme Fable.JsonConverter ou Fable.Remote.

Cependant, permettre de tout mettre dans le même projet est compliqué, je recommande donc d'utiliser différents projets. Pour les types partagés, vous pouvez utiliser un projet partagé comme le suggère @MangelMaxime , ou simplement inclure une référence au fichier contenant les types partagés dans votre projet frontal.