Best object structure for linq to object?

Question

I have a program that stores data in objects in memory that you can think of as small db in memory. I would like to use LINQ to Objects to run some simple queries on the in memory objects. Is there a preferred structure that I should use for the in memory objects. Are there any good resources that I should read before I get to far into this project.

Edit: Here is more info on the application.

It is a winforms application that can also run as a service. It will track the state of around 10k objects max. Each object is fairly self contained so I don't think I will need to do a lot of joins if any. Since it can run as a service I am adding a interface that can query the info about the objects. The queries will be asking questions and grouping the objects not modifying them. Each object will look more like a customer object than say a product object.

Answer 1

There are lots of resources that show how to perform LINQ to POCO (Plain Old CLR Objects). Here are just a few to get you started...

MSDN Overview

Simple Example Code

Detailed Example Code

Answer 2

Rex, first a few questions:

• Is this a WinForms/WPF app or ASP.NET? Could be relevant as a 'small' footprint in memory can become 'large' when replicated for each user/sesion/etc.

• 'small db' - how small are you talking here? 10kb, 100kb, 1Mb? Actually I don't think the size is as important as the structure you choose (within limits, such as physical RAM!) but it might be helpful for other answerers.

• 'simple queries' - can you provide more info on what the objects and queries look like? Do you have a Customer with Name,Address,Age, or are you more thinking about Products with multiple Sizes placed in multiple Orders with different Payments... or something even more complex?

Then some thoughts:

• Keep the object graph/tree/hierarchy flat (in particular the properties you wish to query). Linqing on where Customer.Zipcode = 90210 doesn't seem much different to where Customer.Address.Zipcode = 90210 but it seems to me that the more complex you get with nested objects the harder it will be for the framework to create efficient queries.

• If you already know what the queries will be in advance, and they are important to your application, perhaps you should "build" datastructures to support the queries rather than just rely on Linq? To give an example, the searcharoo.net search engine stores all it's data in memory as objects (can easily be 1-2Mb or more) but the querying mechanism is a couple of custom Hashtables (ref) which are very quick.

Speaking to your comment think of as small db in memory, there are two 'products' that might useful for you:

• Indexed Linq is supposed to allow you to specify indexes on your object collection to make certain queries faster. It is a work-in-progress but might be useful for your needs.

• ComponentOne LiveLinq's website says "LiveLinq uses indexing and other optimizations to speed up LINQ queries in memory". It sounds a lot like Indexed Linq but will be a commercial product.

HTH