Веб-сервисы ASP.NET в общих сборках (DLL)

Question

У нас есть некоторые вещи ASP.NET (они недостаточно четко обозначены, чтобы называть его компонентом), которые мы хотели бы очистить и обернуть некоторые границы, чтобы мы могли использовать их повторно. На самом деле это четыре части, некоторая разметка, немного кода C #, некоторый javascript, выполняемый в браузере, и метод веб-сервиса, который вызывается javascript.

Один из способов очистки этого состоит в том, чтобы переместить разметку в пользовательский элемент управления, C # - в методы code-behind пользовательского элемента управления, javascript - в файл, который будет включен в страницу code-behind. метод и веб-сервис в статический метод в коде позади. (Конечно, при условии, что я могу пометить статический метод в пользовательском элементе управления как WebMethod и заставить его работать, что я еще не пробовал.)

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

Контроль сервера, конечно, означает отсутствие разметки. HTML должен быть введен в страницу с помощью C #. Это не проблема, мы сделали это раньше. Включение javascript в качестве ресурса и вставка элемента управления сервером на страницу не кажется слишком сложным. Я еще этого не сделал, но я вижу множество примеров того, как это сделать, поэтому я уверен, что смогу это выяснить.

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

Дело в том, что, поскольку серверный элемент управления включен в DLL, мы бы хотели, чтобы код этой веб-службы также был включен в DLL. Прямо сейчас все, о чем я могу думать, это определить класс внутри DLL, который выполняет всю работу, которая требуется веб-сервису, который затем может быть вызван веб-сервисом, который мы определяем в веб-приложении. Но я не очень доволен этим. В моем идеальном мире простое включение элемента управления сервером в веб-приложение автоматически включало бы и настраивало веб-сервис, с которым ему нужно было общаться. Но я не знаю, как это сделать, и я не уверен, что это возможно.

Итак, я ищу возможности приблизиться к этому в ASP.NET 3.5.

Идеи

Answer 1

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

Вероятно, самое чистое и идиоматическое решение .NET - использовать HttpHandler для конечной точки на стороне сервера. Потребляющему приложению потребуется дополнение в одну строку web.config, но дополнительные файлы создавать не нужно.

Посмотрите, как ASP.NET AJAX реализует ScriptResource.axd для хорошего, конкретного примера такого подхода. Исходный код для этого: http://www.microsoft.com/downloads/details.aspx?FamilyId=EF2C1ACC-051A-4FE6-AD72-F3BED8623B43&displaylang=en

Answer 2

Я вижу, что этому посту уже пару лет, но я подумал, что потрачу два своих цента за то, чего он мало стоит.

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

В двух словах, он использует интерфейс старой школы ICallbackEventHandler в DLL для связи. Я встроил JavaScript, который асинхронно выполняет обратный вызов для связи непосредственно с серверным элементом управления.

Все это прекрасно работает, но есть несколько ограничений, которые вам нужно понять.

Прежде всего, подход CallbackEvent не такой легкий, как статический WebMethod. Я полагаю (по крайней мере, большая часть) жизненного цикла страницы выполняется как часть обработки обратного вызова.

Вторым является то, что «может быть только один» :), поэтому, если у вас есть другие элементы управления, использующие тот же стиль связи CallbackEvent, вам нужно быть осторожным и убедиться, что вы знаете, какой из них запускает обратный вызов. В моем контроле у ​​меня есть дополнительный параметр RaiseCallbackEvent, который можно использовать, чтобы указать, какой элемент управления совершил вызов (и он предоставляет настраиваемое событие, на которое пользователи могут подписаться).

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

Вот полный исходный код (с демонстрациями) , если вам интересно.

Answer 3

Я бы четко определил API веб-сервисов, чтобы серверный элемент управления «знал», как их вызывать. Серверный элемент управления должен создаваться динамически, чтобы он содержал JavaScript, необходимый для вызова WebServices в соответствии с заранее определенным API. Я предложил это, потому что:

• У меня есть код в производстве, создающий управляемые дБ динамические элементы управления с настраиваемыми функциями JavsScript
• как указано выше, статические методы в коде, помеченном как WebMethod (если установлен параметр EnablePageMethods), могут вызывать некоторый уровень в БД и т. Д.
• вы можете использовать JQuery для асинхронной передачи новых данных из WebService на страницу

В любом случае, я был бы рад прочитать и о других подходах ...

В любом случае, проверьте эту ссылку

и Использование jQuery для прямого вызова методов страницы ASP.NET AJAX

Answer 4

Если ваш веб-сервис взаимодействует только с одним элементом управления, и для каждого экземпляра веб-приложения требуется свой собственный веб-сервис .... тогда я не уверен, что вижу цель его использования в качестве веб-сервиса.

Вы уверены, что не можете просто сделать функциональность веб-сервиса частью приложения? Что он делает, что это должен быть сервис?