Оба метода генерации прокси действительны, это зависит от того, насколько вы хотите контролировать прокси, и от того, владеете ли вы обеими сторонами кода. Третий вариант также существует, вы можете вручную создать свой собственный прокси. Позвольте мне объяснить далее:
В SOA мы передаем сообщения, это другая парадигма для передачи указателей на объекты в куче / стеке, что является нормой в мире OO.
Таким образом, в SOA контракт (что вы можете сделать) и сообщение (государство, в котором необходимо действовать) важны и должны быть переданы потребителям сервиса, чтобы они все могли договориться о контракте или «правилах Вовлеченность »здесь мы имеем самую основную форму SOA.
Введите WS- * набор спецификаций для добавления дополнительной функциональности к нашему вызову службы (распределенные транзакции, безопасность и т. Д.), Но если мы сделаем это, нам всем нужно будет согласовать правила и разновидность типа взаимодействия мы намереваемся использовать, поэтому сервис и его клиенты должны точно договориться о том, как это должно происходить, и обмениваться ими.
Комбинация определений контракта и спецификаций WS- * называется WSDL, и это обычно то, что распределяется между клиентами и сервисами, это согласуется с SOA-арендаторами, которых мы разделяем схемой и контрактом, а не классом, и что Совместимость основана на политике (WS - *).
Таким образом, если вы используете фабрику каналов, вы генерируете прокси на основе имеющегося у вас определения интерфейса и конфигурации, которую вы настроили на лету, если вы используете add service reference, вы позволяете IDE генерировать прокси-класс на основе WSDL сервис, как он существует тогда.
Если вы вручную создадите прокси-сервер, у вас будет полный контроль над тем, как это происходит, и вы можете перейти в цепочку перехвата и выполнить действия на стороне клиента для управления вызовом.
Зависит от того, что вы хотите сделать.