MVVM et ViewModel : comment organiser votre code d'app en tant que développeur (Flutter, iOS, Web)

[@kalaatangane8596]

Vraiment mercie beaucoup cette vidéo m'a fait revoir l'architecture de mon système. Il est donc claire que mes vues étaient mélangé avec la logique et comme vous l'avez dis dans la vidéo, trouver facilement où vient un problème me prennait beaucoup de temps mais avec cette architecture waouh !!! tout mon code devient très très très visible et facilement maintenable. J'ai vu cette vidéo à sa date de sortie et après l'avoir visionné je suis allé refaire tout mon code et vraiment je suis très satisfait. Il fallait donc absolument que je te le fasse savoir pour te remercier. D'où mon commentaire

[@PurpleGiraffe]

Avec plaisir Kala, content d'avoir pu aider! Si tu appliques ces principes sur tes projets tu gagner en efficacité systématiquement. Dans le cours je montre aussi comment y intégrer la notion de tests auto pour avoir la majorité de ton code couvert

[@maths0714]

Hello, merci pour la vidéo ! Je débute dans ce domaine, mais du coup ça veut dire que si on a une app qui ne reçoit aucune donnée ni n'en envoie (API, etc.) on a pas besoin d'un Model ? Admettons j'ai seulement un utilisateur qui rentre des données demandées pour qu'elles soient calculées et affichées après sous une autre forme (chart, list...) j'aurais seulement besoin d'un viewModel + mes vues ?

[@somplesi]

Super cours riches et complets je confirme

[@PurpleGiraffe]

Merci @somplesi, ça me va droit au ❤️ et au code ! Happy coding :)

[@xaviersoh]

Très bien expliqué . Merci

[@PurpleGiraffe]

Merci Xavier! Happy coding :)

[@KaiyASpotify]

Bonsoir, je suis en seconde année de BTS, Le MVVN est une sorte de MVC plus organisée ?

[@PurpleGiraffe]

Oui, on peut dire ça mais ça reste un raccourci. Le MVVM est un autre découpage des responsabilités, plus précis et qui évite le problème principal du MVC : le contrôleur géant. Le soucis avec le MVC c'est que le contrôleur gère quasiment tout et devient rapidement une usine à gaz si on ne fait pas attention.

[@KaiyASpotify]

@@PurpleGiraffe Clair et précis ! Merci ;)

[@Anis-fo6pc]

Merci pour cet extrait. J’ai lu qu’il ne faut plus utiliser le viewModel avec les nouvelles générations d’interfaces, comme Flutter, SwiftUI, JetpackCompose, … Est-ce que ce cours aborde le sujet ?

[@PurpleGiraffe]

J’aimerais bien lire cet article. Pour moi les view model sont toujours intéressants, même avec des frameworks déclaratifs. La séparation des responsabilités rend le code modulaire et facilement testable, peu importe l’outil graphique utilisé. Tu as le lien de l’article où il est déconseillé d’utiliser des view models avec SwiftUI ou Flutter ?

[@baptiste_parmantier]

On en revient au bon vieux MVC ♥

[@PurpleGiraffe]

Merci Baptiste pour ce retour, le MVC est un excellent point de départ. Le soucis est surtout qu'un seul contrôleur n'est généralement pas suffisant pour découper correctement toute la complexité de certains écrans. Les modèles plus récents de type MVVM, Clean, ... gardent la logique de séparer les vues, les données et de créer des contrôleurs intermédiaires ; mais ils créent surtout plus de contrôleurs, avec chacun qui a un rôle précis. Dans cette vidéo je présente le ViewModel, qui est un mini contrôleur pour une seule vue. Mais il va fonctionner de pair avec d'autres contrôleurs (gestion des données distantes, gestion des données, locales, gestion de l'utilisateur actuel, etc.).

[@baptiste_parmantier]

@@PurpleGiraffe Effectivement ! Je suis développeur web spé Typescript et j'utilise le framework backend MVC Adonis (qui est très très proche de Laravel mais de mon point de vu, en mieux sur beaucoup de points) mais généralement je restructure le classique MVC avec une architecture hexagonale avec dans chaque fragments des sites de mini MVC. Lorsque je parlais de "MVC" suite à ta vidéo, j'y voyais une différence au fait que la vue ne sera pas "rendue" par le controller mais plutôt que celui-ci sert de boite à outil "tampon" entre les data (model) et l'interface (view) 😉

[@PurpleGiraffe]

@@baptiste_parmantier 100% d'accord avec toi : le rendu de la vue sera fait par la vue elle même et le ViewModel est bien là pour simplifier le code de nos vues. En ce sens on peut le considérer comme un contrôleur spécifique à cette vue. Merci pour ce débat intéressant :)

[@baptiste_parmantier]

@@PurpleGiraffe Avec plaisir ! 😉