Мы разрабатываем новое приложение, используя следующий стек:
SQL Server 2008 R2 -> Entity Framework 4.2 -> Службы данных WCF -> Клиентская библиотека служб данных WCF
Этоэто все .NET 4.0
Теперь клиентская библиотека WCF Data Services очень удобна для небольших фрагментов данных и простых схем / графов объектов, но это настоящая собака для более сложных моделей.В частности, мы обнаружили, что коллекция DataServiceContext.Links масштабирует что-то вроде O (n ^ 2): чем больше связанных объектов вы загружаете, и чем больше вложенный ваш график, тем медленнее он становится, пока не потребуется больше времени для загрузки данныхв контекст, чем он читает его по проводам.
Например, у нас есть коллекция с 2000 членами, и каждый член имеет 4 свойства навигации.Извлечение всей коллекции без расширения каких-либо навигационных свойств занимает около 1 секунды.Расширение всех 4 навигационных свойств занимает 5 секунд.Мы измерили производительность в различных точках стека, и большую часть дополнительного времени тратится на клиент, сопоставляя данные.
Мы приняли различные методы, чтобы обойти это для больших наборов данных:
- Денормализация.Это хорошо работает для тех графиков, которые мы всегда расширяем.Не очень хорошо работает, если мы хотим отложить загрузку части графика.
- Загрузка связанных объектов по отдельности и соединение их вне контекста данных.Это просто раздражает, но оно преодолевает проблему context.Links.
- Использование нескольких контекстов данных для поддержания минимального давления на коллекцию ссылок.
- Использование MergeOption.NoTracking в соединении с /(1) и (2)
Кто-нибудь знает какие-либо другие методы?Есть ли где-то параметр, который может вызывать ненужные накладные расходы при загрузке связанных объектов?
Иногда кажется, что мы находимся на полпути к написанию нашего собственного контекста, и я хотел бы проверить работоспособность, прежде чем он станет более сложным.
[Да, я понимаю, чтоСлужбы данных WCF могут быть неподходящим инструментом для работы.Увы, мы уже идем по этому пути]