views:

182

answers:

3

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?

A: 

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?

womp
The javascript is running on the browser. It needs to communicate back with code running on the server, asynchronously. There has to be something on the server listening for that communications. Webservices are the usual mechanism for doing that.A webservice could be implemented standalone, or as a .asmx file within the web application, or as a static method on the page, marked as a WebMethod (if EnablePageMethods is set).But all of these require the instantiation of something outside of the Server Control. I'd like to minimize that.
Jeff Dege
A: 

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

YordanGeorgiev
Yes, to all of that. I want the user of the ServerControl to be able to use the control with as little effort as possible. That means that the ServerControl encapsulates the knowledge of what the webservice looks like, how it is called, what it returns, etc. But how to run the webservice is the question.It's simple enough to put a WebMethod on the page, but that requires the user of the ServerControl to create a WebMethod on the page. I'd rather have the ServerControl create the WebMethod, when it is added to the page. But I'm not sure that is possible.
Jeff Dege
I see. The only hint I could give you is to check the BlogEngine source code from CodePlex - the pages in the project are created dynamically from the very beginning ... I guess if one could create the entire page dynamically it should be possible to add a static web method to it dynamically ... Anyway still I am still interested about your problem's solution - I guess it will become soon my problem too ; ) So if you could post some blog links or whatever of how you solved the problem I will appreciate it ...
YordanGeorgiev
A: 

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

Dave Ward
I'm not sure I agree on using HttpHandlers. First, they're still something of a obscurity in ASP.NET programming, not commonly used and not well-understood by most developers. Second, when a future maintenance programmer is trying to understand the control, it's the code for the control and for the page it sits on that he's going to be looking at. It may only be one line in the web.config, but it's out of view. A WebMethod on the page that delegates its functionality to a method in the control has the benefit of being in a source file that the maintenance programmer will be looking at.
Jeff Dege
That makes sense, and I don't fundamentally disagree, but I'm not aware of a realistic alternative when embedding the endpoint in a DLL.
Dave Ward