C#数据处理设计模式:通过ORM存储在数据库中的对象，直接与数据库协同工作

本文关键字：数据库对象协同工作设计模式通过 ORM 存储数据处理 | 更新日期: 2023-09-27 18:27:24

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

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

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

我担心的是，在所有时间都将是的资源和性能障碍

取决于你如何与htem合作。

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

这真的取决于情况。

一般来说，这不是一个容易的问题——大多数时候，执行SQL查询更容易，但内存缓存确实可以提高性能。是的，它使用内存。世界卫生组织关怀-现在工作可以有64gb的内存。问题是从一场演出中看它是否有意义。

具体来说，在交易时将所有变更/销售都保存在数据库中，而不是无论何时ORM持续存在，对我来说都很重要。

逻辑错误。ORM将把它们作为ORM事务的一部分持久化。缓存自然不会是"一个ORM事务"，而是独立于更新的事务。如果naORM进入你的方式，它要么是世界上最吸引人的ORM，要么你的应用程序体系结构被破坏了。

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

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

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