Есть довольно много решений для этого.
- Пусть ваши прокси-классы службы реализуют ваш собственный интерфейс для предоставления методов, а затем просто используют отражение для создания типа.
- Оберните обе службы в другой класс, который предоставляет методы и имеет ссылку на обе службы, а затем просто укажите аргумент переключения, чтобы определить, какие из них использовать.
- Аннотацияиспользовать службу через собственный интерфейс и иметь классы, явно закодированные для каждой службы (см. ниже).
Или, если вы хотите поиграть с динамической и утиной печатью, это, похоже, сработает:
namespace ConsoleApplication42
{
class Program
{
static void Main(string[] args)
{
Type t1 = Type.GetType("ProviderOne.AuthService");
dynamic service = Activator.CreateInstance(t1);
Console.WriteLine(service.GetUsername());
Type t2 = Type.GetType("ProviderTwo.AuthService");
service = Activator.CreateInstance(t2);
Console.WriteLine(service.GetUsername());
Console.Read();
}
}
}
namespace ProviderOne
{
public class AuthService
{
public string GetUsername()
{
return "Adam";
}
}
}
namespace ProviderTwo
{
public class AuthService
{
public string GetUsername()
{
return "Houldsworth";
}
}
}
Имейте в виду, что все они зависят от обеих служб, имеющих одинаковую подпись.
Что касается других служб в будущем, то это действительно зависит.Я никогда не сталкивался с необходимостью динамического переключения с одного сервиса на другой, чтобы получить немного другое поведение при достижении одного и того же.
Возможно, это должно быть направлено со стороны вашего приложения?Вместо того, чтобы выбрать службу, подходящую для этого, просто реализуйте две версии класса с таким изменяющимся поведением - установите общий интерфейс для него и решите, какой из ваших классов использовать вво время выполнения.Затем сам класс будет закодирован непосредственно против одного сервисов.
interface IGetUsername
{
string GetUsername();
}
class UsernameViaProviderOne : IGetUsername
{
public string GetUsername()
{
return new ProviderOne.AuthService().GetUsername();
}
}
class UsernameViaProviderTwo : IGetUsername
{
public string GetUsername()
{
return new ProviderTwo.AuthService().GetUsername();
}
}
Тогда решение полностью закреплено в вашем клиентском коде и устраняет необходимость в рефлексии / динамической типизации:
IGetUsername usernameProvider = null;
if (UseProviderOne)
usernameProvider = new UsernameViaProviderOne();
...
Чтобы разобраться в этом вопросе, вы всегда можете получить SOA и создать еще один сервис, с которым ваше приложение взаимодействует, объединяющий два других сервиса.Тогда, по крайней мере, ваш клиентский код не видит огромное количество различных сервисов и общается только с одним.