Webservices ASP.NET dans les assemblys partagés (DLL)

Question

Nous avons quelques ASP.NET (ce n'est pas assez clair pour l'appeler un composant), que nous aimerions nettoyer, et entourer certaines limites, de sorte que nous pouvons le réutiliser. Il y a vraiment quatre parties à cela, du balisage, du code-behind C#, du javascript dans le navigateur, et une méthode webservice appelée par le javascript. Une façon de nettoyer cela serait de déplacer le balisage dans un contrôle utilisateur, le C# dans les méthodes code-behind du contrôle utilisateur, le javascript dans un fichier qui serait inclus dans la page par le code- derrière la méthode, et le webservice dans une méthode statique dans le code-behind. (En supposant, bien sûr, que je peux marquer une méthode statique dans un contrôle utilisateur comme un WebMethod et le faire fonctionner, que je n'ai pas encore essayé.)

Dans tous les cas, ce qui précède ne fonctionnera pas pour nous , parce que nous voulons créer un composant que nous pouvons inclure dans plusieurs projets. Et cela signifie que nous voulons un composant que nous pouvons inclure dans une DLL, et cela signifie un contrôle du serveur, au lieu d'un contrôle utilisateur.

Un contrôle de serveur, bien sûr, signifie pas de balisage. Le code HTML doit être injecté dans la page par le C#. Ce n'est pas un problème, nous l'avons déjà fait. Y compris le javascript comme une ressource, et avoir le contrôle du serveur l'insérer dans la page ne semble pas trop difficile. Je ne l'ai pas encore fait, mais je vois beaucoup d'exemples sur la façon de le faire, alors je suis sûr que je serai capable de le comprendre.

Mais la partie de ceci je ne suis pas sûr que je comprends, pourtant, est le webservice. Ce contrôle inclura javascript qui rendra les appels à un webservice. Le service Web communiquera uniquement avec le contrôle du serveur, mais il devra parler à la même base de données que l'application Web qui inclut le contrôle serveur. Autrement dit, il ne s'agit pas d'une situation où nous pouvons configurer un service Web unique et autonome auquel toutes les instances du serveur de contrôle vont s'adresser. Nous avons besoin d'un service Web distinct inclus dans chaque application Web qui inclut le contrôle serveur. Le fait est que, puisque le contrôle du serveur est inclus dans une DLL, nous aimerions que le code de ce service Web soit également inclus dans la DLL. À l'heure actuelle, tout ce que je peux penser est de définir une classe dans la DLL qui fait tout le travail dont le webservice a besoin, qui peut ensuite être appelée par un service web que nous définissons dans l'application Web. Mais je ne suis pas vraiment content de ça. Dans mon monde idéal, inclure simplement le contrôle du serveur dans l'application Web inclurait et configurerait automatiquement le service Web auquel il devrait s'adresser. Mais je ne sais pas comment faire ça, et je ne suis pas sûr que ce soit possible.

Donc, ce que je cherche sont des possibilités quant à la façon dont je pourrais arriver à cela, dans ASP.NET 3.5.

Des idées?

Answer 1

A ma connaissance, il n'y a aucun moyen d'encapsuler complètement le point de terminaison côté serveur dans un contrôle serveur. C'est quelque chose avec lequel j'ai lutté dans le passé sans une solution complètement satisfaisante.

La solution .NET la plus propre et la plus idiomatique est probablement d'utiliser un HttpHandler pour le point de terminaison côté serveur. L'application consommatrice nécessitera une addition web.config d'une ligne, mais aucun fichier supplémentaire ne doit être créé. Jetez un oeil à la façon dont ASP.NET AJAX implémente ScriptResource.axd pour un bon exemple concret de cette approche. Le code source pour cela: http://www.microsoft.com/downloads/details.aspx?FamilyId=EF2C1ACC-051A-4FE6-AD72-F3BED8623B43&displaylang=en

Answer 2

Si votre service Web communique uniquement avec le contrôle unique, et chaque instance de l'application Web nécessite son propre service Web .... alors je ne suis pas sûr que je vois le but de ce service Web. Etes-vous sûr que vous ne pouvez pas simplement faire de la fonctionnalité webservice une partie de l'application?

Que fait-il qu'il doit être un service?

Answer 3

Je définirais clairement l'API des Webservices afin que le contrôle serveur "sache" comment les appeler. Le contrôle serveur doit être instancié dynamiquement afin qu'il contienne le code JavaScript nécessaire pour appeler les WebServices en fonction de l'API prédéfinie. Je propose cela parce que:

• J'ai le code dans la production la création de contrôles dynamiques conduit db avec des fonctionnalités JavsScript configurables
• comme indiqué ci-dessus méthodes statiques dans le code derrière marqué comme WebMethod (si EnablePageMethods est défini) pourrait appeler une db couche supplémentaire sur etc.
• vous pouvez utiliser JQuery pour pousser les nouvelles données du WebService à la page asyncronously

Quoi qu'il en soit je serais heureux de lire sur d'autres approches aussi ...

vérifier Quoi qu'il en soit ce link

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

Answer 4

Je vois que cet article a quelques années mais je pensais que je jetterais mes deux cents pour le peu que ça vaut. Si je vous comprends bien, je crois que je fais quelque chose de similaire avec un contrôle de serveur particulier que j'ai écrit que vous pourriez vouloir regarder. En un mot, il utilise la vieille interface ICallbackEventHandler dans la DLL pour la communication. J'ai javascript incorporé qui effectue de façon asynchrone le rappel pour communiquer directement avec le contrôle du serveur.

Tout fonctionne bien, mais il y a quelques limitations à comprendre.

D'abord et avant tout, l'approche CallbackEvent n'est pas aussi légère qu'une WebMethod statique. Je crois (au moins la majeure partie) du cycle de vie de la page s'exécute dans le cadre du traitement de rappel. La seconde est que "il ne peut y en avoir qu'un" :) donc si vous avez d'autres contrôles utilisant le même style de communication CallbackEvent, vous devez être prudent et vous assurer de savoir lequel déclenche le callback. Dans mon contrôle, j'ai un paramètre supplémentaire sur le RaiseCallbackEvent qui peut être utilisé pour dire quel contrôle a fait l'appel (et il expose un événement personnalisé auquel les utilisateurs peuvent s'abonner).

Malheureusement, même si ce n'est pas parfait, c'est le meilleur seule solution que j'ai pu trouver qui complète complètement toutes les fonctionnalités que vous décrivez dans un seul contrôle de serveur réutilisable.

Voici le complete source (with demos) si vous êtes intéressé.