Контракт на обслуживание реализует другой интерфейс - PullRequest
1 голос
/ 05 февраля 2011

Пожалуйста, скажите мне, если это возможно.У меня есть клиентское приложение win form и приложение wcf на C #.Это моя модель.

Общий проект

public interface IServiceA
{
     string DoWorkA();
}

Я не использую атрибуты ServiceContract или OperationContract здесь, в общем проекте.

Теперь ClientProject ссылается на общий проект.ServiceProject также ссылается на Общий проект.

В ServiceProject я использую Договор на обслуживание, как показано ниже:

[ServiceContract]
public interface IGetData : IServiceA
{
   // Implements IServiceA method
   [OperationContract]
   string DoWorkA();
}


public class MyService : IGetData
{
    string DoWorkA()
     {

     }
}

На стороне клиента

public class MyClass : IServiceA
{
    // Implements the IServiceA method
    string DoWorkA()
     {
        // Inside this I will call the MyService using DuplexChannel proxy
     }
}

[Пожалуйста,предположим, что в этой модели реализован контракт обратного вызова]

Почему я задал этот вопрос, так это то, что в моем приложении много модулей, каждый из которых должен получать данные из сервиса своим собственным методом.Поэтому я планирую использовать фасад как образец.Скажите пожалуйста, правильно это или нет ????

Ответы [ 2 ]

2 голосов
/ 05 февраля 2011

Ваш код, как написано, генерирует предупреждение, потому что метод IGetData DoWork() скрывает метод IServiceA DoWork.

Чтобы избавиться от предупреждения, нужно добавить новое ключевое слово:

[ServiceContract]
public interface IGetData : IServiceA
{
   // Implements IServiceA method
   [OperationContract]
   new string DoWorkA();
}

Но я думаю, что вы хотите объединить меньшие интерфейсы в один более крупный сервис. Тогда ваши модули могут взаимодействовать с их понятным интерфейсом (который является подмножеством интерфейса службы).

Например:

public interface IWarehouse : IShipping, IReceiving, IInventory, IMovement {}

Мы реализовали нечто подобное.

  • Мы определили все наши сервисные контракты в общей сборке и использовали интерфейсы как на клиенте, так и на сервере.
  • Мы создали клиентские прокси, которые реализовали эти интерфейсы.

После этого клиенты могут взаимодействовать с клиентскими прокси с более простым подмножеством всего интерфейса службы.

Сначала определите интерфейсы:

[ServiceContract]
public interface IServiceA
{
    [OperationContract]
    string DoWorkA(); 
}

[ServiceContract]
public interface IServiceB
{
    [OperationContract]
    string DoWorkB();
}

[ServiceContract]
public interface IGetData : IServiceA, IServiceB
{
}

Затем создайте прокси (вы также можете использовать ChannelFactory здесь):

public class ServiceClientA : ClientBase<IGetData>, IServiceA
{
    public string DoWorkA()
    {
        return Channel.DoWorkA();
    }
}

public class ServiceClientB : ClientBase<IGetData>, IServiceB
{
    public string DoWorkB()
    {
        return Channel.DoWorkB();
    }
}

Вышеуказанное было бы аналогично вашему MyClass.

Тогда клиент может использовать индивидуальный интерфейс:

IServiceA clientA = new ServiceClientA();
string result = clientA.DoWorkA();

IServiceB clientB = new ServiceClientB();
result = clientB.DoWorkB();

Вы также можете создать сервисную фабрику здесь, если хотите.

Надеюсь, это даст вам некоторые идеи.

0 голосов
/ 05 февраля 2011

Пара баллов:

  • Вашему клиенту не нужно внедрять IServiceA. Это почему? Ваш клиент может использовать эту службу, просто имея ссылку на вашу службу WCF.
  • Ваш интерфейс IServiceA кажется избыточным в данном сценарии. Это не приносит никакой пользы. ИМО вы можете жить IGetData. Здесь вы реализуете сервисный контракт. При желании вы можете переименовать этот интерфейс в IServiceA.

Чтобы ответить на вопрос, где у вас много модулей, которым необходимо получать данные от службы, можете ли вы классифицировать эти модули по характеру бизнеса / функции? Если да, то вы можете создать разные службы WCF для каждой из этих бизнес / функций, и соответствующие модули будут вызывать соответствующие службы. В дополнение к этому я не вижу смысла, почему одному модулю нельзя разрешать собирать данные из более чем одного сервиса. Это вполне приемлемый сценарий.

НТН

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...