Meilleure bibliothèque d'encapsulation Cacao / Objective-C pour SQLite sur iPhone

Question

Je suis de développer pour l'iPhone et suis à la recherche d'un bon Cocoa/Objective-C de la bibliothèque pour travailler avec SQLite. Je ne veux pas utiliser la norme de procédure SQLite C API. Je vois options à sqlite.org en vertu de l'Objective-C section, mais je ne suis pas sûr de qui est le meilleur en termes de la bibliothèque de conception d'API, la stabilité et la fonctionnalité. Je voudrais utiliser quelque chose qui est activement développé et, nous espérons, sera autour pendant un certain temps. Quelqu'un a des suggestions basées sur l'expérience de l'aide?

Merci

Answer 1

Personnellement , j'utilise FMDB et la dernière mise à jour date de hier.

Answer 2

Je suis aussi un fan de FMDatabase, bien que j'ai eu à personnaliser ma propre version de celui-ci. Mes applications utiliser une couche autour de ce que j'ai écrit appelé ArchDBObject que de manière transparente convertit les objets vers et à partir d'une base de données de la représentation; je suis en train de penser au sujet de sortir d'une certaine forme, mais je n'ai pas vraiment décidé encore.

En tout cas, FMDatabase peut être dû à des http://code.google.com/p/flycode/source/browse/trunk/fmdb/.

Answer 3

Le plus simple que j'ai trouvé est celui-ci https://github.com/misato/SQLiteManager4iOS

SQLiteManager par l'Ester de Sanchez.

Il est fondamentalement comme ceci:

NSArray *results = [dbManager getRowsForQuery:@"SELECT * FROM table WHERE id = 1"];

results est un tableau contenant des dictionnaires. Chaque dictionnaire est une seule ligne retournée, où les clés sont les noms de chaque colonne de la table.

Après cela, vous pouvez faire des choses comme ceci:

NSDictionary *aPerson = [results objectAtIndex:0];
NSString *firstName = aPerson[@"firstName"];
NSString *email = aPerson[@"email"];

Answer 4

FMDB est bien, car c’est le moyen le plus léger de ne pas avoir à traiter les appels en C et les conversions de type, tout en vous donnant un accès complet au code SQL.

Ce que je n’aime généralement pas avec les wrappers relationnels-objets, c’est que vous vous éloignez trop du code SQL généré et que la performance commence à en souffrir.

Answer 5

Edit: rien de cela n'est vrai:

Nous utilisons sqlitepersistentobjects. C'est très bon à se cachant de tous les la mécanique de l'interfaçage avec SQL loin à partir de votre code Objective-C. Il y a quelques défauts mais c'est en vertu de l'actif développement par Jeff Lamarche, le auteur de l'excellent Début Développement iPhone.

Google code les hôtes de la source.

Le bémol serait qu'il est parfois trop intelligent et si vous frappez un problème, le débogage/intégration est difficile.

Nous avons laissé tomber SQLite Objets Persistants en faveur de CoreData dès que CoreData était disponible. Si quelqu'un est à la recherche à cette question, je suggère fortement CoreData comme le seul moyen raisonnable d'y aller.