Почему статические методы не используются в качестве веб-служб в веб-службах ASMX?

Ответ 1

Ответ: потому что вы не можете.

Это не так. Дизайн состоит в том, что будет создан экземпляр класса веб-службы, а затем вызывается метод экземпляра.

Я могу только догадываться, почему именно Microsoft разработала его. Чтобы точно знать, вы должны спросить их. Рассмотрим:

• Нет особых преимуществ для разрешения статических методов. Все, что вы можете сделать со статическим методом, вы также можете использовать с методом экземпляра.
• Класс [WebService] не должен быть произвольным классом, который используется как веб-служба. Это означает, что вы создали класс, предназначенный для раскрытия операций веб-сервиса. Таким образом, нет необходимости поддерживать классы, которые уже существуют и уже имеют статические методы.
• Реализация заголовка SOAP позволяет вашему классу содержать поле экземпляра типа, полученного из класса SoapHeader. Это поле будет заполнено входящим заголовком SOAP и/или будет содержать заголовок SOAP, который будет возвращен. Вы не могли бы сделать это со статическим полем, так как оно было бы перезаписано каждым запросом.

Как я уже сказал, это все догадки. Правильный ответ на вопрос: "вы не можете, потому что это разработало Microsoft. Если вы хотите знать, почему они так его спроектировали, вам нужно спросить их".

FWIW, я только что проверил, и не кажется, что WCF также позволяет использовать статические методы.

Ответ 2

Когда клиент создает объект для вашего веб-сервиса, то, что они действительно создают, является прокси-объектом для этой веб-службы. Этот прокси-объект обрабатывает такие вещи, как открытие и закрытие ваших соединений для вас, а также все накладные расходы на фактическую работу с веб-службой. Статический вызов метода будет трудно управлять. "Статический прокси" из-за отсутствия лучшего слова должен был бы делать все, что экземпляр прокси-объекта делает каждый раз, когда клиент вызывает один из статических методов, тем самым добавляя значительные накладные расходы.