[2/4] Architecture Cross-Plateformes Xamarin: couche métier

Auteur du billet de blog : Rudy Spano - Neotech Solutions

Rudy Spano

Consultant .Net
  Publié le mercredi 1 février 2017

Expert technique .Net passionné par tout ce qui est innovant en environnement Microsoft. De la mobilité, du client lourd (Xaml Applications) mais aussi une petite pointe de Web...

Contexte

 

L’assembly BookStore.Business est une dll de type Portable Class Library (l’une des solutions plébiscitées pour partager du code Cross-plateforme).

On y trouve différents namespaces détaillés ci-dessous.

 

Namespaces Providers, DAL

Ce namespace contient des classes à l’image de BookProvider qui servent d’intermédiaire entre le « Front » de l’application et la couche d’accès aux données/la source de données.

 

++ Ajouter le code métier de votre application à cet endroit.

-- Ne pas dupliquer le code métier. Utiliser des méthodes privées chargées de mutualiser ces règles : ValidateBook partagée entre AddBook et UpdateBook.

-- Ne pas dupliquer les traitements entre les appels de méthodes via l’utilisation des champs privés en tirant pleinement profit des concepts de la POO : méthode d’initialisation si nécessaire à ne jouer qu’une fois, gestion d’état, cache…

?? Ne pas nécessairement compléxifier votre architecture en créant des librairies métiers de plus bas niveau ou couches d’accès aux données isolées si la complexité de votre application ne le justifie pas. Beaucoup d’applications mobiles se contentent d’appeler des Api Web...  

++ Abstraire la couche d’accès aux données afin que les consommateurs puissent simuler les dépendances fortes pour des besoins de tests automatisés.

 

Namespace DTO

Ce namespace « Data Transfer Object » définit nos objets métiers qui sont exposés aux Assemblies utilisant la couche métier. Nous y trouvons comme exemple notre classe Book

 

?? Faciliter la construction de ces objets grâce à des patterns de construction : constructeur paramétré, Factory, Builder, …

-- Ne pas lier ces classes à des dépendances externes.

-- Ne pas mettre du code métier dans ces classes.

-- Eviter d’abstraire complètement ces classes via des interfaces (IBook). Souvent inutile et ajoute de la complexité.

-- Eviter l’héritage dans ces classes. Mettons que l’on décide que notre application gère aussi des journaux. On serait tenté de créer une classe parente commune ItemBase qui porterait les propriétés Titre, Date, PagesCount. Par la suite on décide de se « mettre à la page » :) et de gérer les supports numériques: films, podcasts etc… Bref, ce type d’héritage est souvent accompagné de beaucoup de dérives au fil de l’évolution de l’application. La propriété PageCount n’aura plus de sens ici…

++ Mutualiser le code des classes/méthodes via la création et l’implémentation d’interfaces ciblées. Les classes livres et journaux peuvent implémenter une interface simple IPageable qui pourra être manipulée par une classe métier qui définit une méthode CalculateReadingHoursAverage(IPageable pageableItem).

 

Namespaces Helpers, Extensions

Ces 2 namespaces proposent des méthodes qui mutualisent des opérations répétitives dans un projet (couche métier ou non selon le scope).

Un Helper est souvent une classe statique auto-suffisante à l’image de la classe TitleFormatter qui expose par exemple une méthode Format() chargée de passer tout le texte en majuscule et d’enlever les espaces superflus.

Une classe d’extension est une classe statique qui fournit des méthodes d’extensions à un type ou une classe pour laquelle on n’a pas accès au code source.

 

++ Limiter le scope des helpers et classes d’extensions. Ces classes doivent être définies à l’emplacement adéquat.  Par exemple, certains helpers par définition ne concernent que la couche de présentation…

-- Ne pas dépendre d’une autre classe/dépendance externe.

-- Eviter les namespaces « fourre-tout » pour ces classes : « Utils », « Misc », …

?? Essayer de proposer vos méthodes d’extensions à un type/une interface de haut niveau. Une méthode d’extension sur IEnumerable sera plus visible et utilisable que sur List.

 

Namespace PlatformContracts

Ce Namespace contient les interfaces manipulées par la couche métiers qui sont implémentées spécifiquement. Dans notre exemple d’architecture, ILocationProvider est implémentée pour chaque plateforme spécifique : UWP, iOs et Android tandis que ISettingsProvider est implémentée par la couche Cross-Plateforme Xamarin Books.Forms qui fournit un mécanisme unifié. Il est très important que la couche métier utilise des abstractions de ces dépendances.

 

?? Selon la complexité du projet, isoler ce namespace dans une assembly dédiée peut se justifier.

 

Suite

Dans la prochaine partie, je vous détaillerai le contenu de la couche de présentation Xamarin Forms.

Commentaires