Dans une application créée avec MVVM, supposons qu'une valeur soit stockée dans Date in Model (une base de données).
Lors de son affichage à l'écran,
--Format de aaaa / MM / jj HH: mm
--La zone horaire est le Japon
Les spécifications sont les suivantes.
En ce moment, ** Cette conversion et cette mise en forme doivent-elles être effectuées dans la couche ViewModel? Ou devrait-il être fait dans la couche View? ** ** C'est le thème abordé dans cet article.
Ce qui suit est ma propre considération.
Pour conclure d'abord, Je pense que ** en principe, il vaut mieux le faire dans la couche ViewModel ** Je pense.
Cela semble être de la responsabilité de "comment montrer", et en pratique, c'est souvent un simple code pour écrire une extension, donc je pense que certaines personnes pensent le faire avec View ...
Dans le cas de l'édition Date → Chaîne, en plus des paramètres régionaux, "Le fuseau horaire correspond-il aux paramètres du terminal? Est-il corrigé au Japon?" Ou "Et si la valeur issue de l'API est inappropriée comme date et heure?" En effet, cela inclut souvent des problèmes dans le domaine du domaine qui vont au-delà du simple "comment montrer".
Il en va de même pour les valeurs numériques. Par exemple, si vous modifiez simplement la valeur numérique "1234567" avec une virgule telle que "1 234 567", je pense qu'il n'y a pas de problème en tant que responsabilité de la couche View, mais s'il s'agit d'une devise, c'est généralement un problème dans le domaine du domaine. Puisqu'il sera inclus, je pense qu'il vaut mieux en faire la responsabilité de la couche ViewModel.
En d'autres termes, il convient de le classer en tant que couche ViewModel dans le cas d'un traitement d'édition qui inclut des problèmes dans la zone de domaine, et la couche View ** dans le cas d'une édition de format simple qui ne l'inclut pas.
Je pense qu'une telle division a l'avantage de ** faciliter l'écriture de tests unitaires pour la logique qui inclut des problèmes dans le domaine du domaine **.
Exemple de modèle MVVM introduit pour éliminer FatViewController dans les grandes applications iOS