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

Question

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

2

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

Изменить: Подробнее о приложении.

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

Rex Logan 14 март 2009, в 03:31

Источник

0

Было бы полезно, если бы вы дали немного больше информации и пример или два.
Henk Holterman 14 март 2009, в 09:41

Теги:

c#

linq

winforms

linq-to-objects

2 ответа

1

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

Обзор MSDN

Простой пример кода

Подробный пример кода

Phil Wright 14 март 2009, в 09:58

Ещё вопросы

Было бы полезно, если бы вы дали немного больше информации и пример или два.

Conceptdev · Accepted Answer · 2009-03-15T04-27-00.000Z

Рекс, сначала несколько вопросов:

Это приложение 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 МБ или более), но механизм запросов представляет собой пару пользовательских Hashtables (ref), которые очень быстрые.

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

Индексированный Linq должен позволять вам указывать индексы в вашей коллекции объектов, чтобы ускорить выполнение определенных запросов. Это незавершенное производство, но может быть полезно для ваших нужд.
Сайт ComponentOne LiveLinq говорит: "LiveLinq использует индексирование и другие оптимизации для ускорения запросов LINQ в памяти". Это похоже на Indexed Linq, но будет коммерческим продуктом.

НТН