asp потребляет веб-сервис, что делать с объектом recordset?

Question

В настоящее время я запускаю классическую (старую) веб-страницу ASP с объектом набора записей, используемым непосредственно в плохом старом кодексе spagethi fasion.

Я думаю о внедрении слоя данных в asp.net в качестве веб-serivce для улучшения управляемости. Это также первый шаг к обновлению веб-сайта до asp.net. Сам сайт остается ASP на данный момент ...

Может ли кто-нибудь рекомендовать хороший способ замены типа объекта набора записей на совместимый с веб-сервисом тип (например, массив или что-то еще)? Что я заменяю ниже с ?:

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

, а также mutliple наборы записей можно заменить? Я говорю:

set objRS = objRs.nextRecordset 

Любой прошел через это и может порекомендовать?

@AdditionalInfo - Вы просили об этом :-)

Позвольте мне начать с самого начала. Существующая ситуация: У меня есть старый веб-сайт ASP с классическим иерархическим контентом (заголовок, раздел, подразделение, контент), вытащенный из базы данных через хранимые процедуры, а страницы содержимого также находятся в базе данных (ссылка на файл html).

Теперь плохо, ASP-код повсюду распространяется по многим файлам .asp, все делают свои собственные подключения к базе данных, читают, пишут (вам нужно зарегистрироваться для контента). В последнее время у нас были проблемы с атаками SQL-инъекций, поэтому я был вызван, чтобы исправить это.

I может перейти на все страницы .asp, чтобы предотвратить инъекцию sql, но это было бы безумием. Поэтому я решил создать слой данных - все страницы, использующие этот слой для доступа к базе данных. Как только место исправить и обновить код доступа к базе данных.

Приходя к такому решению, я думал, что обновление asp.net не далеко, почему бы не начать использовать asp.net для слоя данных? Таким образом, он может быть повторно использован при обновлении сайта.

Это подводит меня к вышеуказанным вопросам!

Answer 1

Если вы хотите придерживаться классического ASP, я бы предложил создать объект обработки базы данных через ASP-классы, а затем просто использовать этот объект для создания ваших записей. Это позволит централизовать код обработки базы данных и сделать так, чтобы вам приходилось обрабатывать атаки SQL Injection в одном месте.

Простой пример.

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 

Затем, чтобы использовать это, вы бы изменить вызовы:

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

Конечно, вы можете расширить базовый класс для обработки параметризованных хранимых процедур или что нет и больше валидаций и т.д.

Answer 2

Первый мой любимый совет на этой неделе: не относитесь к своему веб-сервису так, как если бы это был локальный объект, или вы собираетесь платить очень здоровую цену исполнения.По сути, не делают такие вещи, как это в вашем веб-приложения:

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

Вы должны всегда предпочитают минимизировать вызовы на веб-службы (и SQL):

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

Теперь, насколько тип данных, используемый для вызовов веб-сервиса, вы в принципе есть два варианта:

• DataSet
• Все остальное (Array)

Большинство коллекций, возвращенных из веб-службы (например, списка <MyData>), фактически преобразуются в массив во время вызова веб-службы. Помните, что веб-службы не возвращают объекты (данные + поведение), а просто структуры данных (или последовательность). Поэтому существует небольшое различие между списком и массивом.

DataSets - более сложные классы; они используют свой собственный сериализатор и в значительной степени полностью воссоздаются в вызывающем приложении. За счет использования таких наборов данных можно заплатить за производительность, поэтому я обычно не рекомендую ее для большинства сценариев. Использование массивов для передачи данных вперед и назад имеет тенденцию быть более эффективным, и, откровенно говоря, это проще сделать.

Ваш случай немного отличается; потому что вы конвертируете существующий сайт, который уже использует ADO, ADO.NET DataSet может стать вашим лучшим способом обновления. ADO.NET и ADO достаточно похожи, что прямое обновление может быть проще. Это зависит от того, как строится ваш веб-сайт.

Для последней части вашего вопроса, DataSets поддерживают несколько наборов записей, похожих на набор записей ADO. Они называются DataTables. Каждый DataSet имеет по крайней мере один DataTable, и вы можете читать их в любом порядке.

Удачи.

Answer 3

Я бы предложил использовать класс XmlHttp в вашем ASP-коде.

Если у вас есть веб-службы ASMX похожее на это, в MyService.asmx:

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

Вы могли бы назвать его в ASP-то вроде этого:

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 будет ответное XML of:

<string>Hello World</string> 

Предполагая, что ваша служба вернула набор данных, вы можете перебирать он использует XPath или любую другую технику/библиотеку XML.

Поисковая оптимизация по MSXML2, вероятно, ответит на любые ваши конкретные вопросы, поскольку она специфична для ASP classic.

Answer 4

Вместо того, чтобы думать в слоях, почему бы не попробовать вертикальные срезы через приложение и преобразовать их в .net. Таким образом, вы получите целые функции, закодированные в .net вместо непересекающихся частей. Какова ценность бизнеса при замене отлично работающего кода без улучшения пользовательского опыта или добавления функций?

Вы также можете рассмотреть компромисс производительности, с которым вы собираетесь отказаться от веб-службы по прямым вызовам ado. Веб-службы - это хорошее решение проблемы нескольких непересекающихся приложений/команд, обращающихся к общей схеме; они не делают одно изолированное приложение более удобным для обслуживания, только медленнее и сложнее.

Answer 5

Другой альтернативой является использование COM Interop для создания сборки в .NET, которая может быть вызвана из классического ASP.

Чтобы создать сборку COM Interop из Visual Studio (например, Microsoft Visual C# 2005 Express Edition):

• Создать новый проект библиотеки классов

• Откройте свойства проекта

  • Под Выбор приложения Информация о сборке ... и включите «Сделать сборку COM-видимой»
  • Под защитой подписи Подпишите сборку и создайте или выберите т существующий сильное имя файла ключа

• записи и построить библиотеку

  классы
  • COM Interop должен иметь конструктор по умолчанию и только не-статические классы и методы опубликованы

• Скопируйте файл .dll в нужную папку/машину.

• Зарегистрируйте.DLL для COM, используя Regasm

Например (при необходимости отрегулировать):

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

• Вызов сборки из ASP

Например (при необходимости отрегулировать):

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

Примечание:

• узел должен быть перерегистрирован через Regasm, когда он обновляется

Смотрите также:

• Exposing .NET Framework Components to COM (MSDN)
• CodeProject: Call a .NET component from an ASP Page

Answer 6

Sql инъекция должна быть обработана используя параметризованные sql-запросы. Это не только устранит риск безопасности, но и значительно ускорит производительность вашей базы данных, поскольку она сможет повторно использовать план выполнения, а не повторять его каждый раз. Предложение о том, чтобы обрабатывать его с помощью замены строк, является глупым. VB ужасен при обработке строк, и эти «замещающие» утверждения будут чрезвычайно дорогостоящими по производительности и памяти (также, на самом деле, вам все равно нужно обрабатывать символ »)

Перемещение кода в .net не улучшает его. Наличие кода db на ваших страницах неплохое; особенно если id вы говорите о небольшом сайте только с несколькими разработчиками. Тысячи сайтов используют эту технику для обработки баз долларов в транзакциях. Теперь непараметрированный динамический sql плохой, и вы должны работать над его устранением, но для этого не требуется переписывать приложение или .net. Мне всегда любопытно, почему люди видят .net как усовершенствование дезактома в своем приложении. Большая часть плохого кода и вредных привычек, которые существовали в модели COM, распространяются только во время конверсии.

Вам либо нужно сделать обязательство создать действительно сплоченную, минимально связанную конструкцию OO; или просто держите то, что у вас есть, потому что это не так уж плохо.

Answer 7

Жаль, что я не видел этого вопроса в 2008 году. Для меня это похоже на то, что ваш сайт использует структуру Justa. Простой способ - изменить код Justa для отправки поиска и ввода данных в urlencode. Я сделал это и отлично работал для меня.

Остальная часть кода достаточно защищена, чтобы предотвратить любые инъекции SQL-кода или другие попытки попасть в базу данных.