Je crée une nouvelle application avec Flutter, et j'essaie de la concevoir, en séparant la logique métier de la vue.
J'ai lu sur Bloc et MVVM (je sais qu'il existe d'autres modèles mais ce sont ceux que j'ai préférés), mais je ne comprends pas les différences entre eux. Ils me ressemblent à peu près.
Quelqu'un peut-il m'aider à les comprendre?
3 Réponses :
En regardant cette illustration pour MVVM ( source ):
Vous pouvez voir qu'il existe des modèles de données et de logique métier distincts. Cependant, en utilisant BLoC, il n'y a pas vraiment de distinction comme ça. Les classes qui gèrent la logique métier gèrent également les données, qui peuvent également s'appliquer à MVVM .
Pour être honnête, il n'y a vraiment pas beaucoup de différence. L' élément clé à retenir est le même pour les deux: isoler la logique métier de l'interface utilisateur. Par conséquent, la mise en œuvre de l'un ou l'autre des deux sera très similaire, c'est-à-dire en utilisant Stream et StreamBuilder .
De plus, il existe des packages qui facilitent le travail avec Stream , par exemple rxdart qui est ce que l'équipe Flutter utilise en ce qui me concerne.
Si je comprends ce que vous dites, est-ce que Bloc est une implémentation de MVVM?
@niegus Vous pouvez le mettre comme ça si vous le souhaitez.
Ils ne sont pas tout à fait les mêmes, en fait ... MVVM implique des liaisons de données entre la vue et le viewmodel, ce qui signifie qu'en pratique, les objets de vue sont principalement ceux qui commandent le viewmodel. MVVM me semble une simplification de MVC, pour montrer le modèle "tel quel" dans les coulisses. Par exemple, Xamarin utilise largement MVVM et les contrôles à l'écran tels que les cases à cocher, les entrées de texte, etc. modifient tous la vue du modèle en arrière-plan.
Vous commencez peut-être déjà à voir un problème ici: si vous modifiez l'interface utilisateur, vous devrez peut-être également modifier le MV. Supposons que vous ayez un numéro d'entrée qui doit être compris entre 0 et 255, où mettez-vous cette logique? Eh bien, sur MVVM, vous mettez cette logique sur la vue. Mais vous devez également mettre ces verrous sur la vue du modèle pour garantir la sécurité des données. Cela signifie beaucoup de réécriture de code pour faire la même chose. Si vous décidez de changer cette plage, vous devez changer à deux endroits, ce qui rend votre code plus sujet aux erreurs. Avertissement : il existe des solutions de contournement pour cela, mais c'est beaucoup plus compliqué qu'il ne devrait l'être.
D'autre part, BLoC fonctionne en recevant des événements et en émettant des états. Peu importe (bien que cela puisse) d'où vient l'événement. En utilisant le même exemple que ci-dessus, la vue signalerait un événement au bloc / contrôleur avec "hé, mon numéro a changé!", Le bloc traiterait alors ce nouvel événement et, si cela était approprié, émettrait un signal vers l'interface utilisateur: " hey UI! Tu devrais changer! J'ai un nouvel état pour toi! ". Ensuite, l'interface utilisateur se reconstruit pour présenter ces modifications.
Pour moi, l'avantage de BLoC par rapport à MVVM est que la logique métier peut être entièrement découplée de la vue, ce qui est globalement une meilleure façon de faire les choses. Comme notre développement logiciel moderne nécessite de plus en plus de changements dans l'interface utilisateur (différentes tailles d'écran, densités, plate-forme, etc.), le découplage du côté de l'interface utilisateur des modèles est une fonctionnalité fantastique pour la réutilisation du code.
BLoC et MVVM semblaient être différents lorsque BLoC a été introduit, mais ces différences se sont estompées à mesure que les implémentations BLoC changeaient au fil du temps. À l'heure actuelle, la seule vraie différence est que BLoC ne spécifie pas une logique de présentation et une logique métier distinctes, ou du moins il ne le fait pas de manière évidente. La logique de présentation est la couche qui comprend les interactions entre les éléments de l'interface utilisateur et la partie métier de l'application (travail de présentateur dans MVP). Certaines implémentations BLoC placent la logique de présentation dans BLoC, d'autres dans l'interface utilisateur.
La NOUVELLE CHOSE dans BloC était qu'il ne devrait exposer aucune méthode. Au lieu de cela, il n'accepterait les événements qu'à travers son ou ses puits exposés. C'était pour des raisons de réutilisation du code entre les applications Web Angular Dart et les applications mobiles Flutter. Ce concept a été récemment abandonné car nous n'écrivons pas vraiment d'applications Web Angular Dart et il est moins pratique que les méthodes classiques. À l'heure actuelle, les blocs dans le package BLoC officiel exposent des méthodes comme la bonne vieille VM.
Certains diraient que BLoC devrait exposer un Stream d'objets d'état complets, tandis que VM peut exposer plusieurs Streams, mais ce n'est pas vrai. L'exposition d'un flux d'états est une bonne pratique dans les deux approches. Au début, les présentations officielles de Google BLoC présentaient également des BLoC mis en œuvre à l'aide de plusieurs flux de sortie.
Une différence intéressante qui semblait être une chose était que BLoC devrait communiquer via des événements non seulement avec l'interface utilisateur, mais aussi avec différentes parties de l'application. par exemple, il doit recevoir un événement après avoir reçu une notification Firebase ou lorsque les données du référentiel changent. Bien que cela semble intéressant, je n'ai jamais vu une telle implémentation. Ce serait étrange d'un point de vue technique (le référentiel devrait connaître tous les BLoC qui l'utilisent ???). Bien que je pense essayer une telle implémentation qui serait basée sur EventBus mais qui est complètement hors sujet :)
BLoC est un modèle conçu spécialement pour Flutter en fonction de l'architecture spécifique de Flutter. Et oui - ils sont à peu près les mêmes