Меня беспокоит то, что наличие ObservableCollections с сотнями или тысячами элементов в памяти всегда будет препятствием для ресурсов и производительности.
Зависит от того, как вы работаете с htem.
У меня есть служба, хранящая в памяти около четверти миллиона элементов по строковому ключу.Я делаю до 50.000 обновлений в секунду, а затем передаю обновления в базу данных - не как обновления, а как новые данные с отметкой времени (отслеживание изменений во времени).
Это действительно зависит.
В общем, это непростой вопрос - в большинстве случаев проще выполнять SQL-запросы, но кэш в памяти может действительно повысить производительность.Да, он использует память.ВОЗ ЗАБОТИТСЯ - рабочие дни могут иметь память 64 ГБ в эти дни.Вопрос в том, имеет ли это смысл с точки зрения производительности.
В частности, для меня важно иметь все изменения / продажи в базе данных во время транзакции, а не всякий раз, когда ORM сохраняется обратно.
ЛОГИЧЕСКАЯ ОШИБКА.ORM сохранит их как часть транзакции ORM.Естественно, кеш будет не «одной транзакцией ORM», а независимым от обновленных транзакций.Если на вашем пути встанет na ORM, то это либо самый отвратительный ORM в мире, либо ваша прикладная архитектура нарушена.
Все обновления финансовых данных должны происходить в транзакции уровня базы данных, и каждый известный мне ORM поддерживает это..
Должен ли я работать непосредственно с базой данных или работать с объектами и позволить ORM управлять хранилищем?
Зависит от требований.Мне нравятся ORM, но в последнее время я обратился к сервис-ориентированной архитектуре, где я обновляю представления moemry, чтобы транслировать транзакцию в базу данных.Но затем я делаю потоковую передачу данных / нет решения в логике (данные поступают из внешнего источника и ДОЛЖНЫ быть обработаны, ошибки невозможны, потери невозможны - если у меня не получится, то следующий запуск приложения будет таким жеданные снова, пока я не скажу, что обработал их).