Поставщики аутентификации, шаблон проектирования для принятия

У меня клиент windows phone 8.1. Этот клиент подключается к веб-API (ASP.NET) и выбирает поддерживаемых поставщиков аутентификации. На данный момент это Google и Twitter. Пользователь (wp 8.1) может выбрать, какого провайдера он хочет использовать для аутентификации.

В зависимости от поставщика, выбранного на телефоне, базовый поток реализации для аутентификации отличается, другими словами, у Google есть один поток, а у Twitter — другой поток. Из-за этого у меня есть операторы переключения в моем клиенте, которые выглядят следующим образом

switch(authProvider)
case: "Google":
  GoogleAuthProvider.PerfomAuthentication();
  break;
case: "Twitter"
  TwitterAuthProvider.PerformAuthentication();
  break;

Моя главная проблема в том, что я сейчас жестко кодирую провайдера. Остальная часть моего телефонного приложения использует IOC (MVVMLight), и в этом случае я жестко кодирую. Как мне избавиться от этого, не обращаясь явно к контейнеру? Плюс скажем, в более поздний момент времени будет поддерживаться дополнительный поставщик аутентификации, а затем, исходя из текущей реализации, мне также нужно изменить клиентский код, как мне минимизировать это?


authentication design-patterns win-universal-app
person user3547774    schedule 21.08.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

В приведенном вами примере шаблон State GoF будет соответствовать задаче, предполагающей, что интерфейс аутентификации является унифицированным (состоит из одного метода — PerformAuthentication и, возможно, из других методов, которые являются общими для всех других возможных поставщиков). Так что вам нужно создать интерфейс IAuthenticationProvider и внедрить его реализацию в логику, которая фактически выполняется (логика, которая ранее содержала switch).

На самом деле это очень похоже на стратегию, которая внедряется через DI, но стратегия просто инкапсулирует алгоритм, в котором состояние является более мощным и подходящим для домена аутентификации (у него может быть … состояние и другие методы/свойства — не так уж плохо, верно? :)

Если вы сталкиваетесь с провайдерами с разными функциональными возможностями и интерфейсами, вы можете выбрать шаблон моста, который объединяет разнородные интерфейсы аутентификации под эгидой единого интерфейса. Но мне кажется, что использование Bridge здесь было бы перебором.

person xenn_33    schedule 01.09.2014