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

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

2 голосов
/ 14 марта 2009

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

Edit: Вот больше информации о приложении.

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

Ответы [ 2 ]

4 голосов
/ 15 марта 2009

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

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

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

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

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

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

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

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

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

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

НТН

1 голос
/ 14 марта 2009

Существует множество ресурсов, которые показывают, как выполнить LINQ to POCO (простые старые объекты CLR). Вот только несколько, чтобы вы начали ...

Обзор MSDN

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

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

...