Fable: Alternativer Architekturvorschlag

Dies wird schwierig, da ich auf einem Mac mit Visual Studio Code arbeite, also habe ich absolut keine Ahnung, wie diese VS-Infrastruktur für das Abhängigkeitsmanagement funktionieren würde :wink: Fable kann kein Projekt kompilieren, wenn es nicht weiß, wie es geht Auflösen von Aufrufen, dies ist beabsichtigt, weil Sie nicht möchten, dass Aufrufe zur Laufzeit in JS fehlschlagen.

Mein Rat wäre, in Ihrer Lösung ein separates Projekt zu erstellen, das nur den Code enthält, der in JS kompiliert werden soll. Dies kann gemeinsame Dateien mit Ihrem Serverprojekt umfassen (zB Typen, die Ihr Domänenmodell definieren usw.), sollte jedoch keine Abhängigkeit von Assemblys für den Server aufweisen (ASP.NET, WebAPI, Entity Framework...).

Übrigens, die Art und Weise, mehrere Projekte und Referenzen zu kompilieren, ändert sich in 0.7. Sie können einige vorläufige Anweisungen in #522 sehen.

Auf diese Weise verwenden wir die VS-Infrastruktur für das Abhängigkeitsmanagement. Ich verstehe, dass dies etwas umständlich aussieht und möglicherweise nicht plattformübergreifend usw. ist, aber es könnte trotzdem eine Lösung sein.

Eine enge Kopplung mit einem bestimmten [schlechten] Editor und einem bestimmten [schlechten] Betriebssystem zu schaffen, ist keine Lösung für alles. Dieses Denken ist ein Grund, warum wir an unserem Ort sind [.Net ist tot. ]

@alfonsogarciacaro , danke für den Rat, ich denke, es wird funktionieren.

@Krzysztof-Cieslak, ha-ha-ha, ich bin Vollzeit-.Net-Entwickler von Unternehmens-Webanwendungen. Meine Vision ist also etwas anders.

@alehro Tatsächlich ist es so, wie @alfonsogarciacaro sagte. Ein separates Projekt für Fable zu haben, ist der richtige Weg. Die Kompilierung verläuft wie erwartet ohne die Abhängigkeitsprobleme. Damit bleibt der Ansatz unabhängig vom Backend gleich. Derzeit arbeite ich an einer FeathersJs Anwendung mit Fable, derzeit nur für das Frontend und es fühlt sich fast genauso an wie die vorherigen Apps mit suave und auch asp.net core .

Wenn Sie das Problem schließen, können Sie es gerne erneut öffnen, wenn Sie weitere Fragen haben.

Ich denke, @alehro hat ein absolut vernünftiges Thema
Es wäre sehr schön, ein einzelnes fsproj für das Front-End und das ASP.NET Core-Back-End zu haben.
Vielleicht geht das mit bedingter Kompilierung, oder?

Bitte den Frontend- und Backend-Code nicht vermischen...

Wenn Sie beispielsweise Elmish verwenden, welchen Teil des Codes möchten Sie mischen? Die Typen ? Warum brauchen die Ansicht und der Server die gleichen Typen? Wahrscheinlich nur für den Schnittstellenteil, ja, eine gemeinsame Klassenbibliothek würde die Arbeit erledigen.

Außerdem können Sie eine einfache Kommunikation zwischen dem Server und dem Client haben. Siehe diesen Artikel

Ich verwende Elmish nicht, da es für mich nicht ausdrucksstark aussieht. Ich würde besser XAML + C# verwenden und in HTML + JavaScript umwandeln, da ich sie besser kenne und im Designer visualisieren kann.

Warum brauchen die Ansicht und der Server die gleichen Typen?

Jawohl.

Wahrscheinlich nur für den Schnittstellenteil, ja, eine gemeinsame Klassenbibliothek würde die Arbeit erledigen.

Es kann, aber warum bin ich darauf beschränkt, alles in einem einzigen Projekt zusammenzufassen?

Außerdem können Sie eine einfache Kommunikation zwischen dem Server und dem Client haben. Siehe diesen Artikel

Suave ist zu langsam und das Routing an einer einzigen Stelle ist unpraktisch. Außerdem wird so etwas wie ASP.NET API Versioning nicht unterstützt.

Fable ist nicht an eine bestimmte Bibliothek wie Suave oder Elmish gebunden, Sie können alles verwenden, was Ihren Bedürfnissen besser entspricht :smile: Auf der Serverseite können Sie jede beliebige Programmiersprache verwenden. Der Hauptvorteil der Verwendung von F# sowohl auf dem Back- als auch auf dem Frontend besteht darin, dass Sie Typen freigeben können und Sie auch über Tools zur Vereinfachung der Kommunikation wie Fable.JsonConverter oder Fable.Remote verfügen.

Es ist jedoch kompliziert, alles in dasselbe Projekt zu integrieren, daher würde ich empfehlen, verschiedene Projekte zu verwenden. Für die freigegebenen Typen können Sie ein freigegebenes Projekt verwenden, wie @MangelMaxime vorschlägt, oder einfach einen Verweis auf die Datei mit den freigegebenen Typen in Ihr Frontend-Projekt einfügen .