Chers lecteurs, nous sommes heureux de vous présenter le livre «Développement d'applications mobiles en C # pour iOS et Android» de l'auteur et expert de Xamarin, Vyacheslav Chernikov de Binwell, que vous connaissez déjà bien. Sans longs préludes, je passe la parole à l'auteur.
Bonjour, cher habrachitatel. Au cours des dernières années, j'ai écrit pas mal d'articles et de tutoriels sur le développement d'applications mobiles à l'aide de C # et du framework Xamarin, mais au départ tous ces guides et une partie des articles ont été conçus comme des chapitres de mon premier livre, qui a finalement vu le jour. Étant assemblé en un seul ensemble (et il y a beaucoup de choses qui n'ont pas été publiées auparavant!), Les matériaux du livre porteront le processus de développement d'applications mobiles à un tout autre niveau - du choix d'un outil et de la préparation de la documentation, à l'automatisation du processus de développement et à la résolution des problèmes courants. Ce livre a été conçu comme un ajout harmonieux aux documents sur Xamarin qui sont déjà en russe et en anglais, révélant des problèmes tels que la conception, l'architecture, la création du squelette (cadre) d'un projet, tout ce qui reste généralement dans les coulisses de la plupart des livres et des cours de formation. .
Le livre couvre en détail et avec un grand nombre d'exemples de code les sujets suivants: comparaison d'outils natifs et multiplateformes utilisant Xamarin, ReactNative, PhoneGap, Qt et Flutter comme exemples; conception et documentation technique du code; architecture et structure du projet, nous mettons tout en place; DevOps mobiles et automatisation de l'assemblage, des tests, de la livraison et de la surveillance; des conseils pratiques pour tous les jours.
Le livre peut être acheté sur le site de la maison d'édition «
DMK Press » (l'option la moins chère!) Et les magasins en ligne
Labyrinth ,
My-Shop.ru ,
Flip.kz ,
Oz.by , ainsi que d'autres magasins en ligne, leur nombre augmente avec la distribution du livre .
Pour la graine (et avec le consentement de l'éditeur) je donnerai un morceau du chapitre 3.
3. Architecture d'application
Nous avons donc déjà appris comment fonctionne Xamarin.Forms et comment réaliser nous-mêmes la conception technique. Maintenant, nous avons une compréhension du modèle de domaine, et il est temps de passer à l'architecture et à la structure de la solution - comment nous distribuerons nos classes dans des dossiers afin qu'il soit plus facile de trouver le code nécessaire plus tard.
3.1. MVVM multicouche
Dans les applications mobiles, une architecture multicouche est traditionnellement utilisée avec la séparation des couches d'accès aux données, de la couche logique métier et de la couche d'affichage de l'interface utilisateur.
Fig. 3.1. Architecture classique à trois niveaux
Étant donné que le modèle architectural MVVM est natif de Xamarin.Forms, il est recommandé de l'utiliser dans des applications mobiles. MVVM décrit la relation entre View (généralement les écrans d'application sont Page), ViewModel et Model.
Fig. 3.2. Modèle MVVM
Ainsi, l'architecture typique d'une application basée sur Xamarin.Forms sera la suivante:
Fig. 3.4. Architecture d'application de base sur Xamarin.Forms
Dans ce livre, nous nous concentrerons sur l'architecture présentée, car c'est un classique pour Xamarin.Forms. Chacun des modules sera décrit plus en détail dans les sections suivantes.
3.2. Décomposition en couches
Si nous rappelons les bases, un programme est un ensemble d'algorithmes et de données. Les applications mobiles ne font pas exception. L'architecture vous permet de séparer les algorithmes et les données à des fins diverses les uns des autres.
Dans les applications mobiles, les types d'algorithmes suivants peuvent être distingués conditionnellement:
- contrôler le comportement et l'apparence des composants de l'interface utilisateur (interface utilisateur, interface utilisateur);
- logique d'interaction utilisateur et scénarios commerciaux (logique métier, BL);
- logique d'acquisition, de stockage et de transformation des données (couche d'accès aux données, DAL);
- fonctionnalité de la plate-forme non liée à l'interface utilisateur (plate-forme).
- Il existe également de nombreux algorithmes supplémentaires tels que l'initialisation d'application ou des classes et extensions auxiliaires supplémentaires (extensions), mais ils ne sont pas si faciles à classer, car ils sont spécifiques aux projets, aux équipes et aux bibliothèques sélectionnées.
- La structure d'un projet vide sur Xamarin.Forms est illustrée ci-dessous. De plus, il est important de comprendre dans quels dossiers placer les fichiers, afin que le code reste simple.
Fig. 3.5. La structure d'un projet vide sur Xamarin.Forms
Si nous procédons à la façon de maintenir le code «en bon état» (dette technique minimale), il est important pour l'équipe de suivre des accords uniformes. Ci-dessous, nous considérerons un exemple de séparation des classes en dossiers, qui correspondra à l'architecture décrite.
Mais d'abord, rappelons les données. Il est important de comprendre lequel sera discuté. Il y a des données qui proviennent du serveur (objet de transfert de données, dto), mais il y a des données qui sont traitées dans l'application (modèles, entités, objets de données). Notez qu'il est plus pratique de recevoir immédiatement des données prêtes à l'emploi de la couche DAL afin de pouvoir travailler plus facilement avec elles. Nous en parlerons plus en détail à la section 3.5.
De plus, dans les applications mobiles, il n'y a pas une telle quantité de données qu'il est nécessaire de créer des modèles épais et de «barbouiller» la logique métier (une approche de grands systèmes d'entreprise). Assez de POCO conventionnel (Plain Old CLR Object) sans aucune logique. Ainsi, toutes les données finies proviennent de la couche DAL, les classes DTO dont les autres couches ne sont pas conscientes sont cachées à l'intérieur. Voici la différence entre les modèles épais et les objets POCO.
Fig. 3.6. La différence entre un modèle «épais» et un objet POCO
De plus, nous respecterons la notation suivante:
- Objets de données - modèles de données plats (POCO) avec lesquels la logique métier continuera de fonctionner.
- Services de données - services d'acquisition, de transformation et de stockage de données.
- Services aux entreprises - services de traitement des données et scénarios commerciaux.
- Services de plateforme - services pour un accès direct aux fonctionnalités de la plateforme.
Je serais reconnaissant pour vos commentaires et commentaires, restez en contact!