Я работаю над переписыванием веб-сайта, который должен извлекать данные своих пользовательских данных из сторонней системы, доступ к которой осуществляется через удаленные объекты.В интересах стандартизации я реализовал пользовательский MembershipProvider для аутентификации и собственный RoleProvider для авторизации, но сейчас я размышляю над лучшим способом работы с данными профиля.Большинство советов, которые я видел, говорят о том, чтобы использовать модель ProfileProvider для работы с данными профиля, если это вообще возможно, но ее дизайн на самом деле не вписывается в систему, с которой мне приходится взаимодействовать.
Самый большойКамнем преткновения является настойчивость ProfileProvider в том, что Profile - это пакет объектов, над которым работает как единое целое.Это может подойти для поставщика на основе SQL, но вызов удаленных объектов - очень дорогая операция.Если я сделаю вызов Profile.FirstName, GetPropertyValues выглядит так, как будто ему отправлена коллекция SettingsPropertyCollection, содержащая каждый объект, определенный в профиле.Для этого веб-сайта, который будет включать в себя несколько наборов адресной информации, информации о заказе, информации о посещаемости и прочее.Извлечение всей этой информации сразу губительно для производительности.Похоже, что целевое сохранение может быть сделано с помощью флага IsDirty на каждом объекте SettingsPropertyValue, но только если это примитивный тип ... которого большинство свойств не имеют.
Я правильно понимаю?Если все, что предоставляет ProfileProvider - «Вернуть этот профиль» или «Сохранить этот профиль», то отложенная загрузка кажется невозможной, а снижение производительности слишком велико.Если я откажусь от модели профиля, каков хороший альтернативный метод для работы со всеми данными профиля?Должен ли я просто запустить свой собственный механизм с поддержкой сессий?