Partager via


Présentation de .NET MAUI

Conseil

Ce contenu est un extrait du livre électronique Modèles d’application d’entreprise avec .NET MAUI, disponible dans la .documentation .NET ou en tant que PDF téléchargeable gratuitement qui peut être lu hors connexion.

Miniature de la couverture du livre électronique Modèles d’application d’entreprise avec .NET MAUI.

Quelle que soit la plateforme, les développeurs d’applications d’entreprise sont confrontés à plusieurs défis :

  • Exigences de l’application qui peuvent changer au fil du temps.
  • Nouvelles opportunités commerciales et défis.
  • Commentaires continus pendant le développement qui peuvent affecter de manière significative l’étendue et les exigences de l’application.

Avec ces éléments à l’esprit, il est important de créer des applications qui peuvent être facilement modifiées ou étendues au fil du temps. La conception d’une telle adaptabilité peut être difficile, car elle nécessite une architecture qui permet à des parties individuelles de l’application d’être développées et testées de manière indépendante sans affecter le reste de l’application.

De nombreuses applications d’entreprise sont suffisamment complexes pour nécessiter plusieurs développeurs. Cela peut constituer un défi important de décider comment concevoir une application afin que plusieurs développeurs puissent travailler efficacement sur différents éléments de l’application indépendamment, tout en veillant à ce que les éléments s’assemblent en toute transparence lorsqu’ils sont intégrés à l’application.

L’approche traditionnelle de la conception et de la création d’une application aboutit à ce que l’on appelle une application monolithique, où les composants sont étroitement couplés sans séparation claire entre eux. En règle générale, cette approche monolithique conduit à des applications difficiles et inefficaces à gérer, car il peut être difficile de résoudre les bogues sans interrompre d’autres composants de l’application, et il peut être difficile d’ajouter de nouvelles fonctionnalités ou de remplacer des fonctionnalités existantes.

Un remède efficace à ces défis consiste à partitionner une application en composants discrets et faiblement couplés qui peuvent être facilement intégrés ensemble dans une application. Une telle approche offre plusieurs avantages :

  • Elle permet à des fonctionnalités individuelles d’être développées, testées, étendues et gérées par différentes personnes ou équipes.
  • Elle favorise la réutilisation et une séparation claire des préoccupations entre les fonctionnalités horizontales de l’application, telles que l’authentification et l’accès aux données, et les fonctionnalités verticales, telles que les fonctionnalités métier spécifiques de l’application. Cela permet de gérer plus facilement les dépendances et les interactions entre les composants de l’application.
  • Il est ainsi possible de maintenir une séparation des rôles en permettant à différentes personnes, ou équipes, de se concentrer sur une tâche ou un élément de fonctionnalité spécifique en fonction de leur expertise. En particulier, cette approche offre une séparation plus nette entre l’interface utilisateur et la logique métier de l’application.

Toutefois, de nombreux problèmes doivent être résolus lors du partitionnement d’une application en composants discrets et faiblement couplés. Il s’agit notamment des paramètres suivants :

  • Décider comment fournir une séparation claire des problèmes entre les contrôles d’interface utilisateur et leur logique. L’une des décisions les plus importantes lors de la création d’une application d’entreprise .NET MAUI consiste à placer la logique métier dans des fichiers code-behind ou à créer une séparation claire des problèmes entre les contrôles d’interface utilisateur et leur logique, afin de rendre l’application plus facile à gérer et à tester. Pour plus d’informations, consultez Modèle-vue-vue modèle.
  • Déterminer s’il faut utiliser un conteneur d’injection de dépendances. Les conteneurs d’injection de dépendances réduisent le couplage des dépendances entre les objets en fournissant une fonctionnalité permettant de construire des instances de classes avec leurs dépendances injectées et de gérer leur durée de vie en fonction de la configuration du conteneur. Pour plus d’informations, consultez Injection de dépendances.
  • Choisir entre les événements fournis par la plateforme et la communication basée sur les messages faiblement couplée entre les composants qui ne sont pas pratiques à lier par références d’objet et de type. Pour plus d’informations, consultez Présentation de la communication entre les composants faiblement couplés.
  • Décider comment naviguer entre les pages, notamment comment appeler la navigation, et où la logique de navigation doit résider. Pour plus d’informations, consultez Navigation.
  • Déterminer comment valider l’exactitude de l’entrée utilisateur. La décision doit inclure comment valider l’entrée de l’utilisateur et comment informer l’utilisateur des erreurs de validation. Pour plus d’informations, consultez Validation.
  • Décider comment effectuer l’authentification et comment protéger les ressources avec l’autorisation. Pour plus d’informations, consultez Authentification et autorisation.
  • Déterminer comment accéder aux données distantes à partir de services web, notamment comment récupérer des données de manière fiable et comment mettre des données en cache. Pour plus d’informations, consultez Accès aux données distantes.
  • Décider comment tester l’application. Pour plus d’informations, consultez Test unitaire.

Ce guide fournit de l’aide sur ces problèmes et se concentre sur les modèles et l’architecture de base pour la création d’une application d’entreprise multiplateforme à l’aide de .NET MAUI. L’aide vise à contribuer à produire du code adaptable, gérable et testable en répondant aux scénarios courants de développement d’applications d’entreprise .NET MAUI et en séparant les préoccupations de présentation, de logique de présentation et d’entités par le biais de la prise en charge du modèle MVVM (modèle-vue-vue modèle).

Exemple d’application

Ce guide comprend un exemple d’application, eShop, qui est un magasin en ligne qui comprend les fonctionnalités suivantes :

  • Authentification et autorisation auprès d’un service principal.
  • Navigation dans un catalogue d’éléments.
  • Filtrage du catalogue.
  • Classement des articles du catalogue.
  • Affichage de l’historique des commandes de l’utilisateur.
  • Configuration des paramètres.

Exemple d'architecture de l’application

Vous trouverez ci-dessous une vue d’ensemble générale de l’architecture de l’exemple d’application.

Architecture de haut niveau eShop

L’exemple d’application est fourni avec :

  • Hébergement et orchestration d’applications Aspire .NET
  • Une application web Blazor développée avec ASP.NET Core.
  • Application multiplateforme, développée avec .NET MAUI, qui prend en charge iOS, Android, macOS par Mac Catalyst et Windows.

L’exemple d’application inclut les services principaux suivants :

  • Microservice d’identité, qui utilise ASP.NET Core Identity et IdentityServer.
  • Microservice de catalogue, qui est un service CRUD (Create, Read, Update, Delete) piloté par les données qui consomme une base de données SQL Server à l’aide d’EntityFramework Core.
  • Microservice de commande, qui est un service piloté par un domaine qui utilise des modèles de conception pilotés par domaine.
  • Microservice panier, qui est un service CRUD piloté par les données qui utilise le cache Redis.

Ces services principaux sont implémentés en tant que microservices à l’aide d’ASP.NET Core et sont déployés en tant que conteneurs uniques avec .NET Aspire. Collectivement, ces services principaux sont appelés application de référence eShop. Les applications clientes communiquent avec les services principaux via une interface web REST (Representational State Transfer). Pour plus d’informations sur les microservices et les conteneurs, consultez Containerized microservices.

Application multiplateforme

Ce guide se concentre sur la création d’applications d’entreprise multiplateformes à l’aide de .NET MAUI et utilise l’application multiplateforme eShop comme exemple. L’image ci-dessous montre les pages de l’application multiplateforme eShop qui fournissent les fonctionnalités décrites précédemment.

L’application eShop MAUI

L’application multiplateforme utilise les services principaux fournis par l’application de référence eShop. Toutefois, elle peut être configurée pour consommer des données à partir de services fictifs pour ceux qui souhaitent éviter de déployer les services principaux.

L’application multiplateforme eShop exerce les fonctionnalités .NET MAUI suivantes :

  • XAML
  • Commandes
  • Liaisons
  • Convertisseurs
  • Styles
  • Animations
  • Commandes
  • Comportements
  • Déclencheurs
  • Effets
  • Contrôles personnalisés

Pour plus d’informations sur cette fonctionnalité, consultez la Documentation sur MAUI.NET.

En outre, des tests unitaires sont fournis pour certaines classes de l’application multiplateforme eShop.

Solution d’application multiplateforme

La solution d’application multiplateforme eShop organise le code source et d’autres ressources en plusieurs projets. Tous les principaux composants mobiles sont contenus dans un projet unique nommé eShopContainers. Il s’agit d’une fonctionnalité introduite avec .NET 6 qui permet à un projet de cibler plusieurs sorties, ce qui évite d’avoir besoin de plusieurs projets de plateforme que nous aurions utilisés dans Xamarin.Forms et les versions antérieures de .NET. Un projet supplémentaire est inclus pour les tests unitaires.

Bien que tous ses composants soient stockés dans un projet unique, il est utile d’envisager de le séparer en plusieurs projets en fonction de vos besoins. Par exemple, si vous avez plusieurs implémentations de fournisseurs de services basées sur un service avec ses propres dépendances, il peut être judicieux de décomposer ces implémentations de fournisseurs de services dans leur propre projet distinct. Les bons candidats pour la séparation des projets incluent les modèles partagés, les implémentations de service, les composants client d’API, la base de données ou les couches de mise en cache. Tout endroit où vous pensez que l’entreprise pourrait réutiliser un composant dans un autre projet est un candidat potentiel pour la séparation. Ces projets peuvent ensuite être empaquetés via NuGet pour faciliter la distribution et le contrôle de version.

Tous les projets utilisent des dossiers pour organiser le code source et d’autres ressources en catégories. Les classes de l’application multiplateforme eShop peuvent être réutilisées dans n’importe quelle application .NET MAUI avec peu ou pas de modification.

Projet eShop

Le projet eShop contient les dossiers suivants :

Dossier Description
Animations Contient des classes qui permettent de consommer des animations en XAML.
Comportements Contient des comportements exposés aux classes d’affichage.
Contrôles Contient des contrôles personnalisés utilisés par l’application.
Convertisseurs Contient des convertisseurs de valeurs qui appliquent une logique personnalisée à une liaison.
Exceptions Contient l’exception ServiceAuthenticationException personnalisée.
Extensions Contient des méthodes d’extension pour les classes VisualElement et IEnumerable<T>.
Programmes d’assistance Contient des classes d’assistance pour l’application.
Modèles Contient des classes de modèle pour l’application.
Propriétés Contient AssemblyInfo.cs, un fichier de métadonnées d’assembly .NET.
Services Contient des interfaces et des classes qui implémentent des services fournis à l’application.
Déclencheurs Contient le déclencheur BeginAnimation, qui est utilisé pour appeler une animation en XAML.
Validations Contient des classes impliquées dans la validation de l’entrée de données.
ViewModels Contient la logique d’application exposée aux pages.
Views Contient les pages de l’application.

Résumé

Les outils et plateformes de développement d’applications multiplateformes de Microsoft fournissent une solution complète pour les applications clientes mobiles B2E, B2B et B2C, offrant la possibilité de partager du code sur toutes les plateformes cibles (iOS, macOS, Android et Windows) et contribuant à réduire le coût total de possession. Les applications peuvent partager leur interface utilisateur et leur code logique d’application, tout en conservant l’apparence de la plateforme native.

Les développeurs d’applications d’entreprise font face à plusieurs défis qui peuvent modifier l’architecture de l’application pendant le développement. Par conséquent, il est important de créer une application afin qu’elle puisse être modifiée ou étendue au fil du temps. La conception d’une telle adaptabilité peut être difficile, mais implique généralement de partitionner une application en composants discrets et faiblement couplés qui peuvent être facilement intégrés ensemble dans une application.