C# 数据处理设计模式 : Objects stored in DB via ORM, 直接与数据库一起工作？

Question

考虑一个存储商店库存的应用程序，其中包含数百种商品类型和每种商品的数量。我目前有一个可以处理这个问题的数据库，由于具有过程编程的背景，所以设计起来很自然。但是，我现在使用 OOP 语言 (C#) 工作，并且正在考虑将库存和其他实体(分支机构、员工、供应商)存储为 CLR 对象，分组在 ObservableCollections 中，然后通过 ORM 持久化到数据库，例如NHibernate。

我担心的是，内存中始终包含数百或数千个项目的 ObservableCollections 将成为资源和性能障碍。考虑到设备故障或断电，我还担心潜在的数据丢失。由于系统将记录金融交易(销售)，因此数据库的可靠性相当重要。具体来说，在交易时将所有更改/销售记录在数据库中，而不是在 ORM 持续返回时对我来说很重要。

我应该直接使用数据库，还是应该使用对象并让 ORM 处理存储？

Answer 1

My concern is that having ObservableCollections with hundreds or thousands of items in memory at all times will be a resource and performance barrier

取决于您如何使用 htem。

我有一项服务，通过字符串键在内存中保存大约 25 万个项目。我每秒对它们进行大约 50,000 次更新，然后将更新传输到数据库 - 不是作为更新，而是作为带有时间戳的新数据(跟踪随时间的变化)。

这确实取决于。

总的来说，这不是一个简单的问题 - 大多数时候执行 SQL 查询更容易，但内存缓存确实可以提升性能。是的，它使用内存。谁在乎 - 如今，工作站可以有 64GB 内存。问题是从表演来看这是否有意义。

Specifically, having all changes / sales in the database at the time of transaction, as opposed to whenever the ORM persists back is important to me.

逻辑错误。 ORM 会将它们保留为 ORM 事务的一部分。当然，缓存不会是“一个 ORM 事务”，而是独立于更新的事务。如果某个 ORM 妨碍了您，那么它要么是世界上最糟糕的 ORM，要么您的应用程序架构已损坏。

对财务数据的所有更新都应该在数据库级事务中进行，并且我知道的每个 ORM 都支持这一点。

Should I work directly with the database, or should I work with objects and let the ORM handle the storage?

取决于要求。我喜欢 ORM，但最近转向了面向服务的架构，在其中更新 moemry 表示，然后将事务流式传输到数据库。但是然后我进行流数据传入/没有逻辑决定(数据来自外部源并且必须进行处理，不可能出错，不可能丢失 - 如果 soemthign 在我这边爆炸，应用程序的下一次启动会得到相同的结果再次数据，直到我说我处理了它)。