SQLite.swift: Лучший способ реализовать классы моделей, представляющие строки данной таблицы?

Question

Это только вопрос, который я задал (до сих пор), которому не нужно много объяснений.

я получил, насколько это с решением его:

• каждый класс может иметь initialiseTable() вид, как функции, которая будет вызываться, когда схема БД инициализируется?
• статические константы в каждом классе для столбца Expression<T>

Я предполагаю, что часть я размышлял о наиболее заполняют экземпляры классов моделей с Query результатов.

Как всегда, заранее спасибо за помощь :)

Ссылки на удивительный SQLite.swift для тех, кто не сталкивался еще.

Update (22/4/15 14:13):

Подумав об этом, я не уверен, о хранении данных строки в Иварс, поскольку это может стать сложно тренировки экономя и обновляя логистику и чрезмерно сложные вещи.

Тем не менее, я по-прежнему считаю, что классы моделей для представления строк - хорошая идея. Я думаю, что основным преимуществом наличия классов моделей, представляющих таблицы строк, является безопасность. Зная, что, например, у Query есть столбец name : Expression<String>. Это здорово, если вы начнете передавать Query экземпляры между классами

Как я уже сказал, я не уверен, действительно ли хотелось бы начать создание класса с iVars для каждого столбца для представления строк. Если вы это сделаете, вы можете начать посещать ORM-землю, которая, как мне кажется, занимает упрощенную красоту SQLite.swift. Единственное преимущество, которое я могу придумать, сохраняя iVars для каждого столбца, это то, что вы могли бы вызвать refresh() на экземпляр, который будет извлекать последние данные из БД, а затем все остальные объекты, указывающие на этот экземпляр, будут иметь самые последние данные без чтобы попасть в БД сами.

Возможно, у вас есть класс, который выполняет подклассы Query и имеет конструктор, который берет базу данных и инициализирует ее с правильным именем таблицы? Возможно, это могло бы иметь геттеры как-то для столбцов строк.

Я просто вслушиваюсь вслух, пытаясь дать пищу для размышлений. Эти идеи довольно незрелые и молодые, просто думая об ограничениях и преимуществах в моей голове каждого подхода, который вы могли бы принять. Вернусь и добавлю/изменим больше, когда усовершенствую идеи.

Update (24/4/15 9:45):

Возможно, классы модели должны быть просто прокси к таблицам БД? Каждый класс имеет сеттер для каждого поля, которое сразу записывается в БД, так что конфликт не существует, поскольку он всегда отражает то, что находится в БД. Но тогда вы не сможете справиться с тем, как часто вы легко попадаете в БД? НО. Вы часто меняете свои ценности?

Answer 1

Оформить заказ http://github.com/groue/GRDB.swift. Она обеспечивает готовый класс записи, а также ориентированные протоколы, которые предоставляют выборку и методу сохраняемости к любому из вашей пользовательской структуры или класса:

let persons = Persons.fetchAll(db, ...) 
try Person(...).insert(db) 

Update: GRDB является протокол-ориентированной библиотекой, которая означает, что он поддерживает неизменные модели. Это совсем не похоже на Core Data или Realm, и есть последствия для дизайна приложения. Отъезд How to build an iOS application with SQLite and GRDB.swift