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?
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