Предложения по реализации простого поиска «бизнес-объектов» в приложении .NET WinForms?

Question

Как лучше всего обеспечить простую возможность поиска «бизнес-объектов» в приложении .NET WinForms?

Под «простым поиском» я подразумеваю что-то вроде «окна поиска» в Vista + Windows 7, которое находится в верхнем правом углу почти каждого окна, которое ищет содержимое этого окна (ничего особенного, вероятно, нет «продвинутого»). ищите либо - будьте проще).

Под «бизнес-объектами» я подразумеваю объекты, основанные на классах, для таких вещей, как «клиенты» и «адреса» (в основном это просто ваши обычные контактные данные).

Я подумал о том, чтобы «свернуть свой собственный» простой поиск, возможно, когда мои классы реализуют функцию «Содержит», чтобы я мог спросить каждый объект, «содержит» ли он какие-либо поисковые термины пользователя (и затем создать какой-то вид простого ранга в зависимости от того, сколько слов было найдено).

Я также изучил Lucene.NET, но он кажется слишком сложным для моих потребностей - необходимость создания индекса (а также его обновления и обслуживания).

Предложения? Идеи?

Answer 1

Я не знаю о «лучшем» способе (я бы поработал в Google, если бы сделал). Однако, учитывая это, я несколько месяцев назад реализовал нечто подобное в демонстрационном тесте концепции / клиента, что и помогло. Обратите внимание, что мне удалось довольно эффективно ограничить проблемную область, особенно в том, что касается размера немедленно доступного для поиска набора данных, чтобы производительность не была проблемой.

Я создал FilterableListView UserControl. Я использовал ListView в режиме детализации, я бросил TextBox непосредственно над ним и использовал взаимодействие с платформой, чтобы придать ему CueText (что-то вроде " Фильтр »или« Поиск »). Затем я обновил содержимое ListView из фонового потока (используя эквивалент моей реализации SafeInvoke), если с момента последнего TextChanged* 1021 произошла задержка в 0,5 секунды * событие из поля фильтра.

Я сделал простое, нечувствительное к регистру совпадение подстроки с содержимым указанного поля в ListView, это было быстро, просто и эффективно. Я считаю, что Linq to Objects очень полезен.

Несколько вещей, которые я бы сделал лучше для более производительной реализации:

1. Используйте скорость двойного щелчка, чтобы рассчитать соответствующую задержку перед выполнением поиска.
2. Предоставить механизм обратного вызова для выполнения поиска вместо его включения в элемент управления. Возможно, что-то вроде IFilterable интерфейса?

Answer 2

Пока у вас не слишком много объектов, имеет смысл делать то, что вы описываете, просто просматривая каждый объект. Вы можете использовать регулярное выражение вместо Contains, чтобы придать ему немного большей гибкости. Contains собирается дать вам соответствие объекту, а не просто строковое значение свойства внутри вашего объекта. Соответствие строки, вероятно, будет более полезным для вас.

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

Answer 3

Я думаю, что ваш подход использования метода «Содержит» в каждом объекте весьма полезен.

Вы можете присвоить " weight " членам объекта, чтобы, если метод содержимого обнаружил совпадение, в качестве возврата было указано " Score ".

Другая вещь, которую нужно учитывать, это то, является ли совпадение полным совпадением или нет ... и присваивает более или менее очко этому баллу.

Если вы выполняете поиск по нескольким типам объектов ... возможно, вы можете назначить более высокие значения основным объектам (больше бизнес-ориентированных объектов), чтобы придать им больший приоритет.

Просто мысли ...

Answer 4

Я бы реализовал простой интерфейс для каждого класса, который просто возвращает список поисковых терминов, описывающих экземпляр. Затем вы сможете получить все свои объекты, запросить у них условия поиска и ранжировать их на основе предоставленных пользователем условий поиска.

Это близко к вашей идее интерфейса Contains, но не допускает большей логики в бизнес-классах. Вы даже можете исследовать объекты с помощью отражения и просто добавить некоторые пользовательские атрибуты в свойства, чтобы дать поисковой системе некоторые подсказки, какие свойства включить в поиск.

Но помните, что вам придется оценивать каждый поиск по всем вашим объектам. Это станет очень медленным за пределами примерно сотни объектов, если вы используете сложную функцию ранжирования. Использование отражения сделает вещи еще хуже.

Еще одна проблема, которую нужно решить, - это как правильно обрабатывать результаты поиска. Если у вас довольно много разных классов, это может быть нетривиальной задачей для отображения результатов и перемещения пользователя к месту в приложении, где он может что-то делать с этими объектами.