Я делал очень сложные штуки, но в целом всё обычно сводится к одному-двум паттернам, которые легко реализуются через IoC.
В любом случае, требеования на входе в том же Autofac можно легко описать как часть процесса регистрации.
Для невизуальных библиотек, которые не являются частью большего проекта, DI framework (в отличии от самого принципа IoC) обычно не используют. Если библиотека является частью большего проекта с визуальной частью, можно включить в неё модуль регистрации, но контейнер ей не нужен, потому что все ссылки распознаются исключительно через конструкторы.
Если в коде встречается явное использование Resolve, то это неправильный пример применения контейнеров. Последний абзац похож на описание правильного подхода, но без конкретных примеров сложно оценить.
Ну да, не good, но Facebook довольно по конкретной (технической) причине отказался от OpenID.
С другой стороны, каждый раз это реализовывать не нужно, достаточно одной библиотеки.
Что касается дупликации — неудобно, да, но разве два OpenID провайдера тут будут лучше?
Точно такая же дупликация.
Ну как бы email это гораздо больше «спалили», нет? Спам там и всё такое.
То есть если доверяете какому-то месту настолько, чтобы оставить там email, в принципе фото (которое в контакте можно найти по имени) не должно быть проблемой.
Email по API получить нельзя, но я говорю об обратной ситуации — получить ограниченную информацию по email.
Кстати, вот одна идея для API (которую Facebook пока не предоставляет): по MD5 email выдавать фотографию (если профиль открытый).
Как некоторый аналог gravatar.
Я недавно писал приложение для управления списком внешних людей (предположим, кандидатов на должность X).
Возможность автоматически подгрузить их фотографии по адресам электоронной почты была бы очень кстати.
Это красиво звучит, но у меня и в обычном HTML+JS есть контролируемый трафик данных, прозрачный deployment, нормальные отладчики (в той же студии, например) и поддержка таких маргинальных систем, как iPad и iPhone.
Статических языков нет, это да. Производительность может быть средней, поэтому для игр и rich media Silverlight лучше.
Плюс SL в последней версии поддерживает OOB, но это не пример конкуренции с web приложениями.
Я больше верю в вещи вроде chi.mp.
Или LinkedIn.
Или хотя бы webfinger.
В любом случае, требеования на входе в том же Autofac можно легко описать как часть процесса регистрации.
Не видел, чтобы владельцев Google или Facebook так где-нибудь называли.
Я надеюсь, с учётом прав доступа?
Пару раз спам приходил, но и всё. Даже с твиттера было больше спама.
Нравится — регистрируешься, не нравится — не регистрируешься.
Непонятно почему люди так это всё принимают близко к сердцу.
Клон FB, конечно, но хоть не такой хлам как mail.ru или Одноклассники.
Если это нужно/интересно, можно зарегистрироваться.
Но, кстати, на вопрос дупликации кнопок это ровным счётом никак не влияет.
С другой стороны, каждый раз это реализовывать не нужно, достаточно одной библиотеки.
Что касается дупликации — неудобно, да, но разве два OpenID провайдера тут будут лучше?
Точно такая же дупликация.
(подсказываю: не OpenID)
То есть если доверяете какому-то месту настолько, чтобы оставить там email, в принципе фото (которое в контакте можно найти по имени) не должно быть проблемой.
Email по API получить нельзя, но я говорю об обратной ситуации — получить ограниченную информацию по email.
Как некоторый аналог gravatar.
Я недавно писал приложение для управления списком внешних людей (предположим, кандидатов на должность X).
Возможность автоматически подгрузить их фотографии по адресам электоронной почты была бы очень кстати.
Статических языков нет, это да. Производительность может быть средней, поэтому для игр и rich media Silverlight лучше.
Плюс SL в последней версии поддерживает OOB, но это не пример конкуренции с web приложениями.