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

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

Я дошел до этого, решив это:

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

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

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

Ссылка на awesome SQLite.swift для тех, кто еще не сталкивался с этим.

Обновление (22/4/15 14:13):

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

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

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

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

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

Обновление (24/4/15 09:45):

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

1 ответ

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

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

Обновление: GRDB - это протокол-ориентированная библиотека, что означает, что она поддерживает неизменные модели. Это совсем не похоже на Core Data или Realm, и есть последствия для дизайна приложения. Проверьте Как создать приложение iOS с SQLite и GRDB.swift

licensed under cc by-sa 3.0 with attribution.