Comprendre la séparation des préoccupations
Objectifs de formation
Une fois cette unité terminée, vous pourrez :
- Expliquer la valeur commerciale de l'adoption de la séparation des préoccupations.
- Utiliser la SOC pour adapter votre solution aux modifications des exigences utilisateurs ou des technologies de la plate-forme.
- Appliquer la SOC au développement de Force.com.
- Déterminer quand appliquer la SOC.
Introduction
Les logiciels, comme les coupes de cheveux, sont souvent considérés comme des choses vivantes qui changent et évoluent au fil du temps. De l'amibe unicellulaire d'un programme de type « Bonjour tout le monde ! » à la complexité d'un logiciel d'entreprise, la gamme et la variété des formes de vie se retrouvent chez les logiciels. Les organismes complexes font évoluer des systèmes dans des buts spécialisés. Les squelettes, les muscles et les organes fonctionnent comme une unité, mais ils interagissent également avec d'autres systèmes au profit d'un tout.
La même chose est vraie des applications complexes d'entreprise. La séparation des diverses préoccupations en différents systèmes ou couches permet de simplifier le code à parcourir et à entretenir. Lorsque des modifications sont réalisées, les impacts et les régressions sur d'autres zones sont réduits et des programmes plus sains et plus adaptables peuvent évoluer.
Vidéo de démonstration Trail Together
Vous souhaitez être guidé pas à pas par un expert pendant que vous travaillez sur cette étape ? Regardez cette vidéo qui fait partie de la série Trail Together.
Séparation des préoccupations (SOC)
L'ours Cody dit souvent : « C’est loin du clavier qu’on écrit le meilleur code ». C’est une autre manière de dire qu'un bon code s'appuie sur une conception soignée et beaucoup d'anticipation. Gardez cette recommandation à l'esprit lorsque vous planifiez l'endroit où vous allez utiliser votre code. Le code est simple quand vous connaissez la voie à suivre !
Un code complexe devient incontrôlable si vous ne le partitionnez pas correctement. Lorsqu'un code est fortement entremêlé, il devient sujet aux erreurs, difficile à maintenir et à apprendre. Avez-vous déjà essayé de déboguer le code spaghetti de quelqu'un ? Et les problèmes empirent lorsque vous invitez de nouveaux développeurs. La création de modules de bibliothèque pour partager des calculs et des processus communs parmi les différentes parties de votre application est souvent la première étape de la réutilisation d'un code, ce qui est évidemment une bonne chose !
La SOC est-elle simplement une façon sophistiquée de parler de réutilisation du code ?
Oui... et non. La SOC nécessite des considérations en amont à propos de la plomberie interne de votre application, notamment les conventions de nommage des classes et les directives de codage. Vous souhaitez que cette planification perdure et soit en quelque sorte autodescriptive pour les autres. Un bon code doit raconter une histoire. L'approche ordinaire pour réutiliser un code consiste à déplacer des fragments de code dès qu'au moins deux zones en ont besoin. Le code est souvent simplement placé dans les classes MyUtil ou dans un autre entrepôt générique. Ce qui est une bonne chose, et très pratique pour un copier-coller !
Quels sont les avantages de la SOC ?
À un niveau élevé, les applications possèdent trois choses : du stockage, une logique et un moyen d’interaction à destination d'êtres humains, de créatures des bois ou d'autres applications. Lorsque vous séparez ces éléments, vous pouvez commencer par définir des couches au sein de votre application, chacune ayant son propre ensemble de préoccupations et de responsabilités vis-à-vis d'autres couches et de l'application générale. Une attention et une gestion soigneuses de ces couches est importante pour adopter la SOC.
- Évolution. Dans le temps, alors que la technologie, la compréhension et les exigences (fonctionnelles et techniques) évoluent, une couche peut avoir besoin d'être étendue, retravaillée ou même abandonnée. À titre d’exemple, voyons comment a évolué la technologie de l'interface utilisateur au cours des 10 dernières années. Combien de framework JavaScript pouvez-vous compter avant de vous endormir ?
- Gestion des impacts. La modification ou l'abandon d'une ou plusieurs couches ne doit pas indûment avoir une incidence sur les autres couches, à moins que ce ne soit intentionnel et lié aux spécifications.
- Rôles et responsabilités. Chaque couche possède sa propre responsabilité et ne doit pas tomber en dessous ni trop étendre cette responsabilité. Par exemple abandonner une technologie ou une bibliothèque client en faveur d'une autre ne signifie pas perdre de la logique métier car cela relève de la responsabilité d'une autre couche. Si les lignes de responsabilité deviennent floues, l'objectif et la valeur de la SOC s'en trouve érodés, ce qui n'est pas bon.
La plate-forme Force.com possède deux approches distinctes vis-à-vis du développement, le codage déclaratif (pointer-cliquer) et le codage traditionnel. Vous pouvez utiliser l'une ou l'autre méthode individuellement ou en conjonction. Les deux approches sont adaptées aux couches SOC standard, comme exposé ci-dessous.
Une présentation
- Déclaratif : Présentations, flux, types d'enregistrement, formules, rapports, tableaux de bord
- Codage : Contrôleurs Apex, Visualforce, Composants Lightning
Couche logique métier
- Déclaratif : Formule, flux, validation, workflow, règles de partage
- Codage : Services Apex, actions personnalisées Apex
Couche d'accès aux données
- Déclaratif : Data Loader
- Codage : SOQL, SOSL, API Salesforce
Couche base de données
- Déclaratif : Objets personnalisés, champs, relations, cumuls
- Codage : Déclencheurs Apex
Quand vous n'avez pas besoin de la SOC sur Force.com
Un avantage essentiel de Force.com réside dans son modèle de développement déclaratif qui vous permet de créer des objets, champs, présentations, règles de validation, workflows, champs de formule et bien plus encore sans écrire une seule ligne de code. Le développement déclaratif est plus rapide et plus facile, et il met déjà en œuvre un degré de la SOC. Si votre application est fortement orientée données, et que vous pouvez fournir une grande partie de votre application de manière déclarative, vous n'avez pas à réinventer la roue : il vous suffit de l'utiliser !
Bien qu'il ne s'agisse pas de code, ce que vous pouvez réussir avec le développement déclaratif est encore très proche d'une couche d'architecture dans votre application, ce que nous aborderons plus en détail par la suite.
Quand utiliser la SOC sur Force.com
Si votre application est orientée processus ou si vous êtes poussé à mettre en œuvre des calculs, des validations plus complexes ou des expériences d'interface utilisateur plus riches, vous vous aventurerez sur les terres du code Apex. Force.com vous offre de nombreux endroits pour placer du code Apex, notamment les déclencheurs, les contrôleurs Visualforce, les API, Apex par lot et les gestionnaires d'e-mails.
Vous pouvez réaliser un énorme investissement en développement et en test de code, mais c'est la logique métier que vous cherchez le plus à protéger. Nous allons explorer plus tard quelques recommandations pour écrire de la logique métier, mais pour le moment, envisagez les instances suivantes pour utiliser la SOC sur Force.com.
- Remplacement ou ajout d'une autre IU à votre application : considérez la quantité de code dont vous avez besoin pour réécrire ou porter ce qui n'a rien à voir avec l'interface utilisateur, mais qui a une incidence sur les fonctionnalités d'insertion, de mises à jour, de validation et de calcul de votre application.
- Fourniture d'une API orientée public à votre logique : évaluez les parties de votre base de code existante que vous souhaiteriez appeler pour mettre en œuvre l'API. Est-ce que l'utilisation de vos méthodes d'action dans vos contrôleurs Visualforce constitue une bonne base pour une API ? (La réponse est non.)
- Évolutivité de votre logique d'application via Apex par lot : si vous devez continuer à fournir une expérience interactive (pour des volumes plus restreints, via votre interface utilisateur existante, comment partageriez-vous la logique entre les deux pour vous assurer que l'utilisateur obtient des résultats cohérents, quelle que soit la taille ?
- Utilisation de méthodes d'action complexes dans vos contrôleurs Visualforce ou Composant Lightning : est-ce qu’une partie de votre code fait plus que transporter simplement des informations depuis et vers l'utilisateur ? Avec Visualforce et les Composants Lightning, vous pouvez partitionner votre code via modèle-vue-contrôleur (MVC), une forme de SOC pour le développement de clients. Toutefois, l'utilisation de contrôleurs pour la totalité de votre code ne garantit pas que vous suivez la SOC selon les termes de votre logique métier.
- Permettre aux nouveaux développeurs de s'y retrouver facilement dans votre base de code : de combien de temps un développeur a-t-il besoin pour apprendre où mettre le nouveau code et trouver le comportement existant ?
Selon l'endroit où vous avez écrit votre code, il est possible que vous soyez en bonne position pour vous attaquer à certains des scénarios ci-dessus. Sinon, ou si vous êtes juste curieux, les unités à venir vont éclairer vos prochaines réflexions. Le tableau suivant peut également vous aider à décider s'il convient d'utiliser ces modèles en fonction de la taille et de la portée de la solution que vous êtes en train de développer.
| Taille de la base de la solution ou du code | Nombre de développeurs | Portée des exigences | Nombre de types de clients et d’interactions | Convient à la SOC ? |
|---|---|---|---|---|
| Petite | 1 à 2 |
|
|
Généralement pas |
| Petite à moyenne | 1 à 6 |
|
|
Mérite d’être envisagé |
| Grande | > 6 |
|
|
Avantages définis |
