Ceci est seulement la question que j'ai demandé (jusqu'à présent) qui n'a pas besoin de beaucoup/aucune explication.SQLite.swift: Meilleure façon d'implémenter des classes de modèle représentant les lignes d'une table donnée?
j'avais obtenu aussi loin que cela avec le résoudre:
- chaque classe peut avoir un
initialiseTable()type de fonction comme qui serait appelée lorsque le schéma DB est initialisée? - constantes statiques dans chaque classe pour la colonne
Expression<T>
Je pense que la partie je méditée sur la plupart des cas est le remplissage des classes de modèle avec Query résultats.
Comme toujours, merci à l'avance pour l'aide :)
Lien vers le SQLite.swift impressionnant pour ceux qui ne l'ont pas encore rencontré.
Mise à jour (22/4/15 14:13):
Après réflexion, je ne suis pas sûr de stocker des données de ligne Ivars car il peut devenir difficile à l'entraînement sauver et mettre à jour la logistique et compliquer les choses.
Cependant, je pense toujours avoir des classes de modèle pour représenter les lignes est une bonne idée. Je pense que le principal avantage d'avoir des classes de modèles représentant des lignes de table est la sécurité. Sachant qu'un Query a la colonne name : Expression<String>, par exemple. C'est très bien d'avoir si vous commencez à passer Query instances entre les classes
Comme je l'ai dit, je ne suis pas sûr si l'on veut vraiment commencer à faire une classe qui a iVars pour chaque colonne pour représenter les lignes. Si vous faites cela, vous pourriez commencer à entrer dans la terre ORM qui, je pense, prend la beauté simpliste de SQLite.swift. Le seul avantage que je peux penser en conservant iVars pour chaque colonne serait que vous pourriez appeler refresh() sur une instance qui récupèrerait les dernières données de la base de données, puis tous les autres objets pointant sur cette instance auraient les dernières données sans avoir frapper la DB eux-mêmes.
Peut-être juste avoir une classe qui sous-classe Query et a un constructeur qui prend une base de données et s'initialise avec le nom de table correct? Peut-être que cela pourrait avoir des getters d'une manière ou d'une autre pour les colonnes de rangée.
Je pense juste à voix haute ici en essayant de donner de la matière à réflexion. Ces idées sont assez immatures et jeunes, je pense juste aux limites et aux avantages de chaque approche que vous pourriez prendre. Je reviendrai et ajouter/changer plus quand j'ai affiné les idées.
Mise à jour (24/4/15 09:45):
Peut-être que les classes du modèle devrait être juste proxies aux tables DB? Chaque classe ayant un setter pour chaque champ qui écrit directement dans la base de données afin qu'il n'y ait pas de conflit dans l'état car il reflète toujours ce qui se trouve dans la base de données. Mais alors vous ne seriez pas capable de gérer combien de fois vous allez à la DB si facilement? MAIS. Changez-vous vraiment des valeurs souvent?
pourquoi ne pas utiliser un coredatastore? Aucun fichier modèle? –
Parce que CoreData. . Je ne veux pas utiliser CoreData. Je vais laisser tous les autres tweets et les messages que vous pouvez trouver là-bas, comme [celui-ci] (http://www.objc.io/issue-4/SQLite-instead-of-core-data.html), expliquer Pourquoi. En outre, le point est que je veux des classes de modèles, pour mieux se protéger contre les bogues. Vous n'avez pas non plus besoin de classes de modèle avec SQLite.swift. – kylejm
Je dois m'asseoir et écrire une bonne réponse avec quelques options, mais vous pouvez commencer par voir comment Firefox utilise SQLite.swift ici: https://github.com/mozilla/firefox-ios/blob/3ab72ff547ccc798fbb166f98c57c60425ca19b7/ReadingList/ReadingListSQLStorage .rapide – stephencelis