.NET Framework -lib auf .NET Core oder .NET Standart migrieren
-
Nein, ausgeschlossen ist es nicht, ich könnte es mir sogar sehr gut vorstellen, aber das wird nicht von heute auf morgen passieren.
Mit Avalonia habe ich noch nichts gemacht, ich schreibe nur ASP.NET Core Anwendungen in C#.
MfG SideWinder
-
JA ASP.NET finde ich auch sehr interessant, aber ich traue mich da nicht so ran, sofern ich mich mit Web-programmierung kaum auskenne, Tutorials habe ich bzg. asp.net auch schon gemacht, aber wenn ich was umsetzen will fehlt mir anfangs noch eine professionelle Hand. Will da nichts zusammenhacken um ans Ziel zu kommen
Apropo: Was wäre denn diesbezüglich ein guter weg, wenn ich mit ner WEB-GUI starten würde, Back-/Frontend mit ASP.NET und die Vorzüge von Razor nutzen, oder ASP.NET nur als backend (REST API) und eine Frontend-Framework benutzen ? Evtl. ist das auch eine sehr doofe Frage
-
Ist beides möglich, "moderner" ist wahrscheinlich Zweiteres, aber ersteres ist sicherlich einfacher. Wir nutzen auch in erster Linie server-side rendering weil man es sich an vielen Stellen sehr einfach machen kann (volles Typsystem, etc.) Client-side würde ich nur machen wenn du wirklich flüssige und häufige Updates benötigst.
MfG SideWinder
-
@SideWinder sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Ist beides möglich, "moderner" ist wahrscheinlich Zweiteres, aber ersteres ist sicherlich einfacher. Wir nutzen auch in erster Linie server-side rendering weil man es sich an vielen Stellen sehr einfach machen kann (volles Typsystem, etc.) Client-side würde ich nur machen wenn du wirklich flüssige und häufige Updates benötigst.
Aber mit TypeScript hast du auch ein volles Typsystem. Und in Zusammenarbeit mit z.B. VueJS und einem CSS Framework, womöglich die beiden gleich kombiniert wie bei Buefy, kann man sehr schöne, dynamische und moderne UIs basteln. Eine REST oder GraphQL Schnittstelle auf der Serverseite hilft dann auch gleich mit, dass man eine sehr schöne SoC hinbekommt.
Ich stimme aber definitiv zu, dass das erstere deutlich einfacher ist und womöglich für einen Anfänger geeigneter. Erst recht, wenn dieser vielleicht nicht so sattelfest in den sonstigen Websprachen und -frameworks ist.
@SoIntMan Noch ein womöglich wichtiger Hinweis. Es gibt Asp .Net und Asp .Net Core. Das sind zwei unterschiedliche Dinge. Wenn du mit .Net Core entwickeln willst, stelle sicher, dass du gegen Asp .Net Core entwickelst, heisst auch entsprechende Dokumentationen und Tutorials liest.
-
@Dravere sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Eine REST oder GraphQL Schnittstelle auf der Serverseite hilft dann auch gleich mit, dass man eine sehr schöne SoC hinbekommt.
Da bin ich mir nie sicher. Wenn die Web-Anwendung nur mit der auch-ansonsten-angebotenen REST-Schnittstelle programmiert, ist der Client meist sehr chatty, da das Web meist verschiedenste Domänen-Concerns auf einer Seite vereint. Da ist man dann oft performanter wenn man einen einzigen neuen Request gegen den Server macht und die ganze Seite neu aufbaut...ich befürchte man muss die REST-API und das REST-Backend oft trennen.
MfG SideWinder
-
@SideWinder Ich kann dir da nicht direkt folgen. Geht es dir um Performance oder Separation of Concerns (SoC)? Bezüglich Performance muss natürlich unbedingt eine gute REST-API vorhanden sein. Da ist allerdings meistens das Problem da, dass die REST-APIs eigentlich keine REST-APIs sind, sondern irgendwie indirekte SQL-Abfragen und es werden einfach die Tabellendaten rausgeliefert. In so einem Fall macht dann GraphQL viel mehr Sinn und hilft auch mit, dass mehrere Daten in einem einzelnen Request gebündelt werden.
Und mag sein, dass der Client etwas mehr Chatty wird, wobei ich mir da nicht wirklich sicher bin, aber wenn du z.B. kein Server-Rendering mehr hast und auch sonst die Logik auf der Serverseite einfacher wird, dann kannst du auch mehr Abfragen abhandeln.
Zudem sind es am Ende ziemlich sicher weniger Daten, welche übertragen werden. Wenn du Server-Rendering machst, dann überträgst du die Daten und die Darstellung. Im anderen Fall aber nur die Daten. Nur der Kaltstart der Seite ist etwas aufwendiger.
-
@Dravere sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Da ist allerdings meistens das Problem da, dass die REST-APIs eigentlich keine REST-APIs sind, sondern irgendwie indirekte SQL-Abfragen und es werden einfach die Tabellendaten rausgeliefert.
Was ja ziemlich genau das ist was REST predigt wie man es machen soll. Weswegen ich REST auch kacke finde
-
@hustbaer sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
@Dravere sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Da ist allerdings meistens das Problem da, dass die REST-APIs eigentlich keine REST-APIs sind, sondern irgendwie indirekte SQL-Abfragen und es werden einfach die Tabellendaten rausgeliefert.
Was ja ziemlich genau das ist was REST predigt wie man es machen soll. Weswegen ich REST auch kacke finde
Nein, ist es nicht. Zumindest nicht, wenn man nach den ursprünglichen Vorschlägen und Definitionen von REST geht. Was aber tatsächlich passiert ist, dass sich REST völlig verblödet hat und es nur noch ein halb-herziges REST ist. Wenn es noch hoch kommt, werden immerhin noch die HTTP Verben korrekt eingesetzt. Man sollte in den Fällen besser von einer HTTP API reden. Aber REST Dokumente sollten eigentlich navigierbar sein und spezifische Antworten auf spezifische Anfragen liefern. REST ist viel komplizierter als was üblicherweise als REST angeboten wird.
Ich weiss leider gerade nicht, wo man dazu eine gute Zusammenfassung findet. Wikipedia ist da nicht wirklich gut. Ich habe lange eigentlich auch mehr HTTP APIs geschrieben. Als ich mich dann für GraphQL anfing zu interessieren und nach den Unterschieden suchte, wurde mir eigentlich erst klar, dass ich bisher HTTP REST falsch eingesetzt habe. Und wenn du nach sowas suchst, findest du z.B. das hier: https://goodapi.co/blog/rest-vs-graphql
Aber der bleibt dort immer noch recht oberflächlich.
-
Ja gut das ist dann wieder so ein Fall von "nein, X ist eigentlich voll cool, nur keiner macht X weil keiner X versteht". In dem Fall bin ich einer von denen die X - anscheinend - nicht richtig verstanden haben, und daher ist es für mich weiterhin nicht brauchbar.
-
@hustbaer sagte in .NET Framework -lib auf .NET Core oder .NET Standart migrieren:
Ja gut das ist dann wieder so ein Fall von "nein, X ist eigentlich voll cool, nur keiner macht X weil keiner X versteht". In dem Fall bin ich einer von denen die X - anscheinend - nicht richtig verstanden haben, und daher ist es für mich weiterhin nicht brauchbar.
Das ist in Ordnung. Und die Experten von X stimmen dir dann sogar zu.
-
Huhu, d.h. ASP.NET und ASP.NET Core unterscheiden sich so emorm?
Eine einfach Web- UI, um eine Applikation zu parametrieren, (als self-hostet-web-server in einem windows-dienst) aber schon da weiß ich nicht wie ich das vernünftig via ASP.Net machen soll, Layout Gestaltung etc. So der MVVM Gedanke von WPF und Kapselung in Controls etc. in ASP.NET in MVC nach zu empfinden, fällt mir schwer.
Cool wäre es , wenn es eine "WPF/XAML to HTML5 Converter" gäbe
Oder eine gescheites Tutorial , mit dem ich Step-by-Step ne Web- App basteln kann..damit es klick macht...
-
Ja, ASP.NET und ASP.NET Core unterscheiden sich enorm. Mit ersterem würde ich nicht mehr anfangen, da es eine der ganz wenigen Technologien ist die Microsoft nicht einmal mehr nach .NET 5 bringen wird, d.h. du baust quasi schon Legacy-Wissen auf.
Für ASP.NET Core gibt es eigentlich im Internet genügend Tutorials, hast du Google schon benutzt? Ganz offiziell ist der Getting-Started-Guide von Microsoft: https://docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/introduction/getting-started
MfG SideWinder
-
Guten Morgen,
ja hab Google schon benutzt, und habe mal ein Tutorial (aber ASP.NET) gemacht, was dann wohl fürn A..... war;)
Wenn ich mich entscheiden würde, ASP.NET nur als Backend zu nehmen, und die Frontend Geschichten mit anderen Technologien zu machen, was würde Ihr da empfehlen. Gibt es hierfür auch IDE und Frameworks, so das man das
html5 layout an Scripts nich komplett "von Hand" machen muss?Ich habe mal React angeschaut, was ich eigentlich ganz cool finde. Aber eine IDE bzw. ein Tool, mit dem ich Frontend content "relativ" einfach bauen kann wäre ideal.
Vielen Danke Euch bisher;)
-
@SoIntMan Wie oben schon erwähnt, sind VueJS und Buefy Möglichkeiten. Damit teste ich gerade rum und bin recht zufrieden. Um genau zu sein, setze ich derzeit bei einem Projekt die folgenden Dinge ein:
- Yarn (JavaScript Abhängigkeiten, Alternative wäre NPM)
- Webpack (Build-Prozess, Alternativen wären wohl Gulp oder Grunt)
- Vue.JS (Client side templating & rendering, Alternativen wären wohl ReactJS und Angular)
- Bulma, bzw. Buefy (CSS-Framework, Buefy ist eine saubere Integration mit VueJS. Es gibt gerne mal solche Kombinationen mit CSS-Frameworks und dem Client-Side Rendering & Templating. Alternativen wären wohl Bootstrap, UIKit, und viele viele mehr)
- Apollo Client (GraphQL JavaScript Client)
- TypeScript (Besseres JavaScript. Einzige Alternative neben reinem JavaScript, welche ich kenne, wäre Kotlin. Kotlin ist in erster Linie eine Java-Alternative, aber man kann es auch nach JavaScript übersetzen lassen.)
- Babel (Unterstützung von neuen JavaScript Features in alten JavaScript Umgebungen)
- WebStorm (IDE, kenne dazu nicht wirklich Alternativen. Hab schon gehört, dass Leute VSCode verwenden. Wahrscheinlich könnte auch Eclipse oder NetBeans mit Plugins Web-Entwicklung unterstützen.)
-
Guten Morgen Davere,
vielen Danke für Deine Mühe, da werde ich mich mal durchwühlen. Echt super danke
-
Noch ein Thema: Kenn Ihr "Node-RED" gibt es da ein äquivalente Implementierung für ASP.NET ? Ich habe nichts gefunden, vll. wisst ihr was !?
Idee: Asp.NET service (Backend, soll mit Logic gefüttert werden. Logic als FBP (flow-based-programming) , diese soll via Web-Frontend erzeugt werden.
-
FYI: https://devblogs.microsoft.com/dotnet/update-on-net-standard-adoption/
With few exceptions, all libraries should be targeting .NET Standard. Exceptions include UI-only libraries (e.g. a WinForms control) or libraries that are just as building blocks inside of a single application.
MfG SideWinder
