Une autre façon d'expliquer la différence pourrait être avec des exemples du monde réel, car la plupart d'entre nous, les mortels, utiliseront les outils et les cadres existants (Xamarin, Unity, etc.) pour faire le travail.
Ainsi, avec .NET Framework, vous disposez de tous les outils .NET mais vous ne pouvez cibler que les applications Windows (UWP, Winforms, ASP.NET, etc.). Étant donné que .NET Framework est une source fermée, il n'y a pas grand-chose à faire à ce sujet.
Avec .NET Core, vous disposez de moins d'outils, mais vous pouvez cibler les principales plates-formes de bureau (Windows, Linux, Mac). Ceci est particulièrement utile dans les applications ASP.NET Core, car vous pouvez désormais héberger Asp.net sous Linux (prix d'hébergement moins chers). Maintenant, puisque .NET Core était open source, il est techniquement possible de développer des bibliothèques pour d'autres plates-formes. Mais comme il n'y a pas de frameworks qui le supportent, je ne pense pas que ce soit une bonne idée.
Avec .NET Standard, vous avez encore moins d'outils mais vous pouvez cibler toutes / la plupart des plateformes. Vous pouvez cibler Mobile grâce à Xamarin, et vous pouvez même cibler les consoles de jeu grâce à Mono / Unity. Mise à jour: Il est également possible de cibler des clients Web avec la plate-forme UNO et Blazor (bien que les deux soient un peu expérimentaux en ce moment).
Dans une application réelle, vous devrez peut-être les utiliser tous. Par exemple, j'ai développé une application de point de vente qui avait l'architecture suivante:
Serveur et client partagés:
- Une bibliothèque .NET Standard qui gère les modèles de mon application.
- Une bibliothèque .NET Standard qui gère la validation des données envoyées par les clients.
Puisqu'il s'agit d'une bibliothèque .NET Standard, elle peut être utilisée dans n'importe quel autre projet (client et serveur).
C'est également un bon avantage d'avoir la validation sur une bibliothèque standard .NET car je peux être sûr que la même validation est appliquée sur le serveur et le client. Le serveur est obligatoire, tandis que le client est facultatif et utile pour réduire le trafic.
Côté serveur (API Web):
Une bibliothèque .NET Standard (qui pourrait également être Core) qui gère toutes les connexions à la base de données.
Un projet .NET Core qui gère l'API Rest et utilise la bibliothèque de bases de données.
Comme cela est développé dans .NET Core, je peux héberger l'application sur un serveur Linux.
Côté client (MVVM avec WPF + Xamarin.Forms Android / IOS):
Une bibliothèque .NET Standard qui gère la connexion de l'API client.
Une bibliothèque .NET Standard qui gère la logique ViewModels. Utilisé dans toutes les vues.
Une application .NET Framework WPF qui gère les vues WPF pour une application Windows. Mise à jour: les applications WPF peuvent désormais être .NET core, bien qu'elles ne fonctionnent actuellement que sur Windows. AvaloniaUI est une bonne alternative pour créer des applications GUI de bureau pour d'autres plates-formes de bureau.
Une bibliothèque .NET Standard qui gère les vues Xamarin Forms.
Un projet Xamarin Android et Xamarin IOS.
Vous pouvez donc voir qu'il y a un grand avantage ici du côté client de l'application, car je peux réutiliser les deux bibliothèques .NET Standard (API client et ViewModels) et simplement faire des vues sans logique pour les applications WPF, Xamarin et IOS.