Я разрабатываю сервис-ориентированную архитектуру для приложения, и я хотел бы, чтобы сервисы были доступны как через WCF, так и для использования через простую библиотеку.В идеале я хотел бы уменьшить дублирующийся код.
Концептуально это соответствует:
Клиент => Служба WCF => Библиотека служб (фактическая реализация)
или
Клиент => Сервисная библиотека (фактическая реализация)
в зависимости от того, где находится клиент (локальный или удаленный).
Вот простой пример:
[ServiceContract]
public interface ICalculator
{
[OperationContract]
int Add(int a, int b);
}
public class Calculator : ICalculator
{
public int Add(int a, int b)
{
return a + b;
}
}
public class CalculatorFactory
{
public static ICalculator CreateCalculator()
{
return new Calculator();
}
}
И мое клиентское приложение сделало следующее
int result = CalculatorFactory.CreateCalculator().Add(1,2);
или
int result = IChannelFactory<ICalculator>().CreateChannel().Add(1,2);
в зависимости от того, было ли оно локальным или удаленным.
Это плохая практика для вызоваКод, аннотированный WCF напрямую (т. Е. Без использования WCF)?
Дополнительные комментарии:
- Я понимаю, что мог бы использовать WCF во всех случаях и просто разместить службу, используя NamedPipes для локальных соединений,Я хотел бы избежать этого, если я могу для простоты.
- Альтернативой вышеупомянутому является существенное дублирование интерфейса ICalculator в библиотеке служб и изменение реализации службы WCF, чтобы она содержала CalculatorFactory.CreateCalculator (). Add(1,2).Это похоже на большие издержки, учитывая, что я хочу, чтобы интерфейс был таким же.