[1/4] Architecture Cross-Plateformes Xamarin

Auteur du billet de blog : Rudy Spano - Neotech Solutions

Rudy Spano

Consultant .Net
  Publié le vendredi 27 janvier 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

Le but de cet ensemble de billets est de vous présenter le type d’architecture applicative type que je mets en place sur des projets mobiles cross-plateformes Xamarin Forms toutefois la plupart des principes s’appliquent aussi de façon plus large aux applications XAML « classiques » (WPF, WinRT, UWP, …) à base de MVVM et d’autres principes plus généralement à tous types d’applications .NET.

Comme toujours, il n’y a pas de vérités absolues ! L’idée est de partager avec vous ce que je considère être de bonnes pratiques basées sur diverses littératures et acquises au fur et à mesure de mes expériences (références en fin d'article).

Partons sur un cas classique : Une application mobile simple permettant de lister des livres et de les ajouter à un panier.

Voici un schéma détaillé non exhaustif des différents Assemblies=>Namespaces=>Classes qui définissent cette application fictive :

 

Afin de vous expliquer mes choix, je vais au fil de ces billets vous introduire chaque partie. De plus, pour chacune d’entre-elles : je partagerai avec-vous quelques bonnes pratiques, mauvaises pratiques et pratiques à considérer en respectant le formalisme suivant :

++ {Description bonne pratique}

-- {Description mauvaise pratique}

?? {Description pratique à considérer}

 

Pour commencer, quelques règles générales…

 Vous trouverez, ci-dessous, quelques règles qui me semblent importantes lorsque l’on conçoit une application.

 

Maintenabilité du code 

++ Respecter les principes SOLID. J’insisterais particulièrement sur les concepts de « Single Responsability Principle », « Open-Closed » et « Dependency Inversion Principle ».

++ Respecter le concept de KISS: «Keep It Simple euhh.. S'il vous plait » :). L'idée est de "ne pas partir sur une usine gaz" lorsque ça n'est pas justifié. Mais aussi ne pas complexifier une architecture afin de vouloir tout prévoir ce qui est utopique et qui a surtout un coût important dans les phases de développement et de maintenance.

++ Définir des constantes et/ou classes de Configuration (selon le scope) pour les valeurs transverses utilisées à plusieurs endroits ou par nature soumises à la modification car limitantes ou arbitraires afin d’assurer à la fois la cohérence, la facilité de changement et la compréhension de cette valeur grâce au nommage.

?? Mutualiser votre code tant que possible si et seulement si c’est raisonnable dans la durée. Cette mutualisation ne doit pas être un frein à l’évolution de votre application.

-- Ne pas « surexposer » votre code. Limiter la visibilié de chaque membre/méthode au maximum est un bon réflexe (private, protected, internal, protected internal, public)

 

Nommage

++ Nommer les classes avec l’adjectif adéquat. BookProvider, ImportantEntryRenderer mieux que BookManager, ImportantEntryManager.

++ Nommer les méthodes avec un verbe Adéquat. AddBook, SynchronizeBookList mieux que ProcessBook.

-- Eviter de nommer 2 classes de la même façon. En effet, même si elles font partie de namespaces différents, ajouter un suffixe approprié permet à votre classe d’être mieux identifiée et d’éviter les erreurs et complications (using, namespaces explicites).

-- Eviter les préfixes inutiles du type MyApplicationDTOBook qui dégradent fortement la « découvrabilité ».

 

Références

 

Suite

Dans la prochaine partie, je vous détaillerai le contenu de la couche métier.

Commentaires