На уровне реляционной БД есть несколько взаимно связанных таблиц с метаданными для пользовательского интерфейса (например, имена колонок). При запуске приложения MetadataProvider должен создавать/обновлять локальную копию этих таблиц. Для настольного приложения эту копию планируется хранить в оперативной памяти, для мобильного — в локальной СУБД.
В .NET абстракцией над реляционной моделью являются классы из пространства
System.Data и можно было бы создать DataSet, а в нем ряд типизированных таблиц для каждого вида метаданных, но будет ли этот подход практичным по сравнению с набором справочников вида
Dictionary<int, GuiViewColumnObject> // здест int это первичный ключ из БД
Мне второй подход кажется более "оопешным". Правда, у него есть минус в виде отсутствия контроля ссылочной целостности. Например, если один объект метаданных ссылается на другой (например, GuiViewColumnObject содержит свойство GiuViewObjectId, то не существует того жесткого контроля ссылочной целостности, который предлагает DataSet.
Впрочем, кеш метаданных на то и кеш, что обновляется сравнительно редко — данные в основном запрашиваются. И не понятно, даст ли использование DataSet со вложенными таблицами (пусть даже типизированными) преимущество перед работой со справочниками?
Единственный аргумент за DataSet, который я пока нашел, это вроде как легче сбрасывать в локальную СУБД (если она реляционная).
При этом структуры данных для ADO достаточно древние и обращаться к ним через Linq можно только после приведения к IEnumerable, что наверное более накладно, чем обращение через DataReader.
В общем, оправдано ли использование DataSet для хранения локального кеша реляционной структуры данных, если для части приложений нужно будет хранить данные этого кеша в СУБД?
