Core data il est ou??
- Créateur du sujet jeromemac
- Date de début
Sans doute parce que c'est plutôt technique et pas aussi spectaculaire que les autres.
Mais c'est là:
http://developer.apple.com/macosx/tiger/coredata.html
Mais c'est là:
http://developer.apple.com/macosx/tiger/coredata.html
Pour comprendre Core data, il faut comprendre le principe fondamental de développement d'une application Cocoa. Je vais essayer d'être le moins technique que possible.
En effet ne l'oublions pas Cocoa est un environnement de développement objet qui comprend deux ensembles de classes.
- Application Kit qui contient les classes permettant en général de concevoir les interfaces utilisateurs
- Fondation kit qui regroupe les classses utilisées pour coder des actions ou décrire des données (chaine de caractères, etc).
Le concept de développement utilisant Cocoa est basé sur le principe que l'on appelle MVC comme Model, View, Controller.
En clair cela veut dire que toute application cocoa bien écrite comprend en général trois parties.
- L'interface utilisateur que l'on développe en utilisant Interface Builder et donc les classes de l'Application Kit; c'est donc la View de MVC,
- Les données que l'on utilise dans son appli et que l'on Modélise en utilisant les classes de Fondation Kit. C'est donc le Model de MVC
- et les actions qui permettent de faire le lien entre les deux et qui composent la partie Controller du concept MVC.
Pour aider les développeurs à produire rapidement des applis qui soient robustes, Apple a fourni jusqu'à Panther deux technologies.
Interface Builder pour la partie View, et la technologie des Binding pour faciliter la conception de la partie Controller.
Pour la Partie Model, les développeurs devaient coder tout eux-mêmes.
Exemple :
je développe un soft permettant de gérer des chèques d'achat. Mon interface propose à l'utilisateur de saisir son numéro d'abonné et le montant de la somme à dépenser .
Une autre interface présente à l'utilisateur, la liste des achats effectués et les modifications se font en temps réel.
Vous voyez que l'utilisation des binding dans mon controller permet automatiquement d'effectuer la mise à jour de la liste d'achats chaque fois que l'utilisateur utilise un chèque d'achat. Le développeur n'a aucun code à écrire!
Par contre pour la partie Model, j'ai modélisé les chèques d'achats (N° chèque , montant), l'utilisateur (son nom, prénom, N° d'abonné et la somme disponible de son compte) Ces données sont stockées dans des fichiers que j'appelle CHEQUE et UTILISATEUR par exemple.
En utilisant Cocoa, CHEQUE et UTILISATEUR sont des classes. Pour utilisateur par exemple, nom, prenom etc sont appelés variables d'instance de la classe. Enfin pour gérer mon objet utilisateur (incrémenter ou décrementer le montant du compte), on utilise ce qu'on appelle en jargon objet des méthodes.
Le plus dur c'est que l'on dots également gérer des undo , les redo. Mais surtout les fonctions permettant de sauvegarder ces données sur disque et pouvoir les relire. C'est ce qu'on appelle gérer la persistence des données.
Croyez-moi c'est assez pénible et il faut vraiment penser à tout.
HEUREUSEMENT Core Data est arrivé ( comme zorro).
Que fait Core Data?
Core Data introduit le moyen de gérer automatiquement la partie Model en introduisant le concept de Managed Object Model qui en fait permet au développeur de modéliser l'ensemble des objets de type données utilisées dans son application. Pour le faire, Apple fournit un outil intégré dans Xcode qu'il désigne sous le doux nom de Data Model Design Tool.
Cette modélisation introduit la notion d'Entité pour désigner les Classes ( Entité CHEQUE et Entite UTILISATEUR par exemple), la notion d'attribut pour designer les variables d'instance de classe. Et chose nouvelle, la notion de Relation entre Entités différentes.
Core data introduit aussi plusieurs autres concepts comme celui du Managed Object Context. En effet imaginez qu'un utilisateur ouvre deux interfaces de l'application pour effectuer des achats pour ses chèques et ceux de son épouse. La notion de contexte permet de faciliter la gestion séparée des deux interfaces. Ceci est très important lorsque par exemple le mari et son épouse ont un même compte. cela permet de valider complètement une transaction au niveau du contexte. La gestion des undo et redo se fait également au niveau du contexte..
Pour la gestion des validations concurentes, Core data introduit la notion de Persistence Store Cordinator. C'est lui qui coordone les accés aux données sur le support. Pour cela il se sert de la modélisation.
Pour que vous comprenier encore mieux je vais le préciser par une image.
Imaginez que les objets de l'applications (CHEQUES, UTILISATEURS) utilisés par l'application sont symbolisés par des boules vertes et rouges. Chaque boule verte est un chèque particulier avec son numéro, son montant etc... et chaque boule rouge est un utilisateur avec son nom, prenom etc.
Quand je lance mon application, celle-ci me demande de saisir mon N° d'abonné. Puis il m'affiche la liste de mes chèques. Comment cela se passe?
Le Persistent Store Cordinator lit sur disque, il se sert d'un model de chèque (Le modèle crée avec l'outil de Core data) pour créer une boule verte en lui donnant son numéro, son montant. il fait la même chose s'il lit les donnés d'une personne sauf que dans ce cas il crée une boule rouge.
L'ensemble de ses boules sont alors gérés par le Managed Object Context. Toutes les opérations que j'effectue sur ces boules sont géré par lui.
Lorsque je vailde l'ensemble de mes opérations, le Managed Object Context transmet au Persistence Store Cordinaor qui se sert du Model comme schéma pour écrire les données validées sur disque
Tous ces mouvements sont gérés par Core Data et non par le développeur.
En outre pour ecrire les données sur disque, Apple propose 3 types de format de fichier.
- Un fichier plat de format binaire
- Un fichier de format XML
- Un fichier au format base SQLite
L'utilisation d'un format ou un autre dépend du développeur .
J'espère avoir été assez claire car pour le développeur, c'est une sacré libération et surtout une façon de développer plus élégante et plus fiable.
Pour Apple c'est une phase de plus vers l'industrialisation du processus de développement. Les applications gagnent en puissance, en fiabilité.
Pour les curieux.
En effet ne l'oublions pas Cocoa est un environnement de développement objet qui comprend deux ensembles de classes.
- Application Kit qui contient les classes permettant en général de concevoir les interfaces utilisateurs
- Fondation kit qui regroupe les classses utilisées pour coder des actions ou décrire des données (chaine de caractères, etc).
Le concept de développement utilisant Cocoa est basé sur le principe que l'on appelle MVC comme Model, View, Controller.
En clair cela veut dire que toute application cocoa bien écrite comprend en général trois parties.
- L'interface utilisateur que l'on développe en utilisant Interface Builder et donc les classes de l'Application Kit; c'est donc la View de MVC,
- Les données que l'on utilise dans son appli et que l'on Modélise en utilisant les classes de Fondation Kit. C'est donc le Model de MVC
- et les actions qui permettent de faire le lien entre les deux et qui composent la partie Controller du concept MVC.
Pour aider les développeurs à produire rapidement des applis qui soient robustes, Apple a fourni jusqu'à Panther deux technologies.
Interface Builder pour la partie View, et la technologie des Binding pour faciliter la conception de la partie Controller.
Pour la Partie Model, les développeurs devaient coder tout eux-mêmes.
Exemple :
je développe un soft permettant de gérer des chèques d'achat. Mon interface propose à l'utilisateur de saisir son numéro d'abonné et le montant de la somme à dépenser .
Une autre interface présente à l'utilisateur, la liste des achats effectués et les modifications se font en temps réel.
Vous voyez que l'utilisation des binding dans mon controller permet automatiquement d'effectuer la mise à jour de la liste d'achats chaque fois que l'utilisateur utilise un chèque d'achat. Le développeur n'a aucun code à écrire!
Par contre pour la partie Model, j'ai modélisé les chèques d'achats (N° chèque , montant), l'utilisateur (son nom, prénom, N° d'abonné et la somme disponible de son compte) Ces données sont stockées dans des fichiers que j'appelle CHEQUE et UTILISATEUR par exemple.
En utilisant Cocoa, CHEQUE et UTILISATEUR sont des classes. Pour utilisateur par exemple, nom, prenom etc sont appelés variables d'instance de la classe. Enfin pour gérer mon objet utilisateur (incrémenter ou décrementer le montant du compte), on utilise ce qu'on appelle en jargon objet des méthodes.
Le plus dur c'est que l'on dots également gérer des undo , les redo. Mais surtout les fonctions permettant de sauvegarder ces données sur disque et pouvoir les relire. C'est ce qu'on appelle gérer la persistence des données.
Croyez-moi c'est assez pénible et il faut vraiment penser à tout.
HEUREUSEMENT Core Data est arrivé ( comme zorro).
Que fait Core Data?
Core Data introduit le moyen de gérer automatiquement la partie Model en introduisant le concept de Managed Object Model qui en fait permet au développeur de modéliser l'ensemble des objets de type données utilisées dans son application. Pour le faire, Apple fournit un outil intégré dans Xcode qu'il désigne sous le doux nom de Data Model Design Tool.
Cette modélisation introduit la notion d'Entité pour désigner les Classes ( Entité CHEQUE et Entite UTILISATEUR par exemple), la notion d'attribut pour designer les variables d'instance de classe. Et chose nouvelle, la notion de Relation entre Entités différentes.
Core data introduit aussi plusieurs autres concepts comme celui du Managed Object Context. En effet imaginez qu'un utilisateur ouvre deux interfaces de l'application pour effectuer des achats pour ses chèques et ceux de son épouse. La notion de contexte permet de faciliter la gestion séparée des deux interfaces. Ceci est très important lorsque par exemple le mari et son épouse ont un même compte. cela permet de valider complètement une transaction au niveau du contexte. La gestion des undo et redo se fait également au niveau du contexte..
Pour la gestion des validations concurentes, Core data introduit la notion de Persistence Store Cordinator. C'est lui qui coordone les accés aux données sur le support. Pour cela il se sert de la modélisation.
Pour que vous comprenier encore mieux je vais le préciser par une image.
Imaginez que les objets de l'applications (CHEQUES, UTILISATEURS) utilisés par l'application sont symbolisés par des boules vertes et rouges. Chaque boule verte est un chèque particulier avec son numéro, son montant etc... et chaque boule rouge est un utilisateur avec son nom, prenom etc.
Quand je lance mon application, celle-ci me demande de saisir mon N° d'abonné. Puis il m'affiche la liste de mes chèques. Comment cela se passe?
Le Persistent Store Cordinator lit sur disque, il se sert d'un model de chèque (Le modèle crée avec l'outil de Core data) pour créer une boule verte en lui donnant son numéro, son montant. il fait la même chose s'il lit les donnés d'une personne sauf que dans ce cas il crée une boule rouge.
L'ensemble de ses boules sont alors gérés par le Managed Object Context. Toutes les opérations que j'effectue sur ces boules sont géré par lui.
Lorsque je vailde l'ensemble de mes opérations, le Managed Object Context transmet au Persistence Store Cordinaor qui se sert du Model comme schéma pour écrire les données validées sur disque
Tous ces mouvements sont gérés par Core Data et non par le développeur.
En outre pour ecrire les données sur disque, Apple propose 3 types de format de fichier.
- Un fichier plat de format binaire
- Un fichier de format XML
- Un fichier au format base SQLite
L'utilisation d'un format ou un autre dépend du développeur .
J'espère avoir été assez claire car pour le développeur, c'est une sacré libération et surtout une façon de développer plus élégante et plus fiable.
Pour Apple c'est une phase de plus vers l'industrialisation du processus de développement. Les applications gagnent en puissance, en fiabilité.
Pour les curieux.
Manu a dit:
C'est volontairement que tu utilises les mots Entité et Relation, j'imagine. Pour faire une analogie directe avec les SGBD.
Cela veut-il dire que les principes de base q'un sgbdr seront disponibles directement lors d'un développement et il serait inutile d'intégrer un sqlite ou autre lorsque le développement de l'appli le requiert.
Je suis un rien "naze" en programmation, mais bon ça m'intéresse.
starmac a dit:
Non c'est pas volontairement. ce sont les termes utilisés officiellment. C'est effectivement emprunté aux SGBD relationnelles. D'autre part, SQLite est fourni en standard et tu peux le choisir comme endroit de persistence de tes objets.
D'ailleurs le Persistence Store Cordinator gère automatiquement les 3 types de format.
D'ailleurs j'ai oublié de signaler que l'orsque l'on défini l'attribut d'une entite, on peut également définir les contraintes (par exemple toujours positif, jamais à blanc, etc).
Chose plus interessante, lorsque l'on défini une relation entre entités, on defini également la règle de gestion de suppression. Pour dire si en supprimant un objet, on doit ou non supprimer également tous les objets qui sont en relation avec lui.
Toutes les vérifications de ces contraintes et relations sont gérées par Core data!
Décidément, il va falloir que je m'y mette !
Et personnellement, je n'ai jamais trop apprécié FMP, ni 4D, donc je n'ai pas construit d'appli de gestion sur ces bases (sauf pour notre petite association).
Lors d'un développement d'appli en utilisant CoreData, on pourra donc "encapsuler" (je ne sais pas comment dire) Sqlite dans le code ?
Il ne me reste plus qu'à trouver le bon bouquin en français (de préférence) qui me permette de manipuler et de développer à terme.
Car ce ne sont pas les idées qui manquent.
Et personnellement, je n'ai jamais trop apprécié FMP, ni 4D, donc je n'ai pas construit d'appli de gestion sur ces bases (sauf pour notre petite association).
Lors d'un développement d'appli en utilisant CoreData, on pourra donc "encapsuler" (je ne sais pas comment dire) Sqlite dans le code ?
Il ne me reste plus qu'à trouver le bon bouquin en français (de préférence) qui me permette de manipuler et de développer à terme.
Car ce ne sont pas les idées qui manquent.
starmac a dit:
En fait on n'encapsule rien. Mieux lors du développement on se soucie même pas de l'endroit où seront stockées les données, on se concentre plutôt sur la logique de son application.
Pour préciser le type de stockage que l'on veut utiliser, il y a deux façons de le faire. Il faut savoir que lorsqu'on développe en Cocoa, chaque Appli a ce qu'on appelle une info.plist. C'est une sorte de descriptif de l'Appli. On y décrit les différents paramètres (Option de compilation, type de données que l'appli gère, les ressources utilisées, etc) . Cette info.plist on peut l'éditer dans Xcode via le panel Inspector de la ressource target.
C'est là qu'on peut dire que pour les données de tel type, choisir le stockage de type SQLite.
La seconde façon de le faire c'est dans le programme. Dans une Appli utilisant Core data, il y a un objet NSPersistenceStoreCordinator fourni par défaut. Il suffit, en utilisant une methode de configuration (dont j'ai oublié le nom que je préciserai plutard), de lui associer un store de type NSSQLiteStoreType.
Manu, je vois en toi un bon allié pour mon initiation à Cocoa et à l'utilisation de Xcode.
Pourrais-tu m'indiquer quelques ouvrages (en français de préférence mais je n'y crois pas) traitant de la question. J'ai bien cherché (Eyrolles, Amazon etc), mais les ouvrages de référence datent de 2002 et beaucoup d'eau a coulé sous les ponts depuis cette époque.
Je ne suis pas un dieu de C, mais ça va, je me débrouille. Pour le reste, j'aurai de longues vacances cet été pour décrypter la doc et me familiariser avec les objets et leurs méthodes.
Mon objectif à terme (1 an ? 10 ans ?) : développer un système de gestion pour des centres de vacances (chassez l'associatif, il revient au galop !).
J'en avais fait un sur FMPro en 1995, mais beaucoup trop limité dans son adaptabilité.
Donc deux choix pour moi : le créer en m'appuyant sur php/mysql ou le coder en cocoa.
J'ai envie de tenter l'aventure cocoa.
Pourrais-tu m'indiquer quelques ouvrages (en français de préférence mais je n'y crois pas) traitant de la question. J'ai bien cherché (Eyrolles, Amazon etc), mais les ouvrages de référence datent de 2002 et beaucoup d'eau a coulé sous les ponts depuis cette époque.
Je ne suis pas un dieu de C, mais ça va, je me débrouille. Pour le reste, j'aurai de longues vacances cet été pour décrypter la doc et me familiariser avec les objets et leurs méthodes.
Mon objectif à terme (1 an ? 10 ans ?) : développer un système de gestion pour des centres de vacances (chassez l'associatif, il revient au galop !).
J'en avais fait un sur FMPro en 1995, mais beaucoup trop limité dans son adaptabilité.
Donc deux choix pour moi : le créer en m'appuyant sur php/mysql ou le coder en cocoa.
J'ai envie de tenter l'aventure cocoa.
starmac a dit:
Tu trouveras ce que tu cherches ici
Beaucoup de personnes du thread Developpeurs ont commencé par là.
Manu a dit:
Merci.
J'avais passé un peu de temps sur Project Omega mais je me rends compte que c'était d'un oeil vraiment distrait (ah les ravages de l'Internet sur le désir de réponse instantannée !) : je n'avais pas remarqué que chaque article était disponible en version imprimable et oh comble de la bétise, que le menu des articles était anti chronologique...
Quelle andouille je fais parfois ! Cela promet pour la programmation :siffle:
J'ai omis de signalé que l'info.plist d'une application sert non seulement à définir le type de données que ton applicatioon génère mais, mieux encore (Tiger oblige
) c'est là que le développeur donne des précisions sur le module importeur que doit utiliser Spotlight pour justement pouvoir indexer les données pour permettre à l'utilisateur de les retrouver par ...spotlight.
PS : Un importeur est un module utilis par Spotlight pour pouvoir 'lire' les documents ou données d'un type particulier et donc les indexer. (ex : un importeur PDF).
) c'est là que le développeur donne des précisions sur le module importeur que doit utiliser Spotlight pour justement pouvoir indexer les données pour permettre à l'utilisateur de les retrouver par ...spotlight.PS : Un importeur est un module utilis par Spotlight pour pouvoir 'lire' les documents ou données d'un type particulier et donc les indexer. (ex : un importeur PDF).
