Лучшая структура объекта для объекта linq?

Question

У меня есть программа, которая хранит данные в объектах в памяти, которые вы можете представить как маленькие db в памяти. Я хотел бы использовать LINQ to Objects для запуска некоторых простых запросов в объектах памяти. Есть ли предпочтительная структура, которую я должен использовать для объектов памяти. Есть ли хорошие ресурсы, которые я должен прочитать, прежде чем я углубится в этот проект.

Редактировать: Подробнее о приложении.

Это приложение winforms, которое также может работать как служба. Он будет отслеживать состояние около 10 тыс. Объектов макс. Каждый объект довольно самодостаточен, поэтому я не думаю, что мне нужно будет сделать много соединений, если они есть. Поскольку он может работать как служба, я добавляю интерфейс, который может запрашивать информацию об объектах. Запросы будут задавать вопросы и группировать объекты, не изменяя их. Каждый объект будет больше похож на объект клиента, чем на объект продукта.

Answer 1

Rex, первые несколько вопросов:

• Является ли это WinForms/WPF-приложение или ASP.NET? Может быть актуальным, поскольку «маленький» след в памяти может стать «большим» при тиражировании для каждого пользователя/пользователя/и т. Д.

• «small db» - как мало вы здесь говорите? 10kb, 100kb, 1Mb? На самом деле, я не думаю, что размер такой же важной, как и выбранная вами структура (в пределах, например, в физической памяти!), Но это может быть полезно для других ответчиков.

• «простые запросы» - можете ли вы предоставить дополнительную информацию о том, как выглядят объекты и запросы? У вас есть Customer с Name,Address,Age, или вы больше думаете о Products с несколькими Sizes, размещенными в нескольких Orders с разными Payment s ... или чем-то еще сложнее?

Тогда некоторые мысли:

• сохранить объект графика/дерево/иерархии плоские (в частности, свойства, которые вы хотите запросить). Linqing на where Customer.Zipcode = 90210, похоже, не очень отличается от where Customer.Address.Zipcode = 90210, но мне кажется, что чем сложнее вы получите с вложенными объектами, тем сложнее будет создавать фреймворки для создания эффективных запросов.

• Если вы уже знаете, какие запросы будут заблаговременно, и они важны для вашего приложения, возможно, вам следует «создавать» структуры данных для поддержки запросов, а не просто полагаться на Linq? Например, поисковая система searcharoo.net хранит все свои данные в памяти в виде объектов (может быть 1-2 Мб или более), но механизм запросов - это пара пользовательских (ref), которые очень быстры.

Говоря на ваш комментарий думать как небольшой дб в памяти, есть два «продуктов», которые могли бы полезны для вас:

• Indexed Linq должен позволить вам указать индексов в вашей коллекции объектов, чтобы ускорить выполнение определенных запросов. Это незавершенное производство, но может быть полезно для ваших нужд.

• Сайт ComponentOne LiveLinq говорит: «LiveLinq использует индексирование и другие оптимизации для ускорения запросов LINQ в памяти». Это звучит так же, как Indexed Linq, но будет коммерческим продуктом.

НТН

Answer 2

Есть много ресурсов, которые показывают, как выполнять LINQ to POCO (обычные объекты CLR). Вот лишь некоторые из них, чтобы вы начали ...

MSDN Overview

Simple Example Code

Detailed Example Code