WCF и Интерфейсное Наследование - действительно ли это - ужасная вещь сделать?
В git flow вы объединяете только тег с основной веткой с номерами релизов. Ваша ветка разработки не знает, какая версия выпущена в данный момент.
Идея Git Flow заключается в том, что ваши разработчики могут работать над своей веткой функций независимо от того, выпустит ли их функция. Только оперативные исправления создают версии немедленного выпуска.
Вот пример потока Git с использованием Gitflow
3 ответа
Я обычно говорил бы, нет. Помните, Вы имеете дело с технологией распределенного приложения, не распределенной объектной технологией, таким образом, понятия как наследование не применяются.
В целом я не спустился бы по этому пути, а скорее, имел бы определенные контракты, которые представляют логическую группировку операций, которые Вы хотите выставить через конечную точку.
Я полагаю, что то, что Вы описываете, не является действительно лучшей практикой все же. Несомненно, выполнимо реализовать больше чем один контракт на Обслуживание на Сервисном типе, так как это - просто вопрос реализации нескольких интерфейсов.
WCF, конечно, делает выполнимым поддерживать несколько конечных точек, которые передают использующий уникальный URIs и независимые контракты. Однако то, что класс ClientBase только принимает один тип интерфейса контракта, например, в значительной степени подразумевает, что прокси-классы, даже если они хранятся в том же lib, все еще должны отчетливо реализовать только один интерфейс контракта.
Если Вы на самом деле успешны в создании только одного определения прокси-класса, я хотел бы знать, как Вам удалось выполнить это. Я могу неправильно понимать Ваши потребности все же. Реализация различных прокси-классов дает Вам окончательную гибкость, потому что значения OperationContractAtrribute как IsInitiating и IsTerminating будут, вероятно, отличаться для различных контрактов. Объединение интерфейсов двух контрактов, как в Вашем примере, потенциально изменяет способ, которым Вы приписали бы методы по контракту на Обслуживание.
Я просто решил, что можно выставить несколько конечных точек (каждое использование различного интерфейса) к тому же сервису, и Вы все еще только должны генерировать ОДИН lib прокси на клиенте, который предоставляет доступ ко всем ним, который решает мою проблему полностью.