Sondage 13 - Core Data
Le sondage n'a pas pour objectif de nier l'utilité de la notion de modèle mais plutôt de saisir vos impressions sur l'approche choisie d'Apple.
1°) Globalement, pensez-vous que ce mécanisme répond au raison de son existence ?
1.1) pas du tout.
1.2) un peu.
1.3) moyennement.
1.4) pleinement.
2°) Pensez-vous que ce mécanisme est complexe à comprendre (niveau fonctionnel exclusivement) ?
2.1°) pas du tout.
2.2°) un peu.
2.3°) moyennement.
2.4°) pleinement.
3°) Pensez-vous que ce mécanisme est complexe à mettre en oe“uvre (niveau organique) ?
3.1°) pas du tout.
3.2°) un peu.
3.3°) moyennement.
3.4°) pleinement.
4°) Si vous éprouvez une quelconque difficulté, seriez-vous intéressé par un autre système ?
4.1°) pas du tout.
4.2°) un peu.
4.3°) moyennement.
4.4°) pleinement.
Merci de votre participation.
1°) Globalement, pensez-vous que ce mécanisme répond au raison de son existence ?
1.1) pas du tout.
1.2) un peu.
1.3) moyennement.
1.4) pleinement.
2°) Pensez-vous que ce mécanisme est complexe à comprendre (niveau fonctionnel exclusivement) ?
2.1°) pas du tout.
2.2°) un peu.
2.3°) moyennement.
2.4°) pleinement.
3°) Pensez-vous que ce mécanisme est complexe à mettre en oe“uvre (niveau organique) ?
3.1°) pas du tout.
3.2°) un peu.
3.3°) moyennement.
3.4°) pleinement.
4°) Si vous éprouvez une quelconque difficulté, seriez-vous intéressé par un autre système ?
4.1°) pas du tout.
4.2°) un peu.
4.3°) moyennement.
4.4°) pleinement.
Merci de votre participation.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
2) Un peu. Mais en fait, le nombre d'objets mis en oe“uvre n'est pas énorme, et il n'est pas forcément nécessaire de savoir comment cela se passe sous le capot pour faire marcher le bouzin.
3) Pleinement. Et là , c'est surtout la faute de la documentation, totalement incapable d'expliquer quoi que ce soit simplement.
4) Sincèrement, un peu, mais pas plus que ça. L'investissement en temps pour comprendre le fonctionnement fut énorme, mais il est derrière moi ! Si je n'avais pas fait cet investissement, ce serait différent, mais aujourd'hui, il me faudrait une bonne raison pour utiliser un autre système, par exemple qu'il puisse facilement prendre des formats de fichiers classiques, ou facilement gérer les documents sous forme de bundles.
Je préfère gérer moi même mon format d'archivage.
Si tu peux argumenter Schlum, je te lirais avec plaisir.
Qu'est-ce qui à fait que cela te rebute ?
Et la doc a l'air moisie en plus...
Au moins je sais exactement ce qui tourne sous le capot !
@Gnome06
Tu peux aussi répondre ! :P
Je répondrais qu'en tant que grand débutant je n'ai pas encore (asser) mis le nez dedans pour pouvoir donner un avis un tant soit peu circonstancié et justifié.
D'où ma demande de détails pour avoir une vision/idée de la chose et un point de vue extérieur.
Je trouve ça très lourd pour ce que ça fait. Je n'accroche pas du tout. Tout comme avec les binding qui y sont très liés d'ailleurs. Pourquoi? Tout simplement parce que le codage est "transféré" à la charge d'IB. Je préfère 100 fois lire un code clair plutôt que de devoir passer mon temps à me perdre dans les onglets d'IB.
Cela se vérifie d'ailleurs à l'usage. Il suffit de faire un bout de code avec Core Data/binding et d'essayer de le reprendre six mois plus tard...
En fait, ce que j'aurais bien aimé c'est plutôt qu'Apple intègre l'approche de rtlabs:
http://www.rtlabs.com/fwork/
Puissant, simple, efficace.
Quand à moi, je ne suis pas du tout de cet avis !
1°) Globalement, pensez-vous que ce mécanisme répond au raison de son existence ?
1.4) pleinement.
Core Data n'est pas adapté à tout; mais si on l'utilise pour ce à quoi il sert, c'est formidable.
2°) Pensez-vous que ce mécanisme est complexe à comprendre (niveau fonctionnel exclusivement) ?
2.3°) moyennement.
On peut faire simplement des trucs simples... mais pour des traitements complexes, il faut se pencher sur la doc très sérieusement.
3°) Pensez-vous que ce mécanisme est complexe à mettre en oe“uvre (niveau organique) ?
3.3°) moyennement.
ça dépend de ce qu'on fait (cf. ce qui précède)
4°) Si vous éprouvez une quelconque difficulté, seriez-vous intéressé par un autre système ?
4.2°) un peu.
Pas à pas, j'étends ma connaissance de CoreData, et je peux l'utiliser pour différents types de projets. JE n'ai pas forcément envie de passer encore du temps sur autre chose. Mais faut voir : si un autre système répond à un besoin différent, ça peut être intéressant.
Bref, je ne suis pas de l'avis de Schlum et Mala.
Utiliser CoreData comme avec les tutoriaux Apple, c'est-à -dire avec des Bindings dans tous les sens et rien que du code magique, et bien c'est vrai que je n'aime pas. Par contre, je vous renvoie à un sujet que j'avais entamé ici : http://www.objective-cocoa.org/forum/index.php?topic=2016.msg19613#msg19613
+
Chacha
Je me permet de te citer dans ton autre post.
Pour moi c'est justement là que ça coince avec Core Data. La complexité de son utilisation augmente de manière exponentielle avec les besoins. Perso, voici le genre de data model que j'ai recréé sous Core Data pour un petit soft de gestion...
10 tables, cela n'a rien d'extraordinaire. Et bien bonjour la galère pour gérer tout ce petit monde, là où de simples requêtes SQL font merveille.
On notera au passage l'obligation de passer par une table "Compteur" pour gérer des références uniques associées aux différentes tables. C'est une aberration à mon sens lorsqu'on parle de bdd relationnelles pourtant Core Data ne le gère pas.
Un beau petit framework SQL, connecté à des vues prévues à cet effet, aurait fait merveille quelque soit le niveau de complexité alors que Core Data s'englue très rapidement. C'est pour ça que je faisais référence à rtlabs. La démo parle d'elle même...
http://www.rtlabs.com/fwork/MacSQLFrameworkDemo.mov
Maintenant, il y a aussi des choses très pratiques avec Core Data comme par exemple la possibilité de drag and drop d'une table sur une vue pour créer une fiche ou un tableau automatiquement.
Edit: en terme d'apprentissage, comprendre le fonctionnement des requêtes SQL ça prend quoi? Un demie heure? Et ça ouvre de nombreuse portes.
Je n'ai pas très bien compris ton problème (qui m'intéresse en parallèle à cette discussion), mais je ne doute pas que tu as raison.
Par contre, je considère justement que CoreData n'est pas fait pour gérer sérieusement une BDD relationnelle. Pour moi, il réalise le minimum de ce point de vue, mais propose en revanche :
-un seul objet (le managed oject) peut me servir dans le code et pour la sauvegarde; je modifie ses propriétés, et je sais que tout est synchronisé/sauvegardé; il n'y a pas une "barrière de code" (lourdeur d'un wrapper) à franchir pour sauvegarder des données en mémoire;
-l'occupation mémoire et la performance des caches de Core Data sont assez souples pour éviter les surconsommations, tout en proposant des requêtes très rapides.
Il est vrai que je n'ai jamais eu besoin de gérer une BDD compliquée. Mais sachant que les clefs étrangères ne sont pas parties d'SQLite, je savais déjà que je n'utiliserais pas Core Data pour ça.
+
Chacha
On aborde là une partie intéressante de Core Data. Son but est justement au départ de faire abstraction de la couche bdd pure et dure. On fait du SQLite pour les perfs mais on peut aussi choisir de plutôt basculer en xml (utile pour le debug). S'il n'y a pas a proprement parlé de clefs étrangères avec SQLite, ce n'est pas le cas de Core Data. Si tu regardes mon exemple, j'ai bien des relations entre la plupart de mes tables. Core Data s'occupe de rendre cette limitation transparente. En cela c'est très puissant.
Dans mon exemple, chaque facture à une clef vers le client qui lui est associé. Et Core Data permet même le liens inverse (relation multiple ici puisqu'un client peu avoir plusieurs factures). C'est donc sur le principe une véritable couche relationnelle. L'orientation naturelle aurait d'ailleurs été le support de nouveaux formats de bdd ainsi que la gestion de bdd multi-utilisateurs. Pourtant Apple semble avoir laissé les friches en l'état.
Là où ça cloche c'est que, si l'on parle de clefs, il faut bien une référence unique. Si Core Data gère bien une référence interne unique pour chaque ligne des tables (c'est facile à confirmer si on est en xml), on y a cependant pas accès au niveau API. Et là on revient à ma table Compteur. A chaque nouveau client, je devais incrémenter ref_client pour générer une nouvelle référence. C'est du moins à l'époque (en 2005) la seule solution qui était proposée pour contourner ce manque.
De mémoire, il y a aussi d'autres problèmes assez frustrant dès qu'on veut travailler sur une ligne de données (ex: calculer le prix TTC à partir du prix HT et de la TVA). Il fallait alors créer des champs "Transiant" et ensuite surcharger la classe gérant l'enregistrement pour venir faire sa cuisine soit même. Idem pour intégrer des imagettes dans un tableau (factures payées->icône vert sinon icône rouge). Au final, on se retrouve avec autant de classes qui servent à bricoler trois lignes de code.
Donc pour revenir à la question initiale, moi ce serait plutôt
1°) Globalement, pensez-vous que ce mécanisme répond au raison de son existence ?
1.1) pas du tout.
Il était sensé - dixit Apple - simplifier la vie et fournir une couche d'abstraction vers d'autre format de bdd. Au final, on s'aperçoit vite, dès qu'on fait un projet un peu complexe, que c'est loin de simplifier la vie et il n'a jamais évolué concernant le second point.
2°) Pensez-vous que ce mécanisme est complexe à comprendre (niveau fonctionnel exclusivement) ?
2.4°) pleinement.
Cela demande un investissement beaucoup trop lourd mais la c'est aussi lié au binding.
3°) Pensez-vous que ce mécanisme est complexe à mettre en oe“uvre (niveau organique) ?
3.3°) moyennement.
Disons que le problème c'est surtout que ça se complique très vite.
4°) Si vous éprouvez une quelconque difficulté, seriez-vous intéressé par un autre système ?
4.4°) pleinement.
Plus y en a mieux c'est.
Voilà , cela n'engage que moi mais c'est mon sentiment après avoir pratiqué un petit moment.
Merci également à olof.
Il y a le objectID des managed objects. Mais je n'ai pas compris comment on gérait le fait que cet id est temporaire avant la première sauvegarde.
Ceci dis, je n'ai jamais réussi à l'utiliser. Je suis même pas arrivé à compiler les exemples livrés sous xCode 3.1. Apparement ils ont été fait sous xCode 3.0 ou 2
Je pense que mon échec est dû à mon manque de compétences et que certaines personnes ici auront le niveaux nécessaire pour l'utiliser si ça les intéressent.
Mais de rien, même si je n'ai absolument rien dit :P
Si ça aide à faire avancer le schmilblick alors!
Effectivement c'est bien à objectID que je faisais référence (j'avais zappé le nom). Le problème c'est qu'on y a de toute façon pas accès au niveau du datamodel. Une piste a étudier serait peut-être de créer un attribut transient qui retourne sa valeur.
En fait ce qui serait bien, c'est tout simplement de pouvoir faire passer objectID en "public" et boum on aurait notre clef unique accessible au niveau du datamodel si on en a besoin pour certaines tables (clique droit sur une table->Afficher ObjectId). Dans le cas contraire, il reste caché. Cela ne compliquerait pas les cas simples et ça apporterait une solution élégante pour les cas plus complexes.
Je plussoie aussi. Je m'y suis jamais vraiment fait à CoreData...
Construire une arborescence basée sur des entités core Data relève du casse-tête chinois, les instances sont stockées à l'aide de NSSet et sont donc chargés dans n'importe quel ordre. Je rejoint donc certain post précédent en disant qu'il faut en de nombreux cas "bricoler" pour obtenir ce que l'on veut...
Il s'agit pourtant à mon sens d'un framework partant de bonnes idées : gestion undo/redo, stockage, compatibilité avec les bindings etc...
En conclusion, prometteur mais aisément perfectible.
@Eaglelouk
D'ou vient ce verbe (plussoie) ? ??? Moi pas comprendre ! :P
Cette expression vient de l'habitude, sur certains forums/blogs/chatrooms/..., d'écrire juste "+1" en commentaire/réponse à une proposition/un post pour dire "je vote pour", "moi je suis d'accord avec ce qui vient d'être dit", autrement dit "un de plus qui partage cet avis" (un peu comme quand il y a plusieurs propositions, ou dans un débat quand il y a plusieurs "camps", tu réponds ça pour dire qu'il faut compter une personne de plus dans ce "camp" là , toi en l'occurrence)
Donc EagleLouk aurais pu indiquer "+1" suite à sa citation de la réponse de schlum, pour dire "je me rajoute à la liste des personnes qui partagent cet avis". Mais au fur et à mesure de l'usage, le verbe "plussoir" et surtout le terme "je plussoie" est apparu, ayant du coup un sens similaire voire identique : "je suis tout à fait d'accord avec ce qui vient d'être dit/cité"
Ce qui me gène c'est qu'il semble que ce nouveau verbe soit du troisième groupe !
De manière générale, les nouveaux verbes sont du premier puisqu'ils sont plus simples à conjuguer. En conclusion, si l'on veut que notre langue ne devienne pas un dialecte, faisons un geste pour la protéger ! :P
On dirais que je m'égare !
- "Je plussoie" pour le verbe "plussoyer"
- "Je plussois" pour le verbe "plussoir"
Ok, mais sur un forum C, il serait plus logique "je plus-plussoie" ;D
Bon, je -->