est-il faux d'utiliser un J'ai une relation à plusieurs dans une application de base de données iPhone. Chaque fois que des données dans cette relation changent, je dois effectuer un calcul exigeant que les données soient triées. Dans l'exemple de département standard / employés de Apple, cela serait comme déterminer le salaire médian dans un département donné. Chaque fois qu'un employé est ajouté ou retiré de ce département, ou des modifications salariales d'un employé, le calcul médian devrait être réalisé à nouveau.
Garder les données triées et les notifications actuelles et obtenez des notifications lorsqu'il change sonne comme un excellent travail pour Est-ce une mauvaise idée d'utiliser un NsfetchedResultController purement pour la gestion de données, c'est-à-dire sans l'utiliser pour alimenter un utableview ?
NsfetchedResultSluTroller . Le seul "problème" est que je n'utilise pas de utableview . En d'autres termes, je n'ai pas affiche les employés triés dans un utableview . Je veux juste un éventail de personnes triées à jour afin que je puisse les analyser dans les coulisses. (Et, bien sûr, je ne veux pas écrire de tas de code qui duplique une grande partie de NsfetchedResultSluTroller .)
NsfetchedResultController purement pour la gestion de données, c'est-à-dire sans l'utiliser pour alimenter un utableview ? Je n'ai pas vu cela fait nulle part et je pensais avoir quelque chose à manquer.
3 Réponses :
Il n'y a rien de mal à utiliser nsfetchedResultController sans vue. Votre cas d'utilisation ressemble à une bonne raison de ne pas réinventer la roue.
Pour moi, cela ressemble à une utilisation appropriée de NsfetchedResultController. Cela pourrait être un peu trop chers, car son utilisation principale consiste à aider à remplir et à tenir à jour les visualisations de la table, mais si vous êtes prêt à supporter la complexité supplémentaire, il n'y a aucune raison de ne pas l'utiliser comme tel. L'utilisation correcte des notifications serait l'autre méthode et il est tout aussi complexe que je devrais estimer.
Je ne l'appellerais pas mal mais définitivement "lourd".
Il serait moins de mémoire et de la CPU à regarder pour enregistrer les économies via le Ceci fait partie de ce que le En outre, il n'y a aucune raison de conserver quoi que ce soit puisque vous retenez déjà l'entité «département» et accédez donc à ses relations. Holding sur les objets enfants "juste au cas où" est un gaspillage de mémoire. Laissez les données de base gérer la mémoire, qui fait partie de la raison de l'utilisation. nsmanagedObjectContextivation et effectuez le calcul là-bas. La notification viendra avec trois instances Nsarray dans son userinfo et vous pouvez ensuite utiliser un simple nspredicate contre ces tableaux pour voir si un employé que vous se soucient de changer et de répondre.
NsfetchedResultController sous les couvercles. Cependant, vous éviteriez les autres parties du NsfetchedResultSluTroller que vous ne vous souciez pas ou dont vous avez besoin.
Heavy
nsfetchedResultSluTroller fait plus de traitement que de regarder simplement des objets sauvegardés. Il gère Deltas, appelle les appels à ses délégués, etc. Je suis pas en disant qu'il est mauvais de quelque manière que ce soit de manière ou de forme. Ce que je dis, c'est que si vous SEULEZ CARE Lorsque des objets ont changé dans votre relation, vous pouvez le faire assez facilement en regardant les notifications.
Mémoire
Merci pour la réponse rapide et la suggestion! Si vous utilisez NsfetchedResultController n'est pas mauvais, cela ressemble à un problème de performance. Dans certains cas, il serait utile de conserver les données triées pour les autres calculs initiés par l'utilisateur qui l'exigent. Je suppose que FetetchedObjects est de savoir où vient la majeure partie de la charge de la mémoire. Si oui, je perdrai les économies de mémoire en conservant les données triées dans le cadre de la gestion de la notification de sauvegarde. Mais quelle est l'utilisation supplémentaire de la CPU que vous parlez de votre référence? Est-ce que c'est d'utiliser une récupération dans NsfetchedResultSultRoller au lieu d'un accesseur de relation?
Vous utilisez des extrayant pour rechercher des objets en fonction des attributs. Pour trouver des relations, vous parcourez le graphique de l'objet en appelant après les relations d'objets récupérés. Marcher le graphique est plus efficace car le contexte n'a besoin que des défauts (c'est-à-dire des objets sans données d'attribut chargé) pour suivre les relations.
La seule raison pour laquelle je tiendrais sur les objets de "employé" triés consiste à éviter de les recourir dans le cadre de chaque calcul initié par l'utilisateur.
Personnellement, dans ce cas, je créerais une méthode de commodité qui retourne les employés triés au lieu de les conserver, mais cela est sans doute une préférence personnelle.
J'aime cette approche; C'est ce que je fais actuellement. :) En fait, je filtre les "employés" d'abord et trier les résultats. L'ensemble de données filtré peut être relativement petit. Je pensais donc: "Pourrait-il être plus intelligent de filtrer / trier le grand jeu de données une fois et mettre en cache le petit tableau de résultats plutôt que de filtrer à plusieurs reprises le grand jeu de données à chaque fois que j'ai besoin du sous-ensemble triché? Je pourrais créer une classe pour gérer le filtrage / triés de données et utilisez des notifications de changement de la MOC pour garder tout à jour. Hmm ... N'y a-t-il pas une classe qui fait essentiellement cela? " Et donc ma question est née.
Comme indiqué ci-dessous, l'utilisation d'un contrôleur de résultats récupéré de cette manière n'est pas un problème. Vous devriez vous rappeler que "l'optimisation prématurée est la racine de tout mal". Étant donné que c'est la méthode la plus facile à implémenter, essayez-la et voyez si cela fonctionne dans cette instance particulière, puis essayez quelque chose d'autre que lorsque vous avez testé et que vous l'avez trouvé insuffisant.
Difficile de discuter contre les conseils de @ Techzen ici. Je suis dans les bols des données de base que j'ai tendance à voir que c'est des internes différemment.
Pour autant que je sache, le consensus est que ce n'est pas une mauvaise idée d'un point de vue de conception, mais cela pourrait avoir des implications de performance qui sont mieux évaluées avec des tests. J'aimerais pouvoir accepter toutes les réponses.