C# Data handling design pattern: Objects stored in DB via ORM, work directly with the database?

Question

Consider an application that stores inventory for a store, which consists of hundreds of item types and quantities of each item. I currently have a database mapped out which can handles this, which was natural to design due to a background in procedural programming. However, I am now working in an OOP language (C#) and I am considering storing the inventory and other entities (branch offices, employees, suppliers) as CLR objects, grouped in ObservableCollections, and then persisted to the database via an ORM such as NHibernate.

My concern is that having ObservableCollections with hundreds or thousands of items in memory at all times will be a resource and performance barrier. I am also worried about potential dataloss considering equipment failure or power outage. As the system will be recording financial transactions (sales) the reliability of a database is rather important. 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.

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

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

Depends how you work with htem.

I have a service keeping about a quarter million items by string key in memory. I do up to around 50.000 updates on them per second, then ttream the udpates out to the database - not as updates but as new data with timestamp (track change over time).

It really depends.

In general this is not an easy question - MOST of the time it is easier to do a SQL query, but an in meemory cache can really BOOST performance. Yes, it uses memory. WHO CARES - worksations can have 64gb memory these days. THe question is whether it makes sense from a performance.

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.

LOGICAL ERROR. An ORM will persist them as part of the ORM transaction. Naturally the cache would not be "one ORM transaction" but independent of transactions updated. If na ORM gets into your way here, it is either the worlds most sucking ORM or your application architecture is broken.

All updates to financial data should happen in a database levele transaction and every ORM I know of supports that.

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

Depends on requirements. I love ORM's but hav gone lately to a service oriented architecture where I update in moemry representations thn stream the transaction out to the database. But then I do streaming data inocoming / No decision in logic stuff (data comes from external soruce and HAS to e be processed, no error possible, no loss possible - if soemthign blows on my end, the next start of the app gets the same data again, until I say I processed it).