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

А>Да, все верно — почему мастер пейдж — свойство страницы — можно сделать контрол — и мастер контрол соответственно!!!
Я не понимаю это предложение.

А>таким образом мы не привязаны к странице,
А к чему надо привязываться? Контролы-то уже есть.

А> и допустима ситуация вложения мастер пейдж контролов.
А их и так можно вкладывать.

А>Мне кажется этот подход правильнее — просто компонента,
Так делайте User Control, кто мешает?

А> а не часть объектной модели АСП НЭТ.
МasterPage наследуется от UserControl. Это просто большой контрол, сделанный для удобства разработчика. Стандартная реализация. Вас не раздражает что есть контрол asp:Button?

А>Ну, сдесь вся выдумка — абстрагировать реализацию мембершипа — а собственно, нечего абстрагировать.
Есть чего.

А>Нужен интерфейс мембершипа и его провайдер . Тоесть свести 2 функциональности — просто пользоваться провайдером. Далее — интерфейс мембершипа совсем не сложный — аутентифицировать, взять роли, и узнать, аутентифицирован ли — последние 2 — принципал.
Так и сделали.

А> Так сложно отделить самому, ведь получаем полную свободу действий, в отличие от использования существ. архитектуры, и что еще хуже — базы данных.
Мембершип не привязан к БД. Именно потому что сделан через провайдеры. к БД привязана конкретная реализация — SqlMembershipProvider

А>Какие при этом напрашиваются сложности с деплойментом. Конфигурировать чей-то компонент, задавая даже ему ГУИ часть — неблагодарное дело.
Не понял. Какое ГУИ? Какой чей-то компонент, какой деплоймент? Мне трудно читать несвязанные утверждения через тире.

А>Вывод о легкой интеграции — только из-за того, что мембершип есть в стандартных библиотеках
Не _только_ из-за того, а _именно_ из-за этого.

З.Ы. Пока я не вижу ничего плохого ни в Membership ни в MasterPages.