Я кеширую целую кучу статических метаданных в моем приложении при запуске.Это из БД, и есть тонны отношений внешнего ключа.Я ищу лучший способ их моделирования.Я только начал с LINQ.
Мне легко объявить класс
public class AllData {
public static IQueryable<libm_ColPurpose> IQ_libm_ColPurpose = libm_ColPurpose.All();
public static IQueryable<libm_ColType> IQ_libm_ColType = libm_ColType.All();
...
(я использую SubSonic 3 для генерации своих классов, но это не относится к делу),Затем я могу использовать члены IQueryable <T>, чтобы получить доступ ко всему, что я хочу, например:
libm_ColType ct = AllData.IQ_libm_ColType.SingleOrDefault(x => x.ColTypeStr == this.DefaultJetColTypeStr);
До использования IQueryable я использовал словари для хранения связей FK, чтобы имитировать приведенный выше кодЯ набрал бы следующий код из существующего списка List <libm_ColType> list
Dictionary<string, libm_ColType> colTypeByColTypeStr = new Dictionary<string, libm_ColType>();
foreach (libm_ColType x in list) { rtn.Add(x.ColTypeStr, x); }
, и тогда я мог бы использовать
libm_ColType ct = colTypeByColTypeStr[this.DefaultJetColTypeStr];
OK, так что, наконец, мы перейдем к вопросу!
Поиск в словаре по идентификатору чрезвычайно эффективен, однако решение IQueryable гораздо более гибкое и элегантное.
Мне интересно, какой удар по производительности я получу, используя IQueryable.Я подозреваю, что я делаю линейное сканирование списка каждый раз, когда я вызываю его, и это действительно будет складываться из-за повторных вызовов, если задействовано много записей.Было бы здорово, если бы я мог определить уникальные столбцы и создать хеш-таблицу, сгенерированную и кэшированную после первого поиска, но я подозреваю, что это не будет частью предложения.
Это немного нарушает правиладля меня относительно использования LINQ.
Обратите внимание (я повторю это снова), что я НЕ извлекаю данные из базы данных, они уже находятся в памяти, и я запрашиваю их там, так что мне интереснопри поиске в памяти IQueryable <T>.