Привет,
Во время портирования нашего приложения столкнулись с тем, что у наших сервисов достаточно много обобщённых методов.
Скажите, имет ли смысл играться с IOperationInvoker, IDispatchMessageFormatter и почими экстеншенами WCF'а что бы добавить поддержку вызова обобщённых методов?
Здравствуйте, Norex, Вы писали:
N>Привет, N>Во время портирования нашего приложения столкнулись с тем, что у наших сервисов достаточно много обобщённых методов.
хм, а как вы себе представляете некую "обобщенную" службу отвечающую за непонятно что? сдается мне, что у вас службы выполняют мелкозернистую работу, в том время как их контракт должен быть достаточно высокоуровневый полностью покрывающий некую задачу
Здравствуйте, Аноним, Вы писали:
А>хм, а как вы себе представляете некую "обобщенную" службу отвечающую за непонятно что? сдается мне, что у вас службы выполняют мелкозернистую работу, в том время как их контракт должен быть достаточно высокоуровневый полностью покрывающий некую задачу
Простите, но суть вопроса была можно ли обучить WCF выполнять обобшённые методы или нет.
А контракт нам достался по наследству — мы его не дизайнили и менять его нельзя.
В этом мире разработчики не всегда могут делать то, что им бы хотелсь — есть риски, риски, риски и ещё раз риски — любимые слова продактов.
Здравствуйте, Norex, Вы писали:
N>Простите, но суть вопроса была можно ли обучить WCF выполнять обобшённые методы или нет. N>А контракт нам достался по наследству — мы его не дизайнили и менять его нельзя. N>В этом мире разработчики не всегда могут делать то, что им бы хотелсь — есть риски, риски, риски и ещё раз риски — любимые слова продактов.
Обобщенные методы, как и обобщенные типы в контракте сервиса нарушают принципы SOA (Service-Oriented Architecture), поскольку обобщения относятся к специфике платформы .NET, а кто сказал, что на платформе вашего клиента вообще такое понятие как обобщения будут существовать?
В интерфейсе сервисов можно использовать только bounded generic types (т.е. MyClass<int>, MyClass<MyClass2>), но нельзя использовать просто открытые обобщенные типы MyClass<T>.
Контракт WCF-сервиса публикуется с помощью WSDL, который не то что обобщения, он даже перегрузку методов не поддерживает, поэтому даже с помощью каких-то хаков прикруть обобщения к контрактам WCF вряд ли удастся (а если и удастся, то это уже будет очень слабо напоминать WCF).
Здравствуйте, SergeyT., Вы писали: ST>Обобщенные методы, как и обобщенные типы в контракте сервиса нарушают принципы SOA (Service-Oriented Architecture), поскольку обобщения относятся к специфике платформы .NET, а кто сказал, что на платформе вашего клиента вообще такое понятие как обобщения будут существовать?
Точно будут.
Т.к. у меня один только один вид клиента и полностью в нашем ведении.
ST>В интерфейсе сервисов можно использовать только bounded generic types (т.е. MyClass<int>, MyClass<MyClass2>), но нельзя использовать просто открытые обобщенные типы MyClass<T>.
Это мы знаем, спасибо XsdDataContractExplorer'у Ж)
ST>Контракт WCF-сервиса публикуется с помощью WSDL, который не то что обобщения, он даже перегрузку методов не поддерживает, поэтому даже с помощью каких-то хаков прикруть обобщения к контрактам WCF вряд ли удастся (а если и удастся, то это уже будет очень слабо напоминать WCF).
Мне не нужно публиковать это ни куда.
А подправить Message.Headers.Action — я могу.
Вообщем, ваша мысль сводиться к тому, что обойти это ограничение вряд ли удасться?
Здравствуйте, Norex, Вы писали:
ST>>Обобщенные методы, как и обобщенные типы в контракте сервиса нарушают принципы SOA (Service-Oriented Architecture), поскольку обобщения относятся к специфике платформы .NET, а кто сказал, что на платформе вашего клиента вообще такое понятие как обобщения будут существовать?
N>Точно будут. N>Т.к. у меня один только один вид клиента и полностью в нашем ведении.
Но WCF — это не .net remoting, в его основу заложены несколько иные принципы
N>Вообщем, ваша мысль сводиться к тому, что обойти это ограничение вряд ли удасться?
Есть вариант, как "обойти" проблему обобщений — отказаться от них: вместо generic-ов использовать object-ы и использовать NetDataContractSerializer вместо DataContractSerializer (это тоже нарушение принципов SOA, поскольку NetDataContractSerializer сохраняет информацию о типе, но это весьма просто сделать штатными средствами, см. здесь
). Вот это точно работать будет. Ну, а поверх созданных таким образом сервисов/проксей можно прикрутить интерфейс, максимально схожий с вашим исходным интерфейсом (сделать такой себе адаптер), но который уже не будет являться частью интерфейса сервиса, а будет лишь оболочкой над ним.
А вот о возможности полноценной прикрутки обобщений в интерфейс сервиса — я никогда не слышал, поэтому и сомневаюсь в такой возможности.
