Проект договора на обслуживание (подпись операции)

Question

Я разрабатываю некоторые сервисы и хотел бы получить отзывы об используемых мной соглашениях.

Для всех операций я всегда определяю объект «Контекст» и объект «Результат»,из-за следующих преимуществ:

• расширяемость: я могу добавлять параметры в контекст или объекты к результату без изменения интерфейса
• компактность: у меня только один объект в определениидаже если мне нужно много параметров

Пример:

[OperationContract]    
DoSomethingResult DoSomething(DoSomethingContext context)

В любом случае, я не совсем уверен, что это лучший способ сделать это по следующим причинам:

• накладные расходы: я всегда заключаю свойства ответа в объект.Иногда объект Result не имеет свойств
• управления версиями: в WCF встроено управление версиями для контрактов, и, возможно, было бы лучше использовать другую версию, чтобы сообщить о разнице

На самом деле я использую ту же технику и с обычными методами, поэтому для меня было бы важно получить отзывы, советы, критику и т. Д. И т. Д.

Спасибо

Answer 1

Я думаю, что это совершенно законный способ написания ваших контрактов. Я работал над несколькими проектами с такими контрактами, и это было приятно - очень легко во время разработки (просто добавьте свойство к объекту, и все готово), простой и понятный шаблон, который применим ко всем услуги и допускает такие вещи, как единый метод проверки для всех операций.

В ответ на ваши опасения:

• Я не думаю, что затраты на создание пустого объекта вообще значительны. Не беспокойтесь об этом, пока это не станет проблемой.
• Если у объекта Result нет свойств (т.е. вы ничего не возвращаете), просто верните void. Вы ничего не получаете, возвращая пустой объект.
• Вы можете (и, вероятно, должны) создавать версии этих объектов по мере создания версий ваших контрактов. То, что вы делаете, никоим образом не мешает вам создавать версии ваших объектов.

Обратите внимание, что управление версиями объектов не означает их изменение на DoSomethingResult_v1, DoSomethingResult_v2, как я видел ранее. Вы должны версия с пространствами имен; это делает вещи яснее и чище. Просто поместите версию в пространства имен XML как в контракте операции, так и в атрибутах члена данных.

Answer 2

Я не думаю, что здесь есть какие-либо проблемы с производительностью, и код выглядит легко для работы с точки зрения владельцев кода.

Моя большая проблема в том, что с точки зрения потребителей не совсем ясно, как работает ваша услуга. Им придется полагаться на отдельную документацию или сообщения об ошибках.

Для кого-то, кто не знаком с вашим кодом (т. Е. Только что загрузил WSDL), было бы намного проще использовать ваш сервис, если бы требуемые параметры были объявлены. Вы также получаете хорошую степень проверки из коробки.

Для иллюстрации:

[OperationContract]     
DoSomethingResult DoSomething(DoSomethingContext context) 

против

[OperationContract]   
[FaultContract(typeof(CustomerNotFoundFault))]   
Customer GetCustomer(UInt32 customerId) 

Этот пункт в основном относится к разработке API. Там, где это не так важно, вы являетесь как автором, так и потребителем услуги.

Я полностью поддерживаю предложение Кирка Бродхерста об использовании пространств имен для управления версиями. Я использую это, и это хорошо работает.

РЕДАКТИРОВАТЬ: во втором чтении, я думаю, что я неправильно прочитал ваш пост. Я предполагал, что ваши объекты параметров и возвращаемых значений являются неким общим объектом, который вы используете во всех сервисах. Если они действительно специфичны для каждого сервиса, то это отличный подход, который я успешно использовал во многих случаях. Вы преуспеете с этим.