Core data : oui ou non ?

Bonjour,


 


Je suis en train de faire une application "document-based".


Chaque document a pour données :


 


(1)


-> un NSString


-> un NSArray de NSString


-> une autre NSString


et 


(2)


-> une collection d'objets de type A


 


 


Un objet de type A est typiquement la donnée de :


-> trois NSString


-> un tableau d'objets de type B


-> un tableau d'objets de type C


 


D'après ce que j'ai lu dans "Programmation Cocoa sous Mac OSX", je me demande s'il possible qu'à  l'enregistrement mon document sauvegarde à  la fois (1) et (2). Les données (2) me semblent bien adaptées à  Core Data. Mais je n'ai pas compris si Core Data va me permettre de sauvegarder (1).


 


 


Autre point : j'ai l'impression que CoreData est un gadget !!!


Si tout ce qu'il me permet de faire c'est de m'offrir une interface graphique pour créer mon modèle... bof !


L'argument qui revient en masse : il gère le undo... bof, pas si génial que ça pour les contraintes que créent Core Data.


 


Le seul argument que je vois en faveur de Core Data contre NSKeyedArchiver, c'est qu'il fait du fetching, c'est-à -dire qu'il ne charge pas toutes les données à  l'ouverture. Mais, je ne prévois ps d'avoir beaucoup de données.


 


Je signale que je suis débutant dans la programmation d'applications (et aussi en Cocoa).


 


Voilà , je voulais avoir votre avis sur Core Data et comprendre comment on peut gérer à  la fois des ManagedObjects et des données auxiliaires.


 


 


J'espère que ma question et mon modèle d'appli sont clairs ; n'hésitez pas à  me poser des questions !


 


Merci


Colas


«1

Réponses

  • Voilà , je voulais avoir votre avis sur Core Data et comprendre comment on peut gérer à  la fois des ManagedObjects et des données auxiliaires.


     


     


    J'espère que ma question et mon modèle d'appli sont clairs ; n'hésitez pas à  me poser des questions !


     


    Merci


    Colas


    Le modèle peut être pas, Core Data a ça de bon qu'il permet de bien voir le "graphe", les relations entre les objets de données de l'application   dont il automatise la sauvegarde, sans compter les Undo/Redo qui sont gérés automatiquement. Enfin il organise la persistence des données, avec lui l'utilisateur retrouve son travail. Sans que tu aies eu à  implémenter NSCoding dans tes classes de base.


    Le revers de la médaille c'est qu'on ne travaille plus sur des NSObjects mais des sous classes de NSManagedObject et donc ça n'est plus toi, le programmeur, qui décide quoi faire  avec tes data mais Core Data qui te concède des points d'accès et des procédures de recherche. On y perd de la liberté et parfois de la visibilité/compréhension de ce qui se passe, on y gagne de la rigueur. C'est comme ça que je le ressens ;)


    Quand on débute le conseil est de l'éviter. Et, de mémoire, ceux qui sont passés outre ce conseil ont souffert..

  • colas_colas_ Membre
    avril 2013 modifié #3

    Imaginons que mon document ait un numéro de série, qui est une NSString.


    Je devrais donc créer une entité NumeroDeSerie et qui ne contient qu'une NSString ?


  • LeChatNoirLeChatNoir Membre, Modérateur

    Perso, j'attaque une 3eme appli (que je ne finirai sans doute jamais ^^) qui doit gérer qques données mais rien de bien méchant.


    Jusqu'à  maintenant, je me débrouillai avec du JSon ou plist et j'ai jamais voulu me lancer dans CoreData. 


     


    Mais la présentation de helios m'a mis la puce à  l'oreille... Si un mec comme Mattt Thompson l'utilise, c'est que qque part, c'est devenu mature...


     


    J'ai donc lu attentivement un post ici qui m'a également rassuré : notre rihno du forum l'utilise également et semble le maitrisé.


     


    Donc direction un tuto qui est pas trop mal fait pour voir l'intérêt de la bête : 


    Partie 1 : http://www.techotopia.com/index.php/Working_with_iOS_6_iPhone_Databases_using_Core_Data


    Partie 2 : http://www.techotopia.com/index.php/An_iOS_6_iPhone_Core_Data_Tutorial


     


    Je vais embrayé sur la doc Apple pour approfondir un peu tout ça (le tuto effleure tout juste la chose) et pense l'utiliser pour stocker mes qques données.


    Mais effectivement, sans vouloir me la péter, je pense avoir le recul nécessaire maintenant. Il y a de cela 2/3 ans, j'avais voulu m'y frotter et je m'y étais vite perdu...


     


    +


  • Mais la présentation de helios m'a mis la puce à  l'oreille... Si un mec comme Mattt Thompson l'utilise, c'est que qque part, c'est devenu mature...


     


    Je dois dire que ce genre de commentaire me fais frémir... Cela fait quand même bien longtemps que CoreData est mature, depuis au moins 10.6, et ça ne veut pas dire que ça ne fonctionnait pas avant.


     


    Ce qui me fait d'autant plus frémir c'est que ce que Thompson vous a présenté avec Helios c'est basé sur les incremental store, un truc que je connais assez bien pour en avoir déjà  développé et fait une présentation à  Paris, et qui lui est tout sauf mature, il n'est même pas correctement documenté !


     


    Se servir d'un IncrementalStore quand on connait très bien CoreData et les requêtes client/server c'est pas un soucis, c'est juste un système d'adapter au final. Mais sortir un outil comme Helios, boite noir sur un truc bas niveau d'Apple que peut de monde est capable de comprendre, c'est pas une bonne idée... La réputation de Thompson va faire que pas mal de gens vont s'y essayer se retrouver en galère quand il va y avoir un problème...


     


    Alors CoreData tout simplement, oui, allez y, ça demande une lecture de doc conséquente mais c'est tout a fait fiable.


     


    Helios, pas avant d'avoir développé vous même un proto d'incrementalstore histoire que vous sachiez dans quoi vous êtes en train de mettre les mains.

  • KubernanKubernan Membre
    avril 2013 modifié #6

    Si tu veux te lancer dans Core Data il va te falloir assimiler quelques concepts, notamment les contexts (NSManagedObjectContext). Cela va bien plus loin qu'une simple opération d'écriture et de sauvegarde de données.


    Core Data est un outil fantastique mais pas évident à  appréhender pour qui se lance dans la programmation et doit apprendre d'autres choses en même temps.


     


    Ca ne vaut probablement pas le coup de t'y mettre si tu as un petit volume de données avec une structure assez simple.


  • LeChatNoirLeChatNoir Membre, Modérateur

    Wouhhh, je t'ai fait frémir 2 fois :-)


     


     


    LeChatNoir Power :-)

  • christopheLchristopheL Membre
    avril 2013 modifié #8

    J'aurai tendance à  répondre : "Core Data : oui et non"


     


    J'ai une application avec et une sans Core Data. Si c'était à  refaire, je referai pareil.


     


    Dans une, j'ai pas mal de données, des relations multiples, dans lesquelles je fais des recherches selon certaines contraintes. Core Data est très pratique.


     


    Dans l'autre, j'ai peu de données, avec une relation pyramidale, je sais que dans l'avenir il n'y a quasiment aucun risque qu'elles se complexifient, je les maitrise bien, j'ai utilisé le système d'archivage avec une shared Instance. J'estime avoir perdu du temps à  la mise en place des données mais à  l'utilisation de ces données j'estime en gagner (clarté, rapidité). Après c'est vrai que j'utilise sans aucun doute plus de mémoire que si j'avais utilisé Core Data mais comme j'ai peu de données... Utiliser Core Data aurait été comme prendre un bazooka pour chasser une mouche.


  • Core Data est extrêmement efficace. En ce qui concerne les données du type (1)  je les définis dans une entité du modèle (maGlobale) et pour laquelle je crée une instance (et une seule) lors de la création d'un nouveau document.


     


    J'ai débuté sur une application Core Data avec Binding (gestion de ma cave), simpliste, mais lors de son écriture j'ai découvert Core Data. Comme dit Yoann j'ai beaucoup lu la documentation et épluché les exemples. Ce qui m'a permis de savoir ce que je pouvais faire et surtout ce que je ne pouvais pas faire. 


     


    Remarque que, maintenant, j'ai l'impression que je peux tout faire avec...


     


    Un conseil, plutôt que de travailler directement avec des NSManagedObject, prends le temps d'interfacer tes entités du modèle avec des classes nommées et tu pourras en faire ce que tu veux (ajout d'instances et de méthodes etc.).


     


    Bonne lecture.

  • CéroceCéroce Membre, Modérateur

    D'après ce que j'ai lu dans "Programmation Cocoa sous Mac OSX", je me demande s'il possible qu'à  l'enregistrement mon document sauvegarde à  la fois (1) et (2). Les données (2) me semblent bien adaptées à  Core Data. Mais je n'ai pas compris si Core Data va me permettre de sauvegarder (1).


    Bien sûr qu'on peut sauvegarder, c'est même essentiellement à  ça que ça sert.


     


    Autre point : j'ai l'impression que CoreData est un gadget !!!


    Pas du tout, c'est très fiable et bien conçu.


    Crois-moi, je commence à  connaà®tre pas mal de pans de Cocoa, et Core Data est l'un des plus soigné. Pour moi, le gros problème était la documentation quand je m'y suis mis, il y a quelques années. Celle-ci s'est beaucoup améliorée.


     


    Si tout ce qu'il me permet de faire c'est de m'offrir une interface graphique pour créer mon modèle... bof !


    L'argument qui revient en masse : il gère le undo... bof, pas si génial que ça pour les contraintes que créent Core Data.


     


    Le seul argument que je vois en faveur de Core Data contre NSKeyedArchiver, c'est qu'il fait du fetching, c'est-à -dire qu'il ne charge pas toutes les données à  l'ouverture. Mais, je ne prévois ps d'avoir beaucoup de données.


     


    Il y a d'autres avantages, je pense en particulier à  son système de migration d'une version à  une autre. Mais c'est vrai que c'est surtout intéressant si tu as beaucoup d'objets, ou que tu ne veux pas t'ennuyer à  gérer des répertoires et dépendances entre fichiers.


     


    Je signale que je suis débutant dans la programmation d'applications (et aussi en Cocoa).


     


    On en arrive au point qui fâche: Core Data est complexe. Il demande une bonne maà®trise de Foundation. Par exemple, un point qui paraà®t anodin mais qui pose problème est qu'il faut lancer des requêtes pour obtenir des objets; c'est déjà  un peu complexe en soi. Ensuite, les objets sont renvoyés sous forme de NSSet, donc non ordonnées; il faudra les classer avant l'affichage. Ce ne sont que des exemples, mais il y a un foule de petites choses comme ça qui rendent l'apprentissage difficile.


     


    Mon avis, comme conseillé plus haut, est de faire sans Core Data. Ton modèle est bien trop simple pour que ça vaille le coup de t'investir là -dedans pour l'instant.

  • LeChatNoirLeChatNoir Membre, Modérateur

    Donc pas de order by ?


    Ca veut dire qu'il faut tranformer le NSSet en Array et le trier ?


  • Donc pas de order by ?


    Ca veut dire qu'il faut tranformer le NSSet en Array et le trier ?


    Que nenni !

  • AliGatorAliGator Membre, Modérateur

    Perso j'utilise CoreData avec le framework MagicalRecord, ce qui change tout à  mon avis, car MagicalRecord est vraiment bien foutu et permet d'avoir une API super simple à  utiliser en rajoutant une couche toute bête au dessus de CoreData.


     


    Par exemple pour faire simple, si j'ai une entité Personne, pour récupérer toutes les personnes triés par nom, avec l'API CoreData de base il faut que je crée une NSEntityDescription, une NSEntity, une NSFetchedRequest, enfin plein de trucs comme ça (je suis même pus sûr des noms tellement maintenant je n'ai plus à  les utiliser ou à  m'en soucier avec MagicalRecord vu que c'est transparent) donc écrire 3-4 lignes tout ça pour pouvoir faire ma requête, et récupérer le résultat dans un NSSet puis le trier.


     


    Avec MagicalRecord, j'ai juste à  écrire [Person findAllSortedBy:@name ascending:YES]; et pouf, j'ai un NSArray d'objets Person, trié par le champ "name". C'est simple, c'est magique, c'est efficace. Y'a vraiment plus rien à  faire.


  • colas_colas_ Membre
    avril 2013 modifié #14

    Ensuite, les objets sont renvoyés sous forme de NSSet, donc non ordonnées;


     


    j'avais cru comprendre que dans la dernière version de Core Data, on pouvait gérer des NSArray.


    Ce que je dis est-il hors sujet ?


     


    Pour me répondre à  moi-même, tu voulais dire que les requêtes renvoient des NSSet.


  • j'avais cru comprendre que dans la dernière version de Core Data, on pouvait gérer des NSArray.


    Ce que je dis est-il hors sujet ?


     


    Pour me répondre à  moi-même, tu voulais dire que les requêtes renvoient des NSSet.


     


    Non. Quand tu exécutes une requête (en utilisant NSFetchRequest) Core Data te renvoie un array (selon ton type de requête mais c'est un détail ici) qui sera trié selon un (ou plusieurs) critère(s) que tu as toi même transmis à  la requête.


    Exemple :



    NSFetchRequest *req = [NSFetchRequest fetchRequestWithEntityName:@Person];
    NSSortDescriptor sortDescriptorWithKey:@"name" ascending:YES; // tri
    NSArray *persons = [myCoreDataContext executeFetchRequest:req error:NULL]; // execution de la requête, renvoi le resultat trié

     


    Mais si tu accèdes directement à  une relation de type many, par exemple : person.friends, ton résultat est un NSSet.

  • colas_colas_ Membre
    avril 2013 modifié #16

    Mais si tu accèdes directement à  une relation de type many, par exemple : person.friends, ton résultat est un NSSet.


     


    Et justement, il y a pas une histoire qu'avec la dernière version de Core Data on peut faire des NSArray ?


     


    PS : c'est ce dont j'ai besoin !


  • KubernanKubernan Membre
    avril 2013 modifié #17

    Et justement, il y a pas une histoire qu'avec la dernière version de Core Data on peut faire des NSArray ?


     


    PS : c'est ce dont j'ai besoin !


     


    Non je ne crois pas. En revanche il y a les ordered set (il me semble) mais je n'ai pas étudié ce truc là .


    Rien ne t'empêche non plus de créer ta méthode qui te renvoie un array trié (ou pas d'ailleurs), par exemple dans ton objet Person :


     



    - (NSArray *)sortedFriends {
    NSSortDescriptor *sortDescriptor = [NSSortDescriptor sortDescriptorWithKey:@name ascending:YES];
    NSArray *orderedFriends = [self.friends sortedArrayUsingDescriptors:@[sortDescriptor]];
    return orderedFriends;
    }

  • Petit rappel pour les NSOrderedSet, c'est 10.7+ et iOS 5.0+, c'est pratique, mais c'est un peu particulier à  utiliser, d'autant que les NSArrayController ne sont pas mis à  jour pour s'en servir en binding, on est obligé de faire des value transformer pour convertir les set en array et inversement...


     


    ça demande quelques tests pour bien le maitriser et surtout se rappeler que l'ordre de tri de la relation (ordre d'arrivé, peut être rangé autrement ensuite) n'est pas forcément l'ordre d'affichage choisi.


     


    Le NSOrderedSet sert pour conserver un ordre source, mais ce n'est pas ce set que vous devrez tirer au niveau du contrôle pour l'affichage par date / nom etc... Vous devrez toujours passer par un NSArray intermédiaire pour avoir un tri propre à  la vue et non au modèle.


  • Bonjour,


     


    Personnellement je conseille core data pour des applications avec des données compliquées et je l'utilise plus sur OSX. Sur iOS, je pense que dans 90% des cas on peut s'affranchir de core data et utiliser un simple stockage sur fichier.


     


    K.


  • AliGatorAliGator Membre, Modérateur

    Pas du tout d'accord Karoxys. Dans les applis iOS que j'ai faites où j'ai utilisé CoreData, j'aurai pas pu m'en passer et ça aurait été la grosse galère de faire ça en stockage de fichiers.


     


    Ca dépend pas de OSX ou iOS, mais de la complexité (et évolutivité) de ton DataModel.


  • Bonjour,


    pour ma part je trouve que se passer de CoreData peu être une erreur c'est un outil vraiment puissant et une fois les concepts intégrés ca facilite la vie.


     


    Je l'utilise depuis ma premiere application et je n'ai jamais eu de problème avec. Contrairement à  Ali je n'utilise pas de framework particulier mais je testerais MagicalRecord pour la prochaine ;)


  • N'oubliez pas MoGenerator dans la toolbox des indispensables de CoreData.


  • N'oubliez pas MoGenerator dans la toolbox des indispensables de CoreData.


    Je connais pas non plus... j'utilise vraiment que le Framework CoreData.... 

  • colas_colas_ Membre
    avril 2013 modifié #24

    Merci de vos réponses !


     


    @yoann :


    À propos des NSOrderedSet vs NSArray.


    Mon modèle a, disons, 2 objets : A et B.


    L'objet A est constitué par exemple de 2 NSString et 1 Bool.


    L'objet B est constitué de 2 NSString et d'un NSArray d'objets A.


     


    Est-ce que ce modèle est facilement implémentable avec Core Data ?


     


    Merci


    Colas


  • Merci de vos réponses !


     


    @yoann :


    À propos des NSOrderedSet vs NSArray.


    Mon modèle a, disons, 2 objets : A et B.


    L'objet A est constitué par exemple de 2 NSString et 1 Bool.


    L'objet B est constitué de 2 NSString et d'un NSArray d'entités A.


     


    Est-ce que ce modèle est facilement implémentable avec Core Data ?


     


    Merci


    Colas


     


    À mon sens tu te focalise trop sur cette histoire d'array trié.


     


    Core Data est utilisé depuis longtemps et on n'a pas attendu les ordered set pour l'utiliser.


     


    Enfin, ton modèle est très classique. Bien sûr que Cora Data te permet de gérer ça.

  • Pas du tout d'accord Karoxys. Dans les applis iOS que j'ai faites où j'ai utilisé CoreData, j'aurai pas pu m'en passer et ça aurait été la grosse galère de faire ça en stockage de fichiers.


     


    Ca dépend pas de OSX ou iOS, mais de la complexité (et évolutivité) de ton DataModel.


    Ah bon ? J'ai effectué une formation avancé sur iOS il n'y a pas longtemps et le formateur à  tester pas mal de chose sur core data. Il a trouvé que niveau performance pour un lecteur RSS c'était pas le mieux. Ils obtenaient de meilleur résultat soit à  la main soit dans un fichier au niveau du temps de réponse.


     


    C'est intéressant de voir qu'il y a les pour et les contre au final !!


     


    K.


  • KubernanKubernan Membre
    avril 2013 modifié #27

    Ah bon ? J'ai effectué une formation avancé sur iOS il n'y a pas longtemps et le formateur à  tester pas mal de chose sur core data. Il a trouvé que niveau performance pour un lecteur RSS c'était pas le mieux. Ils obtenaient de meilleur résultat soit à  la main soit dans un fichier au niveau du temps de réponse.


     


    C'est intéressant de voir qu'il y a les pour et les contre au final !!


     


    K.


     


    Attention, en utilisant Core Data il faut avoir la connaissance de quelques règles d'optimisations. Ces règles s'appliquent pour les fetch request (bath size, pre-fetching...), pour la sauvegarde et/ou la suppression.


     


    Le modèle même peut influer sur les performances. Sans parler bien entendu de traitement asynchrone.


     


    Il existe enfin un ensemble d'outils permettant de mesurer finement les performances Core Data.


     


    Le formateur a-t-il connaissance de ces règles ? Les a-t-il appliqué ? (je ne préjuge pas de ses compétences, ce sont simplement les questions que l'on peut amener à  se poser quand on fait ce type de comparaison).


     


    EDIT : Ouaaaais !! j'ai grilled Ali !! (en plus condensé :-)


  • AliGatorAliGator Membre, Modérateur

    Utilisait-il correctement CoreData ? Entre autres, profitait-il de l'avantage des NSFetchResultController par exemple ?


     


    Les NSFetchResultController ont de gros avantages donc la pagination automatique, la gestion d'un cache interne, l'optimisation pour les TableViews et autres listes...


     


    Par exemple pour un lecteur RSS où tu as disons 5000 articles dans ton RSS, NSFetchResultController va être très optimal car ne charger que les articles nécessaires à  l'affichage, et de façon incrémentale et paginée (par exemple il va les charger 50 par 50, et quand tu scrolles et arrive près de la fin du multiple de 50 chargé il va charger en base les 50 suivants tout seul, etc). Ce qui t'évite de faire une grosse requête pour tout rapatrier d'un coup qui serait longue, optimise les temps de réponse, tout en gardant à  la fois fluidité et continuité dans le scrolling.


    Si tu fais ça par un fichier (genre une NSKeyedArchive) tu vas être obligé de charger ton tableau d'articles en entier d'un coup, donc ouvrir ta NSKeyedArchive ou ton PLIST et y récupérer le tableau des 5000 articles, avant de pouvoir les traiter et les afficher dans ta TableView...


     


    Bref, ça dépend comment tu codes et si tu utilises CoreData à  bon escient, aussi ;)


     


    Pour des petites structures et des DataModel simples, ou des fichiers que tu n'ouvres pas tous les 4 matins, gérer ça par PLIST ou NSArchive ça va. C'est ce que je faisais avant (avant de me résoudre à  tester et me mettre à  CoreData, car au début CoreData me faisait un peu "peur") et ça peut encore se faire pour de la gestion de documents ou pour des modèles de données facilement exploitables et peu complexes (à  la limite un lecteur RSS dont le DataModel est très simple, avec juste 2 entités/tables/classes "Sources" et "Articles", c'est loin d'être un modèle de données complexe donc ça passe encore).


    Mais dès que tu as un DataModel un peu plus conséquent, (dans mon projet actuel j'ai par exemple 11 entités avec des relations partout entre chaque) non seulement c'est plus simple et plus évolutif à  gérer et manipuler avec CoreData (tu as directement les classes modèle générées par CoreData, et tu n'as pas à  coder de encodeWithCoder ou initWithCoder ou quoi que ce soit), surtout si tu utilises MagicalRecord (où le setup de la stack CoreData se fait en une ligne et pas 30).


  • Je ne sais pas comment il utilisait core data car au final on a pas mal bossé sur les fichiers et le sujet a été abordé le dernier jour.


     


    Mais, il nous a parlé de la complexité des données en disant que pour des applications iPhone/iPad le modèle n'était pas très complexe dans 80% des cas et que ce n'était pas la peine d'utiliser core data pour des données aussi simple. A voir dans la réalité.


     


    Après j'ai regardé pas mal les lecteurs RSS sur iOS et la plus part font des mises à  jour indiquant qu'ils avaient supprimés Core Data donc j'ai pensé tout de suite à  la formation en me disant c'est surement à  cause des prefs.


     


    Mais effectivement tout dépend comment tu l'utilises. Si tu es un expert core data ou pas et si le modèle en a besoin.


     


    Donc peut-on dire : Core data oui, non ? Tout dépend de la complexité de ton modèle de données.


     


    K.


  • AliGatorAliGator Membre, Modérateur

    Mais, il nous a parlé de la complexité des données en disant que pour des applications iPhone/iPad le modèle n'était pas très complexe dans 80% des cas et que ce n'était pas la peine d'utiliser core data pour des données aussi simple. A voir dans la réalité.


     


    Oui, bah ça ça dépend de ce que tu fais. Oui pour les applis qu'en général tu fais quand tu es débutant (lecteur RSS ou quoi), c'est sûr qu'en général le DataModel est plutôt simple. Mais pour toutes les applis que je fais maintenant, j'en vois peu parmi celles qui gèrent des données pérènes pour lesquelles j'y gagnerai pas à  utiliser CoreData


     


    Mais effectivement tout dépend comment tu l'utilises. Si tu es un expert core data ou pas et si le modèle en a besoin.


    A vrai dire, je ne pense pas être expert CoreData, loin de là . Le projet que je fait actuellement est le premier projet sur lequel j'ai utilisé CoreData, c'est avec ce projet que j'ai découvert le framework, dont j'avais déjà  entendu parler plusieurs fois (j'avais déjà  entendu les termes de NSPersistantStore, NSFetchRequest ou NSEntity ou NSEntityDescription etc mais j'étais pas encore familier avec eux et confondait un peu tout ça, trop abstrait encore pour moi avant d'y avoir touché) mais sans jamais avoir eu l'occasion de m'y plonger pour essayer de comprendre tout ça.


    Dès ce premier projet avec CoreData, j'ai utilisé le framework MagicalRecord qu'on m'a fortement conseillé, et effectivement qui simplifie énormément la vie (surtout que quand tu découvres CoreData pour la première fois et que tu vois les tutos qui te montrent qu'il faut écrire 30 lignes pour configurer ta stack CoreData, ça fait peur et décourage un peu, alors qu'avec MagicalRecord ça se fait en une seule ligne limite c'est magique voire déroutant de simplicité). Eh bien j'ai très vite monté en compétence sur CoreData (surtout que MR enlève la complexité du code du fmk CoreData) et ça m'a démystifié le framework qui me faisait un peu peur et que finalement je trouve super bien pensé et très simple.


    Bon certes il y a parfois des petites choses obscures qui nécessitent que je me documentent quand je tombe dans un cas un peu particulier, mais dans l'ensemble, faut pas non plus avoir peur de CoreData.


     


     


     


    Donc peut-on dire : Core data oui, non ? Tout dépend de la complexité de ton modèle de données.


    Bah c'est ce que j'ai dit dès le début dans mon message plus haut non ? :P

  • Je ne sais pas comment il utilisait core data car au final on a pas mal bossé sur les fichiers et le sujet a été abordé le dernier jour.


     


    Mais, il nous a parlé de la complexité des données en disant que pour des applications iPhone/iPad le modèle n'était pas très complexe dans 80% des cas et que ce n'était pas la peine d'utiliser core data pour des données aussi simple. A voir dans la réalité.


     


    Après j'ai regardé pas mal les lecteurs RSS sur iOS et la plus part font des mises à  jour indiquant qu'ils avaient supprimés Core Data donc j'ai pensé tout de suite à  la formation en me disant c'est surement à  cause des prefs.


     


    Mais effectivement tout dépend comment tu l'utilises. Si tu es un expert core data ou pas et si le modèle en a besoin.


     


    Donc peut-on dire : Core data oui, non ? Tout dépend de la complexité de ton modèle de données.


     


    K.


     


    Est-ce que cela dépend plus de la complexité du modèle que de des connaissances que l'on a de Core Data ? Qui peut le plus, peu le moins. Si par exemple je devais développer un lecteur RSS sur iOS je m'orienterai immédiatement sur du Core Data. Là , clairement, ce n'est pas une question de complexité du modèle de base.

Connectez-vous ou Inscrivez-vous pour répondre.