Являются ли автоматически созданные прокси лучшим подходом для реализации асинхронного клиента WCF?

Question

Я проектирую архитектуру для проекта C # / .NET 3.5, который будет взаимодействовать между клиентом и сервером через WCF.Как правило, это будет система запрос-ответ, поэтому в качестве примера один из методов службы может выглядеть следующим образом:

User GetUserByLastName(string lastName);

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

У меня есть подтверждение концепции, которую я реализовал в соответствии с документацией Microsoft, поэтому прокси-серверы клиентовавтоматически генерируются с помощью диалогового окна «Добавить ссылку на службу» в Visual Studio, и я отмечаю опцию включения асинхронных методов.

Это прекрасно работает в качестве подтверждения концепции, но я встречал многочисленные посты в блоге и другие ссылкиНастоятельно рекомендуем не использовать автоматически сгенерированные прокси в крупномасштабном проекте.Некоторые из этих источников представляют альтернативы, включающие создание прокси вручную или динамическое создание прокси с использованием отражения, но эти решения, по-видимому, неизменно реализуют только синхронные вызовы WCF.

Автоматически сгенерированный прокси для асинхронного клиента WCF включает в себя довольнокод, который я бы не хотел применять вручную для каждого сервиса и метода.

Итак, мой вопрос:

Это плохая идея использовать автоматически сгенерированные прокси для асинхронныхУслуги WCF и, если да, есть ли хорошая альтернатива, которая не требует значительного ручного обслуживания кода котельной плиты?

Answer 1

Это плохо по нескольким причинам, и я уверен, что вы прочитали их все в этих сообщениях в блоге.Для меня основными недостатками являются:

1) Создание канала - полный беспорядок, уродливый и неэффективный

2) Невозможно кэшировать ChannelFactory

3)хорошо работать с DI

4) Если вы повторно используете клиент, канал может выйти из строя, и вам придется кодировать его

5) Это генерация кода, и если ваш код изменяется, вы должнырегенерация.

6) Это не экономит много кода, если честно.Создание фабрики каналов с использованием интерфейса службы (и ее кэширование), а затем создание прокси-сервера - это несколько строк кода, если вы используете web.config / app.config для настройки конечной точки.