ASP.NET webservices in shared assemblies (DLLs)

Question

We have some ASP.NET stuff (it's not delineated clearly enough to call it a component), that we'd like to clean up, and wrap some boundaries around, so that we can reuse it. There are really four parts to this, some markup, some C# code-behind, some javascript running in the browser, and a webservice method that is called by the javascript.

One way of cleaning this up would be to move the markup into a user control, the C# into the code-behind methods of the user control, the javascript into a file that would be included in the page by the code-behind method, and the webservice into a static method in the code-behind. (Assuming, of course, that I can flag a static method in a User Control as a WebMethod and have it work, which I've not tried yet.)

In any case, the above won't work for us, because we want to create a component that we can include in multiple projects. And that means we want a component we can include in a DLL, and that means a Server Control, instead of a User Control.

A Server Control, of course, means no markup. The html needs to be injected into the page by the C#. That's not a problem, we've done that before. Including the javascript as a resource, and having the Server Control insert it into the page doesn't seem too difficult. I've not done it, yet, but I see plenty of examples on how to, so I'm sure I will be able to figure it out.

But the part of this I'm not sure I understand, yet, is the webservice. This control will include javascript that will make calls back to a webservice. The webservice will communicate only with the Server Control, but it will need to talk to the same database that the Web Application that is including the Server Control is talking to. That is, this isn't a situation where we can configure a single, stand-alone webservice that all instances of the Server Control will talk to, we need a separate webservice included in each Web Application that includes the Server Control.

The thing is, that since the Server Control is included in a DLL, we'd like for the code for this webservice to also be included in the DLL. Right now, all I can think of is to define a class within the DLL that does all the work that the webservice needs to, that can then be called by a webservice that we define in the Web Application. But I'm not really happy with that. In my ideal world, simply including the Server Control in the Web Application would automatically include and configure the webservice that it needs to talk to. But I don't know how to do that, and I'm not sure that it is possible.

So what I'm looking for are possibilities as to how close I could get to that, within ASP.NET 3.5.

Ideas?

Answer 1

I see this post is a couple of years old but I thought I'd throw my two cents in for what little it's worth.

If I understand you correctly, I believe I'm doing something similar with a particular server control I wrote you might want to look at.

In a nutshell, it uses the old-school ICallbackEventHandler interface within the DLL for communication. I have embedded javascript that asynchronously performs the callback to communicate directly with the server control.

It all works nicely, but there are a couple of limitations you need to understand.

First and foremost is that CallbackEvent approach is not quite as light weight as a static WebMethod. I believe (at least most of) the page lifecycle executes as part of the callback processing.

The second is that "there can be only one" :) so if you have other controls making use of the same CallbackEvent style of communication, you need to be careful and make sure you know which one is firing the callback. In my control, I have an additional parameter on the RaiseCallbackEvent that can be used to tell which control made the call (and it exposes a custom event that users can subscribe to).

Unfortunately even though it's not perfect, this is the best only solution I've been able to come up with that completely wraps up all of the functionality you describe into a single reusable server control.

Here is the complete source (with demos) if you're interested.

Answer 2

To my knowledge, there's no way to completely encapsulate the server-side endpoint within a server control. It's something I've wrestled with in the past without a completely satisfactory solution.

Probably the cleanest, most idiomatic .NET solution is to use an HttpHandler for the server-side endpoint. The consuming application will require a one-line web.config addition, but no additional files need be created.

Take a look at how ASP.NET AJAX implements ScriptResource.axd for a good, concrete example of this approach. Source code for that: http://www.microsoft.com/downloads/details.aspx?FamilyId=EF2C1ACC-051A-4FE6-AD72-F3BED8623B43&displaylang=en

Answer 3

I would define clearly the API of the Webservices so that the Server control would "know" how-to call them. The server control should be instantiated dynamically so that it will contain the JavaScript needed for calling the WebServices according to the predifined API. I proposed this because:

• I have code in production creating db driven dynamic controls with configurable JavsScript functionalities
• as stated above static methods in code behind marked as WebMethod (if EnablePageMethods is set) could call some db layer further on etc.
• you could use JQuery to push the new data from the WebService to the page asyncronously

Anyway I would be glad to read about other approaches also ...

Anyway check this link

and Using jQuery to directly call ASP.NET AJAX page methods

Answer 4

If your webservice only communicates with the one control, and each instance of the web application requires it's own webservice.... then I'm not sure I see the purpose of it being a webservice.

Are you sure you can't just make the webservice functionality part of the application? What's it doing that it needs to be a service?