iPhone et SQLite: comment gérer la connexion à la base de données avec plusieurs classes?

Question

J'ai quelques doutes sur SQLite ... Mon application utilise une seule table (encapsulé dans une classe logique de données) pour stocker de petites données, la connexion est ouverte à didFinishLaunchingWithOptions et Finalisé en applicationWillTerminate (oui, je sais que dans iOS4 applicationWillTerminate est seulement appelé par iSO si nécessaire, mais j'écris sur la base de données à chaque changement de données).

Maintenant, je dois ajouter une deuxième table (et une classe relative) qui va stocker des données différentes (pas de jointure entre les deux tables) et de taille normale (environ 1-2 lignes pour le jour). J'ai pensé à appliquer le modèle singleton pour partager la connexion et les instructions, mais j'ai lu que pour des raisons de performances, il est recommandé d'utiliser des variables de classe locales pour maintenir la connexion.

Alors, quelle est la meilleure pratique? Singleton ou deux connexion ouverte? Quelle solution recommanderiez-vous pour ma situation?

Merci

Answer 1

Pour une utilisation si simple, un singleton est probablement la bonne réponse pour les raisons mêmes que @Eiko mentionne. Cependant, tout cela soulève la question suivante: pourquoi n'utilisez-vous pas les données de base? L'utilisation correcte de SQLite est en fait assez difficile et j'ai vu des dizaines d'ingénieurs très talentueux/expérimentés se tromper complètement sans s'en rendre compte. Pire, la mise à l'échelle d'une implémentation existante est encore plus difficile. Ajout de la concurrence est vraiment vraiment dur avec SQLite droite (et les ingénieurs Core Data ont dépensé une énorme quantité d'énergie et ont appliqué une tonne d'expertise pour soutenir la concurrence sur SQLite correctement).

Pour une utilisation aussi simple, Core Data ne sera pas difficile à apprendre et vous offrira une base de code beaucoup plus solide et polyvalente.

Answer 2

Singleton pour moi lorsqu'ils sont stockés dans la même base de données.

De petites quantités de données ne devraient pas être un goulot d'étranglement au niveau des performances.

Ou, bien sûr, aller avec CoreData. :-)