Skip to main content

Exemple d’erreur MVVM très gênante pour le Garbage Collector

Quand on utilise MVVM, il faut se rappeler que l’on exploite un pattern qui a plus de 10 ans. En 10 ans, il y a d’énormes évolutions dans le monde du développement. Que ce soit dans le bon ou le mauvais sens.

Régulièrement, il m’arrive de tomber sur une implémentation qui donne bien du fil à retordre au Garbage Collector. Tellement, qu’il ne peut pas faire correctement son travail.

De quoi s’agit-il ?

Certains pensent que pour avoir un MVVM propre et correctement architecturé, le VieModel doit implémenter une interface IViewModel et que la View doit implémenter une interface IView.

Voici les interfaces en question.


public interface IView
{
    IViewModel ViewModel { get; }
}

public interface IViewModel
{
    IView View { get; }
}

Quel est le problème ?

Concernant la logique, ou la modélisation de la chose, au premier abord le problème ne saute pas aux yeux. Mais que se passe-t-il quand vos objets ne sont plus utiles et que le Garbage Collector doit passer sur ceux-ci ?

La View référence le ViewModel et le ViewModel référence la View. Il y a là une référence cyclique. Tant que l’un a une référence à l’autre, il est impossible de libérer les ressources de l’un ou de l’autre.

Comment s’en sortir ?

Bien évidemment, vous pouvez mettre les deux propriétés View et ViewModel à null, mais votre interface ne le prévoit pas. On peut changer l’interface et appliquer un code pour libérer les références à chaque implémentation (si cette logique est oubliée sur un couple View VieModel, il y a là un risque de se retrouver dans la même situation).

La solution la plus simple est d’admettre que dans un MVVM, il n’est pas toujours utile que le ViewModel connaisse sa View. Surtout si vous êtes dans une logique moderne de View First. Ce qui est le cas aujourd’hui pour la plupart des plateformes (UWP, Xamarin.Forms, Universal Apps, WPF…)

On peut donc se débarrasser de l’interface IViewModel.

Conclusion

Toujours vérifier l’impacte d’un Pattern sur ses ressources (RAM, CPU…). Sur ce point, le profilage via Visual Studio peut s’avérer très utile.

Jérémy Jeanson

Comments

You have to be logged in to comment this post.

Cookies Cookie Policy

This website uses cookies to allow us to enhance your browsing experience (accessibility settings). If you continue to use this website you agree to our use of cookies.