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

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

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

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

• Каковы требования безопасности для данных? Если данные централизованы, с несколькими пользователями (одновременными или последовательными), вам может потребоваться управлять безопасностью и разрешениями для данных. Не видя данных, трудно сказать, будет ли легче управлять с помощью файловой персистентности или базы данных.

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

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

О кроссплатформенных проблемах: если вы этого не сделаете Знайте наверняка , что кросс-платформенные функциональные возможности потребуются в будущем, не создавайте его сейчас. В целом почти наверняка легче решить эту проблему, когда придет время (миграция и т. Д.), Чем ограничить свое развитие сейчас. Чаще всего ЯГНИ .

Об обмене данными между частями приложения: Это должно быть встроено в само приложение, например, в классы, которые обращаются к данным. Не перегружайте механизм персистентности, чтобы он также был каналом передачи данных между частями приложения; если вы перегрузите его таким образом, вы преобразуете постоянное состояние в контракт между объектами, вместо того, чтобы надлежащим образом рассматривать его как расширение частного состояния объекта.

Конечно, это зависит от того, что вы хотите сериализовать. В некоторых случаях сериализация смехотворно проста.

(Однажды я написал программу на Java, где вы можете рисовать и перетаскивать объекты. Если вы были готовы, вы можете сохранить его в файл (например, myTimeline.til). В этот момент сотни объектов были сохранены, их положение на холсте, их размер, их цвета, их внутренние тексты, их спецэффекты, ...

Вы могли бы, конечно, открыть myTimeLine.til и работать дальше.

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

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

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

Моя точка зрения первая: , безусловно, есть несколько сценариев, в которых базы данных не будут лучшим решением. Сериализация не была изобретена разработчиками только потому, что им было скучно.

1. Неверно, если вы используете XMLserialization или SOAP.
2. Уже не совсем актуально.
3. Только если вы не будете осторожны, используйте для этого множество «лучших практик».
4. Только если вы хотите, чтобы это было проблематично,

См. в этой публикации Stackoverflow для комментария о применимости XML и применимости системы управления базами данных. В нем обсуждается вопрос, который очень похож на предмет обсуждения в вашей команде.

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

1. Ну, вы всегда можете написать конвертер в C #, чтобы извлечь данные позже, если это необходимо.

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

3. Это путь мира. Сожги мосты и требуй апгрейдов. Преобразуйте данные или создайте инструмент для этого, а затем больше не поддерживайте способ старой версии.

4. Нет, если программа C # передает данные другим приложениям. Другие приложения не должны получать доступ к данным, которые принадлежат этому приложению напрямую, должны ли они?

Для передачи и автономного хранения, сериализация в порядке; но для активного использования какая-то база данных гораздо предпочтительнее.

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

Некоторые другие ваши болевые точки относительно сериализации не все верны - если вы выбираете мудро. Очевидно, что BinaryFormatter является плохим выбором для переносимости и управления версиями , но «буферы протокола » (формат сериализации Google) имеют версии для Java, C ++, C # и много других , и предназначен для устойчивости к версии.

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

Да, вероятно, правда. Обратной стороной является то, что вы должны получить весь объект, что похоже на получение всех строк из таблицы. А если он большой, то это будет обратная сторона. Но если он не такой уж и большой, а с моими хобби-проектами они не такие большие, может, они идеально подходят?