MVVM n’impose pas une architecture utilisant l’injection de dépendances mais il se trouve que cette stratégie se marie bien avec l’esprit de MVVM. Seulement la DI est lente…comment s’en sortir ?
L’injection de dépendances
Hors de question d’entrée ici dans le détail de ce qu’est l’injection de dépendances ! Noël approche à grand pas, les vacances d’hiver et tout ça, et j’en ai déjà parlé en long et en large !
Juste disons ici que l’ID ou la DI (en anglais) utilise à tour de bras la réflexion de C#, c’est génial mais c’est lent et c’est connu. Quand tout un soft fonctionne de la sorte sur un gros PC de gamer on ne voit rien et c’est cool. Quand les mêmes stratégies sont utilisées avec des Apps de plus en plus grosses sur des smartphones ou des tablettes là ça commence à se sentir...
Le manque de réactivité est le monstre hideux que tout développeur doit absolument terrasser sur smartphone. En desktop on a payé déjà, il y a longtemps, certains même n’étaient pas nés ou encore en couches et ne peuvent pas s’en rappeler… Mais on a eu notre époque du “gratte bit” (à ne pas confondre avec un tic qui commence à l’adolescence). Il fallait chercher le moindre octet en vadrouille, le trucider, revoir les algorithmes pour gagner deux instructions machines… Bref ce temps-là a aussi existé dans le monde des PC mais il est révolu (ce qui ne veut pas dire qu’il ne faut plus être parcimonieux !). Et tout naturellement les unités mobiles ont pris le relai. Certes elles sont de plus en plus puissantes, avec beaucoup de RAM, des processeurs multi-cœurs etc. Mais manger du temps machine qui pourrait être évité ça se paye. Ça se voit. C’est moins réactif…
Ode à la paresse
Qu’il est doux de ne rien faire quand tout s’agite autour de soi…
Pareil pour une App !
La paresse paye toujours. Elle est bonne conseillère et force à utiliser l’esprit plutôt que la force brute. Le sage est paresseux. L’App bien écrite aussi.
Paresseux en anglais cela se dit Lazy. Comme la classe du même nom en C#… Une classe générique. Lazy<classe> donc.
La classe c’est d’être Lazy, être paresseux c’est la classe, etc, on peut tourner autour du truc mais rien de très hilarant non plus, tout le monde n’a pas fait l’école du rire il faut en convenir.
Comment être paresseux ?
Je veux bien que vous essayez de suivre mes conseils à la lettre et que certains tentent déjà l’auto-hypnose pour se détendre… mais bon rappelez-vous … je viens de le dire : en utilisant Lazy<classe> !
En introduction je parlais d’injection de dépendances, et chez les moins endormis je vois qu’une question vous démange : quel rapport ?
Ben aucun. J’ai loupé le 1er avril je me rattrape avant la fin de l’année, j’ai le droit.
Enfin si. En appliquant MVVM avec de la DI, il y a plein de services, de trucs et bidules qui sont fournis aux constructeurs. La DI va continuer à utiliser la réflexion, mais ses mécanismes internes vont aussi l’obliger à créer les instances de tout ce petit monde. Qui est loin d’être utilisé à 100% et encore moins tout de suite.
En utilisant Lazy<IService> au lieu de IService directement, on va laisser la DI faire son job mais au moins on va éviter toutes les créations d’instances en cascade qui peuvent en découler.
La page arrivera plus vite à l’écran, on aura gagné en réactivité… pour pas cher, juste avec un peu de paresse…
Un exemple :
public class MainViewModel {
private Lazy<ISomeRepository> _lazySomeRepository;
private ISomeRepository SomeRepository => _lazySomeRepository.Value;
public MainViewModel(Lazy<ISomeRepository> lazySomeRepository){
_lazySomeRepository = lazySomeRepository; }
public void RefreshData(){
var allData = SomeRepository.GetAllData();
.....
}
}
Ici ce sont des Lazy<ISomeRepository> qui sont donc enregistrés dans le système d’injection de dépendances. On récupère ainsi juste des conteneurs paresseux et les instances ne sont créées que lorsqu’on s’en sert…
Bien entendu même en dehors de MVVM ou en dehors de tout contexte de DI la construction paresseuse par Lazy peut être utilisée pour éviter les initialisations inutiles.
Conclusion
Un peu de paresse par ci, un peu de paresse par-là, et ce sont des tas d’instances qui au lieu d’être construites tout de suite vont être créées dans le temps, quand il y en aura besoin. Cela finit par faire une grosse différence et offre une meilleure réactivité à vos Apps, voire une empreinte mémoire minimum puisque l’utilisateur ne se servira pas forcément de tout tout le temps.
Maintenant ce n’est pas une panacée non plus. Certains services auront tout intérêt à être créé tout de suite ou le plus vite possible même avec un petit délai car ils seront utilisés tout au long de l’application. Ou bien ils se devront de répondre immédiatement en cas de sollicitation.
Bref comme d’habitude il n’est pas question de généraliser, chaque développeur doit réfléchir et prendre les bonnes décisions en accord avec l’App qu’il construit !
Paresseux oui, dilettante non !
Stay Tuned !