J'ai récemment décidé de commencer à apprendre le développement iOS. À cette fin, je lisais Programmation iOS: The Big Nerd Ranch Guide . Dans le livre, les auteurs décrivent un modèle de conception MVCS - Model-View-Controller-Store , l’idée de base étant que, dans la mesure où de nombreuses applications utilisent plusieurs sources de données externes, conserver la logique de la demande dans le contrôleur peut devenir très compliqué. propose de déplacer toute la logique de requête hors de l’automate et dans un objet séparé.
En bref pour citer le livre
Model-View-Controller-Store place la logique de requête dans un objet séparé, que nous appelons magasin (Figure 28.4). L'utilisation d'un objet magasin minimise le code redondant et simplifie le code qui extrait et enregistre des données. Plus important encore, il déplace la logique pour traiter avec une source externe dans une classe ordonnée avec un objectif clair et ciblé. Cela rend le code plus facile à comprendre, ce qui facilite la maintenance et le débogage, ainsi que le partage avec les autres programmeurs de votre équipe.
Et
La bonne chose à propos des magasins asynchrones est que, même si de nombreux objets effectuent beaucoup de travail pour traiter une demande, le flux de la demande et sa réponse se trouvent au même endroit dans le contrôleur. Cela nous donne l'avantage d'un code facile à lire et à modifier.
Je voulais en savoir plus sur ce modèle et voir ce que les autres pourraient en dire, mais lors de la recherche en ligne, les seules références que je pouvais trouver étaient celles du même livre (le modèle est-il peut-être connu sous un autre nom?).
Pour moi, la logique de l'auteur semble avoir du sens, et cela semble être une extension logique du modèle MVC classique, mais c'est peut-être parce que je n'ai pas vraiment beaucoup d'expérience avec le modèle MVC dans la pratique (mis à part une incursion dans le développement iOS). sorte de MVV utilisé avec backbone.js (c'est-à-dire, si vous le considérez MVC )).
J'espérais que peut-être une personne plus expérimentée pourrait nous aider à déterminer s'il existe des défauts / problèmes évidents avec le modèle MVCS qui me manque.
la source
Réponses:
"Store", dans le cas des modèles de conception MVCS, a tendance à pencher vers la logique de stockage. Dans le cas d'iOS, il s'agit généralement d'une implémentation Core Data. Si vous créez un modèle Core contenant des données dans Xcode, vous verrez l'aspect "Stocker" de ce modèle de conception dissimulé dans la classe AppDelegate.
Pour passer à ce niveau, je vais souvent créer une classe de gestionnaire de singleton qui gère la configuration de la pile de données de base et traite de tous les extractions / sauvegardes associées à la pile. Comme le dit la citation que vous avez mentionnée, il est très facile non seulement d’appeler ces méthodes, mais également de les ajuster si nécessaire, au lieu d’avoir des options de sauvegarde / récupération dans tous les contrôleurs de vue.
Le paradigme "Store" ne se limite toutefois pas aux données de base. Votre magasin peut être juste un service Web. Vous avez peut-être une classe qui interagit avec Facebook, Twitter, Yelp ou une autre API basée sur REST. J'ai trouvé (et de même suivre la tendance) que ces types de classes ont également pour nom Manager. Ils gèrent littéralement tous les détails internes afin que vos autres classes puissent simplement entrer ou sortir exactement ce dont elles ont besoin.
En ce qui concerne les défauts évidents ou les problèmes avec ce modèle de conception ... Comme pour tout modèle de conception, le problème le plus criant est de vous assurer que vous avez configuré votre projet de manière à ce que le paradigme évolue. Surtout avec un modèle de conception qui est nouveau pour vous, cela peut parfois être la partie la plus difficile. L'avantage de diviser votre logique "Store" dans sa propre classe est le fait même qu'il facilite grandement la maintenance du code.
la source
'Store' dans ce contexte ressemble beaucoup à un référentiel ou à un service . Dans ce cas, il s'agit d'un modèle extrêmement commun. Les défauts / problèmes varieront avec votre implémentation et le domaine du problème.
De manière générale, il semble que le livre utilise "Store" pour représenter un niveau de logique métier + un niveau de logique d'extraction de données qui gère un ensemble de données qui peut ou non faire partie de votre application.
Par exemple, envelopper l'API Twitter dans un 'Store' est un bon moyen de compartimenter cette logique.
Après mûre réflexion
À l'aide de cette définition de MVC (qui, à mon avis, est plutôt parfaite), le «magasin» est en réalité un sous-ensemble du modèle. La délimitation entre le fait qu'il s'agisse d'une extension de MVC ou d'un motif d'extraction de données n'est pas très utile. Ils finissent par ressembler au même code.
En bout de ligne, je pense que vous irez bien en suivant les conseils qu’ils suggèrent (semble bien dans l’ensemble).
la source