asp consommant un service web, que faire de l'objet recordset ?

Question

Actuellement, j'utilise une page web ASP classique (ancienne) avec un objet recordset utilisé directement dans la mauvaise vieille méthode de code spagethi.

J'envisage de mettre en œuvre une couche de données en asp.net en tant que service web pour améliorer la gestion. C'est aussi un premier pas vers la mise à niveau du site web en asp.net. Le site lui-même reste ASP pour le moment...

Quelqu'un peut-il me recommander un bon moyen de remplacer le type d'objet recordset par un type compatible avec les services Web (comme un tableau ou autre) ? Que dois-je remplacer ci-dessous par.. :

set objRS = oConn.execute(SQL)
while not objRS.eof
   ...
   name = Cstr(objRS(1))
   ...
wend

et aussi que plusieurs jeux d'enregistrements peuvent être remplacés par ? Je parle de :

 set objRS = objRs.nextRecordset

Quelqu'un est passé par là et peut vous recommander ?

@AdditionalInfo - vous l'avez demandé :-)

Laissez-moi commencer par le début. La situation actuelle est : J'ai un vieux site web ASP avec un contenu hiérarchique classique (en-tête, section, sous-section, contenu) extrait de la base de données via des procédures stockées et les pages de contenu sont également dans la base de données (un lien vers le fichier html).

Le problème, c'est que le code ASP est réparti sur de nombreux fichiers .asp, qui établissent tous leurs propres connexions à la base de données, lisent et écrivent (il faut s'enregistrer pour le contenu). Récemment, nous avons eu des problèmes d'attaques par injection SQL et j'ai été appelé pour les résoudre.

I podría aller changer toutes les pages .asp pour empêcher l'injection sql mais ce serait de la folie. J'ai donc pensé construire une couche de données - toutes les pages utilisant cette couche pour accéder à la base de données. Un seul endroit pour corriger et mettre à jour le code d'accès à la base de données.

En prenant cette décision, j'ai pensé que la mise à jour d'asp.net n'était pas loin, pourquoi ne pas commencer à utiliser asp.net pour la couche de données ? De cette façon, il peut être réutilisé lors de la mise à niveau du site.

Ce qui m'amène aux questions ci-dessus !

Answer 1

Tout d'abord, mon conseil préféré de la semaine : ne traitez pas votre service Web comme s'il s'agissait d'un objet local ou vous allez payer un prix très élevé en termes de performances. Essentiellement, ne faites pas ce genre de choses dans votre application Web :

MyDataWebService ws = new MyDataWebService();
foreach(DataItem item in myData)
{
    ws.Insert(item);
}

Vous devriez toujours préférer minimiser les appels à votre service Web (et SQL) :

MyDataWebService ws = new MyDataWebService();
ws.Insert(myData); // Let the web service process the whole set at once.

Maintenant, en ce qui concerne le type de données à utiliser pour vos appels de service web, vous avez essentiellement deux choix :

• DataSet
• Tout le reste (Array)

La plupart des collections renvoyées par un service Web (comme une liste<MyData>) sont en fait converties en tableau pendant l'invocation du service Web. N'oubliez pas que les services Web ne renvoient pas d'objets (données + comportement) mais simplement des structures de données (ou une séquence de celles-ci). Par conséquent, il y a peu de différence entre une liste et un tableau.

Les DataSets sont des classes plus complexes ; elles utilisent leur propre sérialiseur personnalisé et sont pratiquement entièrement recréées dans l'application appelante. L'utilisation de DataSets de cette manière a un coût en termes de performances, c'est pourquoi je ne la recommande généralement pas dans la plupart des scénarios. L'utilisation de tableaux pour transmettre des données dans les deux sens est généralement plus efficace et, franchement, plus facile à réaliser.

Votre cas est un peu différent ; parce que vous convertissez un site existant qui utilise déjà ADO, un DataSet ADO.NET pourrait être votre meilleure voie de mise à jour. ADO.NET et ADO sont suffisamment similaires pour qu'une mise à jour directe soit plus facile de cette façon. Cela dépend en quelque sorte de la façon dont votre site Web est construit.

Pour la dernière partie de votre question, les DataSets prennent en charge les recordsets multiples, comme les Recordset d'ADO. Ils sont appelés DataTables. Chaque DataSet possède au moins une DataTable et vous pouvez les lire dans n'importe quel ordre.

Bonne chance.

Answer 2

Je vous suggère d'utiliser la classe XmlHttp dans votre code ASP.

En supposant que vous avez un service web ASMX similaire à celui-ci, dans MyService.asmx :

[WebMethod]
public string HelloWorld()
{
  return "Hello World";
}

Vous pourriez l'appeler en ASP de la manière suivante :

Dim xhr

Set xhr = server.CreateObject("MSXML2.XMLHTTP")

xhr.Open "POST", "/MyService.asmx/HelloWorld", false
xhr.SetRequestHeader "content-type", "application/x-www-form-urlencoded"
xhr.Send

Response.Write(xhr.ResponseText)

ResponseText serait une réponse XML de :

<string>Hello World</string>

En supposant que votre service renvoie un ensemble de données, vous pouvez le parcourir en utilisant XPath ou toute autre technique/librairie de traitement XML.

Une recherche sur MSXML2 répondra probablement à vos questions spécifiques, puisqu'il s'agit d'un outil spécifique à ASP classic.

Answer 3

Au lieu de penser en couches, pourquoi ne pas essayer de prendre des tranches verticales de l'application et de les convertir en .net. Ainsi, vous obtiendrez des fonctionnalités entières codées en .net au lieu de parties disjointes. Quelle valeur commerciale y a-t-il à remplacer un code qui fonctionne parfaitement sans améliorer l'expérience de l'utilisateur ou ajouter des fonctionnalités ?

Vous pouvez également prendre en compte le compromis de performance auquel vous allez renoncer avec un service Web par rapport aux appels publicitaires directs. Les services Web constituent une bonne solution au problème de l'accès à un schéma commun par plusieurs applications/équipes disjointes ; ils ne rendent pas une application isolée plus facile à maintenir, mais seulement plus lente et plus complexe.

Answer 4

Si vous voulez vous en tenir à l'ASP classique, je vous suggère de créer un objet de gestion de base de données via les classes ASP, puis d'utiliser cet objet pour créer vos jeux d'enregistrements. Cela centraliserait votre code de gestion de base de données et ferait en sorte que vous n'ayez à gérer les attaques par injection SQL qu'à un seul endroit.

Un exemple simple.

Class clsDatabase

    Private Sub Class_Initialize()
        If Session("Debug") Then Response.Write "Database Initialized<br />"
    End Sub

    Private Sub Class_Terminate()
        If Session("Debug") Then Response.Write "Database Terminated<br />"
    End Sub

    Public Function Run(SQL)
        Set RS = CreateObject("ADODB.Recordset")
        RS.CursorLocation = adUseClient
        RS.Open SQLValidate(SQL), Application("Data"), adOpenKeyset, adLockReadOnly, adCmdText
        Set Run = RS
        Set RS = nothing
    End Function

    Public Function SQLValidate(SQL)
        SQLValidate = SQL
        SQLValidate = Replace(SQLValidate, "--", "", 1, -1, 1)
        SQLValidate = Replace(SQLValidate, ";", "", 1, -1, 1)
        SQLValidate = Replace(SQLValidate, "SP_", "", 1, -1, 1)
        SQLValidate = Replace(SQLValidate, "@@", "", 1, -1, 1)
        SQLValidate = Replace(SQLValidate, " DECLARE", "", 1, -1, 1)
        SQLValidate = Replace(SQLValidate, "EXEC", "", 1, -1, 1)
        SQLValidate = Replace(SQLValidate, " DROP", "", 1, -1, 1)
        SQLValidate = Replace(SQLValidate, " CREATE", "", 1, -1, 1)
        SQLValidate = Replace(SQLValidate, " GRANT", "", 1, -1, 1)
        SQLValidate = Replace(SQLValidate, " XP_", "", 1, -1, 1)
        SQLValidate = Replace(SQLValidate, "CHAR(124)", "", 1, -1, 1)
    End Function
End Class

Pour l'utiliser, vous devez alors modifier vos appels :

Set oData = new clsDatabase
Set Recordset = oData.Run("SELECT field FROM table WHERE something = another")
Set oData = nothing

Bien sûr, vous pouvez étendre la classe de base pour gérer des procédures stockées paramétrées ou autres, ainsi que des validations supplémentaires, etc.

Answer 5

Une autre solution consiste à utiliser COM Interop pour créer une assemblée dans .NET qui peut être appelée à partir d'ASP classique.

Pour créer un assemblage COM Interop à partir de Visual Studio (par exemple, Microsoft Visual C# 2005 Express Edition) :

• Créer un nouveau projet de bibliothèque de classe

• Ouvrez les propriétés du projet

  • Sous Application, sélectionnez Assembly Information... et activez "Make assembly COM-Visible".
  • Sous Signer, activez Signer l'assemblage et créez ou sélectionnez un fichier clé de nom fort existant.

• Écrire et construire la bibliothèque

  • Les classes COM Interop doivent avoir un constructeur par défaut et seules les classes et méthodes non statiques sont publiées.

• Copiez le fichier .dll dans le dossier/machine souhaité.

• Enregistrer le fichier .dll pour COM à l'aide de RegAsm

Par exemple (ajustez si nécessaire) :

"C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe" "C:\path\to\assembly.dll" /tlb /codebase

• Appeler l'assemblage depuis ASP

Par exemple (ajustez si nécessaire) :

Dim obj, returnValue
Set obj = Server.CreateObject("MyProject.MyClass")
returnValue = obj.DoSomething(param1, param2)

Note :

• l'assemblage doit être réenregistré via RegAsm lorsqu'il est mis à jour

Voir aussi :

• Exposer les composants de .NET Framework à COM (MSDN)
• CodeProject : Appeler un composant .NET depuis une page ASP