Как бы вы хранили табличные постоянные данные в вашем C # проекте?

Question

В настоящее время я пишу плагин для программного обеспечения в стиле CAD. Плагин выполняет расчеты на основе данных, прочитанных из модели CAD, и большого количества табличных поисков (например, напечатано таблиц в руководстве по расчетам). Я унаследовал этот плагин, и текущее решение определяет класс Constant, который имеет набор статических членов структуры и двумерных массивов. Эти массивы затем индексируются значениями enum во время выполнения для поиска соответствующих данных.

Я не слишком доволен решением, так как представление в классе Constant довольно сложно для чтения - значения перечисления, используемые при получении данных, конечно, не видны, когда редактирование данные (хотя это случается только вручную и очень редко).

Я бы предпочел не связывать БД (и движок) с небольшим плагином, но хотел бы иметь похожую семантику, например, используя LINQ для выбора значений, где совпадают некоторые поля и т. Д.

Каково ваше предпочтительное решение этой проблемы?

• Вы используете кучу файлов XML и анализируете их во время выполнения?
• Вы используете шаблонизатор (t4?) Для генерации классов из файлов XML во время компиляции?
• храните ли вы XML-версии наборов данных в ресурсах (читайте их во время выполнения, LINQ to dataset ...)
• Вы бы просто сохранили класс Constants, возможно, добавили бы некоторую документацию для участников (не заставляйте меня начинать с унаследованного кода без каких-либо комментариев ...)

Answer 1

Я делаю это в данный момент для приложений, критичных к производительности. Я делаю это путем сериализации данных в виде плоского файла (как часть моего процесса выпуска), а затем (при запуске) десериализации их в модель класса, что позволяет выполнять запросы LINQ-to-Objects.

В большинстве сценариев xml было бы разумным, но по предпочтению я использую свой собственный двоичный сериализатор - в основном для скорости.

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

Чтобы уточнить: используемые данные хранятся в стандартной базе данных (они хороши в таких вещах, и существует множество инструментов для импорта / редактирования / запроса / и т. Д.). В рамках процесса выпуска я загружаю данные в объектную модель (используя те же классы) из базы данных и сериализую их:

// during release
MyDataModel data = new MyDataModel(); // wraps multiple data lists
data.Load(); // from database tables, using ORM
data.Save("data.bin"); // serialization

затем я отправляю data.bin вместе с приложением (ну, на самом деле, он хранится отдельно, но это не так ...); и во время выполнения:

MyDataModel data = new MyDataModel();
data.Load("data.bin"); // deserialization
data.Freeze(); // make immutable

Обратите внимание, что в этом случае данные являются «неизменными эскимо» - то есть, чтобы сохранить «постоянный» характер (но, позволяя редактировать данные во время загрузки), у меня есть каскадный метод Freeze, который устанавливает флаг предметы; как только этот флаг установлен, все изменения (для элементов или списков) вызывают исключение. Это отрицательно сказывается на производительности или на работающем коде: поскольку вы ожидаете обрабатывать его как постоянные данные, он только читает!

Answer 2

Если развертывание является проблемой, вы всегда можете встроить файл XML в вашу сборку. Это обеспечивает тот же уровень постоянства, поскольку пользователи не смогут копаться в данных.

Любой файл можно внедрить в качестве ресурса с помощью VS, просто добавьте файл в проект и выберите: Build Action => Embedded Resource из свойств.

Тогда при запуске вы можете позвонить:

// name is the name of the embedded resource
Assembly.GetExecutingAssembly().GetManifestResourceStream(name); 

Чтобы получить поток для встроенных данных.

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

Answer 3

Если производительность не является ограничением, я бы использовал подход XML-dataset-in-resources. Это довольно очевидно (так что любой, кто заберет у вас код в будущем, не будет озадачен его внешним видом), его легко редактировать и получать к нему доступ, и нет необходимости заново изобретать колесо в виде настраиваемого парсера табличного XML данные.

Answer 4

Я бы поддержал предложения по использованию XML (будь то база ресурсов или нет), но хотел бы немного остановиться на вопросах синтаксического анализа / редактирования / обработки этого сценария.

---

Сначала короткое примечание, касающееся вопроса, связанного с Pavels , ответит, возможно ли визуальное редактирование XML с помощью редактора таблиц в Visual Studio (VS): это было на самом деле в VS 2003 (см., Например, ' Рисунок 6.28. Документ XML: представление данных ' здесь о том, как это выглядело), ​​в VS 2005 функция была несколько понижена (см., Например, Внешний вид XML в Visual Studio 2005 против Visual Studio 2003 ) и в VS 2008 окончательно удален (см., например, Редактор XML-данных отсутствует в Visual Studio 2008 ), что весьма прискорбно, так как он имел свои применения и мог бы вам здесь тоже помочь. Та же (вероятно связанная) судьба относится и к конструктору схем XML, который, по крайней мере, получит замену в VS 2010, пока не знает о новом представлении данных XML.

---

Возвращаясь к исходному вопросу: учитывая ваши требования, вы можете предоставить выделенную XML-схему для ваших XML-файлов. Оказавшись на месте, любой приличный редактор XML сможет по крайней мере предоставить Intellisense (т. Е. значения перечисления видны при редактировании ) и предупредить вас об ошибочных записях данных. Если редактирование источников XML таким способом все еще кажется «сырым», вы можете получить более удобное редактирование «без источника» с помощью чего-то вроде XML Notepad 2007 .

Тем не менее, наиболее важным преимуществом наличия схемы XML является то, что это позволяет автоматизировать использование с помощью инструментов, в частности, вы можете генерировать оба, простые старые классы .NET и / или LINQ включил наборы данных из него через Microsoft Инструмент определения схемы XML (Xsd.exe) . (Для хорошо известных структурированных данных, т. Е. На основе схемы XML, это гораздо предпочтительнее, чем использование утомительного настраиваемого решения на основе t4.)

Конечно, получение схем в первую очередь и их правильное применение на практике может потребовать некоторых усилий, но это окупается за любую серьезную разработку, связанную с XML, imho.

И для текущей задачи вы, возможно, уже лучше и сможете выводить XML-схему из существующего класса Constant, см. Ключ / t для Xsd .exe . Вероятно, первоначальный результат может быть неполным или не совсем адекватным, но с небольшим предварительным рефакторингом и / или ручной настройкой вы сможете довольно быстро получить приличную схему.

В результате вы сможете работать со своей базой кода примерно так же, как сейчас (предположительно), т.е. у вас будут строго типизированные перечисления и т. Д., Или вы можете переключаться с использованием данных XML через наборы данных с поддержкой LINQ. как вам угодно (на самом деле вы можете сделать оба параллельно).

Answer 5

Вы можете создать класс Constant.
Таким образом, вы можете хранить свои данные в более удобном методе, таком как файл MDB (MS Access) или MDF (SQL Express). Редактирование этих файлов удобно для пользователя.

Я предлагаю вам иметь дополнительный проект, который генерирует класс Constant вашего основного проекта со всеми необходимыми данными в качестве констант. Дополнительным проектом может быть Консольное приложение. Используйте событие перед сборкой в ​​главном проекте для запуска этого консольного приложения, и тогда у вас будет сгенерированный класс.