Abstraction modèle-contrôleur avec Core Data

Question

En apprenant à connaître Core Data, j'ai remarqué comment (dans les modèles de Xcode) Apple utilisait directement les classes de requêtes à l'intérieur du contrôleur de vue. Cela semble être un mauvais MVC (avoir une logique d'accès à la base de données directement dans le contrôleur de vue). Serait-il judicieux d'abstraire ce type d'actions vers une suite distincte de classes qui obtiennent les données de la base de données et les renvoient au contrôleur de vue qui les appelle ?

EDIT-

Donc, pour être clair, quand je dis "types d'actions", je parle spécifiquement des opérations CRUD. Mais si vous avez des idées sur d'autres choses qu'un "contrôleur de modèle" pourrait faire, je serais intéressé de les entendre.

Answer 1

C'est une question d'opinion, et souvent oui, les modèles sont la forme la plus simple d'exemple de travail. Il est difficile de faire en sorte qu'un modèle génère plusieurs fichiers, par exemple.

Oui, personnellement, je crée généralement une sous-classe NSManagedObject distincte. J'aime avoir un objet _MySubclass qui a tous les éléments générés automatiquement, puis faire en sorte que le modèle fasse référence à MySubclass qui a une logique métier basée sur le modèle (vous pouvez utiliser mogenerator ou d'autres méthodes pour faire cela aussi si vous le souhaitez). Une autre façon de voir les choses est de les considérer comme des "contrôleurs de modèle" et des "contrôleurs de vue".

Answer 2

C'est une très bonne question et la réponse dépend probablement de votre situation. Les puristes de l'architecture insisteraient peut-être sur des contrôleurs de modèle séparés, et cette approche présente de nombreux avantages. Cependant, je me retrouve parfois à utiliser des valeurs clés lorsque je réalise une vue simple. Lorsque les choses sont plus complexes, par exemple lorsque vous codez le même modèle pour Mac et iOS, le fait d'avoir des contrôleurs de modèle séparés vous permettra de réutiliser une grande partie du code. Lorsque vous devez diverger, les catégories Obj C sont un moyen très propre d'étendre la fonctionnalité sans ajouter beaucoup de frais généraux. Personnellement, je préfère les catégories à une sous-classification étendue.

Depuis la sortie de NSFetchedResultsController, mes classes de modèles sont plus légères. Il y a beaucoup de nuances à cela et l'expérience vous aidera à trouver la meilleure solution pour votre application. J'ai également constaté que l'écriture de tests unitaires dès le départ vous aidera à résoudre les problèmes et à valider votre conception, ou vous renverra à la planche à dessin :)