Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, <Аноним>, Вы писали:

А>>Ну раз непонимание, то, объясните мне, плиз, ИСТИННОЕ назначение этих штук с учетом комментариев выше!!!

G>Я так и не понял суть претензий к MasterPages из того что написано. Вопрос в том почему MasterPage не UserControl? Если я понял неправильно, объясните пожалуйста, желательно без обилия восклицательных знаков. Лучше всего по пунктам, мне так будет легче понять.

Да, все верно — почему мастер пейдж — свойство страницы — можно сделать контрол — и мастер контрол соответственно!!!
таким образом мы не привязаны к странице, и допустима ситуация вложения мастер пейдж контролов. Мне кажется этот подход правильнее — просто компонента, а не часть объектной модели АСП НЭТ.

G>Membership нужен для того, чтобы безболезненно менять реализацию безопасноcти абстрагированно от самого приложения. Поясню примером — форум, работающий на Membership легко интегрируется в любой сайт, уже использующий данную инфраструктуру. Разработчику форума не нужно знать, как устроена безопасность у того, кто будет его использовать. То же относится к контролам, так или иначе работающим с безопасностью.

Ну, сдесь вся выдумка — абстрагировать реализацию мембершипа — а собственно, нечего абстрагировать. Нужен интерфейс мембершипа и его провайдер . Тоесть свести 2 функциональности — просто пользоваться провайдером. Далее — интерфейс мембершипа совсем не сложный — аутентифицировать, взять роли, и узнать, аутентифицирован ли — последние 2 — принципал. Так сложно отделить самому, ведь получаем полную свободу действий, в отличие от использования существ. архитектуры, и что еще хуже — базы данных. Какие при этом напрашиваются сложности с деплойментом. Конфигурировать чей-то компонент, задавая даже ему ГУИ часть — неблагодарное дело.
Вывод о легкой интеграции — только из-за того, что мембершип есть в стандартных библиотеках