1
votes

Où dois-je créer une instance de modèle pour une vue dans SwiftUI?

Je suis nouveau sur MVVM. Pour autant que je sache, je dois éviter d'utiliser le code de modèle dans une structure de vue.

Dans mon cas, j'ai 2 vues, MainView et ChildView. MainView n'a pas de ViewModel. Mais ChildView a un ViewModel (par exemple ChildViewModel). Étant donné que ChildViewModel est utilisé uniquement dans ChildView, je n'ai donc pas enregistré l'instance de modèle sur EnvironmentObject ou je n'ai pas transmis l'instance à MainView, car MainView n'utilise pas du tout le modèle.

I pensez, le meilleur moyen est que ChildView crée sa propre instance du modèle par lui-même comme ci-dessous. Mais je ne sais pas si cela va ou non. Cela enfreint-il les règles de MVVM?

struct ChildView: View {
    @ObservedObject var childViewModel = ChildViewModel()

    var body: some View { ... }
}

Merci d'avance.


0 commentaires

3 Réponses :


0
votes

Cela ne viole pas le modèle MVVM. Si votre vue principale a besoin de transmettre certains paramètres à la vue enfant, elle doit le faire en utilisant les paramètres init. Cependant, une chose à noter est que chaque fois que vous accédez à la vue enfant à partir de votre vue principale, une nouvelle instance de ChilViewModel sera créée. Dans les cas d'utilisation, où cela n'est pas acceptable, un modèle de vue est créé dans la vue parente et transmis à la vue enfant pour conserver la même instance chaque fois qu'un utilisateur accède à la vue enfant. Les deux ne violent pas le modèle MVVM. J'espère que cela répond à votre question.


0 commentaires

1
votes

Est-ce que cela enfreint les règles de MVVM?

Non, ce n'est pas le cas, car MVVM à propos de la "séparation des responsabilités" et le modèle fourni séparent exactement View & ViewModel. De plus, il suit également la règle "injection de dépendances", car vous pouvez utiliser et

ChildView () // avec le modèle par défaut

et

ChildView (childViewModel: ChildViewModel (...)) // un modèle spécifique


0 commentaires

1
votes

Je ne suis pas d'accord avec la réponse acceptée. Je vais fournir mes arguments.

MVVM ne consiste PAS à avoir un objet appelé modèle de vue. La plupart des développeurs MVVM le font juste pour avoir un objet appelé modèle de vue.

parce que MVVM à propos de la "séparation des responsabilités"

Quel modèle de conception ne concerne PAS la séparation des responsabilités?

Pourquoi pensez-vous que la conception du SDK SwiftUI n'assure pas la séparation des responsabilités?

Je dois éviter d'utiliser le code de modèle dans une structure de vue

La structure de la première vue n'est pas une vue, c'est un modèle conforme à la vue.

Par exemple; struct Model: View

Ceci est conçu pour que vous puissiez faire model -> view binding (et éventuellement afficher -> model binding) facilement.

Là sont des annotations telles que @State , @StateObject spécialement conçues pour le prendre en charge.

Par exemple; restitue lorsque @State change, le compilateur vérifie pour empêcher l'accès à l'objet @State depuis l'extérieur de struct Model: View .

En d'autres termes, struct Model: View est le endroit pour écrire des codes de modèle! Par conception!

Notez qu'il s'agit de struct Model , pas de class Model . MVVM ne prend pas en compte le type de valeur. Donc, au lieu de profiter de l'immuabilité du type valeur, MVVM avez-vous pensé qu'un modèle séparé dans un type de référence est une bonne idée? Ce n'est pas le cas.

Je vais le répéter. Un modèle de type REFERENCE pour "séparation des responsabilités".

Il existe des raisons héritées pour lesquelles vous devez créer un modèle de vue distinct. Cela dépend de la conception de la reliure. Il est tout à fait possible que vous ayez besoin d'un modèle de vue séparé pour que la liaison fonctionne dans un langage commun.

Mais Swift n'est pas un langage commun.

Je ne sais pas pourquoi les développeurs de MVVM pensent Les créateurs de SwiftUI SDK sont des idiots et ne savent rien de MVVM. La vérité est que SwiftUI a une conception de liaison si efficace que vous n'avez pas besoin d'un modèle de vue séparé pour décrire la liaison.

Bon sang, même moi, je peux voir que vous bénéficiez désormais de tous les avantages de la liaison et de la vue automatique mise à jour à partir du modèle de type valeur, les fonctionnalités MVVM les plus emblématiques, sans les frais généraux liés à la création manuelle d'un modèle de vue distinct. Et je ne suis pas un développeur MVVM.

SwiftUI crée un modèle de vue par défaut. J'ai vu des tentatives de construction d'un modèle de vue dessus à maintes reprises. Ils ont tous lamentablement échoué, car le modèle de vue est désormais un poids mort.

Vous n'en avez pas besoin, et en fait, vous perdez le support du SDK lorsque vous l'utilisez.

Ou pensez à il de cette façon. SwiftUI supprime UIViewController.

Voyez-vous des développeurs MVC sortir et insister pour que vous créiez un objet Controller séparé?

Le même argument s'applique. Par exemple;

car MVC concerne la "séparation des responsabilités" et a fourni un modèle est exactement séparer View & Control. De plus il suit "la dépendance règle d'injection "également

Ne laissez pas ces mots abstraits vous embrouiller. Il y a des principes de base qui s'appliquent à tout.

Pour votre question, c'est une forme inefficace de MVVM. ChildView doit être votre modèle. Et c'est plus MVVM que ce que ces développeurs MVVM vous ont dit.

Par exemple;

struct ChildView: View {
    @State var value: Value 
    @StateObject var resource: JSON
    var body: some View { ... }
}


0 commentaires