Что такое код asp accesssource


Содержание

Достать значение из SqlDataSource

Необходимо получить значение из SQLDATASOURCE например есть sqldatasource и есть TEXTBOX в выполняется pageload:

08.02.2010, 16:23

Получить значение из LinqDataSource или SqlDataSource
Здравствуйте. Сейчас только начинаю осваивать asp.net, поэтому такой глупый вопрос. На странице.

Достать значение по id
Есть web страница example.aspx. В коде example.aspx.cs генерируется button и label Button btn =.

Как достать значение байта из игры?
Нужно достать значение скорости грузовика из игры ETS. Возможно ли это сделать кодом, и если да.

Как присвоить значение для пареметров запросов SQLDATASOURCE?
Как присвоить значение для пареметров запросов SQLDATASOURCE update, insert, delete? Строка запроса.

Что такое код asp accesssource

Этот текст предназначен для тех, кто никогда не имел дела с ASP и вообще смутно себе представляет возможности программирования на стороне сервера. Я ставил себе задачу создать у читателя общее представление о предмете. Отдельные неточности при этом менее важны — пожалуйста, громко не ругайтесь.

Общие сведения

ASP (Active Server Pages) – это мощная технология от Microsoft, позволяющая легко разрабатывать приложения для WWW. ASP работает на платформе Windows NT и IIS (Internet Information Server), начиная с версии 3, хотя вроде есть реализации на других платформах. ASP – это не язык программирования, это внутренняя технология, позволяющая подключать программы к Web-страницам. Основа успеха ASP – простой скриптовый язык (Visual Basic Script или Java Script) и возможность использования внешних COM-компонент.

Как это все происходит?

Вы пишете программу и складываете в файл на сервере. Браузер клиента запрашивает файл. Файл сначала интерпретируется сервером, на выходе производится HTML-код. Этот HTML посылается клиенту. Файлы с программами имеют расширение .asp. Файлы asp – это обычные текстовые файлы, содержащие исходные тексты программ. Файлы делаются с помощью любого текстового редактора. Каталог, в котором размещены файлы asp должен иметь права на выполнение, так как сервер исполняет эти файлы, когда браузер их запрашивает. Собственно программы пишутся на любом скриптовом языке, который установлен в системе. По умолчанию поддерживаются VBScript и JavaScript. Можно доустановить другие (например, Perl). Если ничего специально не указывать используется VBScript. В дальнейшем будем ссылаться только на него. Программные фрагменты заключаются в скобки . Можно ставить открывающую скобку в начале файла, закрывающую – в конце, все что между ними – программа на Visual Basic’е.

Какие средства есть для программирования?

Web – нормальная среда программирования, если правильно понять, что есть что. В VBScript есть все нормальные конструкции структурного программирования (if, while, case, etc). Есть переменные (описывать не обязательно, тип явно не задается). Поддерживаются объекты. Работа с ними обычная – Object.Property, Object.Method. Есть ряд встроенных объектов (Request, Response, Session, Server, Connection, Recordset). Можно доустанавливать другие компоненты (скачивать, покупать, программировать), например для работы с электронной почтой.

Вывод

Понятия «экран», куда можно выводить данные нет. Все, что надо показать пользователю, выбрасывается в выходной поток на языке HTML. Браузер пользователя интерпретирует этот HTML. Для упрощения вывода существует объект Response . Вывод осуществляется с помощью метода Write .

Так производится запись во внутренний буфер объекта Response. Когда скрипт заканчивает работу, весь буфер выдается клиенту. Надо заметить, что клиент получает «чистый» HTML, таким образом программы на ASP не зависят от клиентского ПО, что очень важно. Если внутри выводимой строки нужно использовать кавычку, кавычка удваивается. Другие методы и свойства Response позволяют управлять выводом. Так Response.Buffer регулирует, получает ли клиент данные по мере из записи в Response, или все сразу по завершении исполнения страницы. Метод Response.Redirect перенаправляет браузер на другую страницу. Чтобы им пользоваться, нельзя до него на странице использовать Response.Write.

Программа на ASP не может явно спросить пользователя о чем-то. Она получает данные из других страниц, либо через URL. Передаваемые параметры помещаются во входной поток и доступны через объект Request . Чтобы передать переменную var в программу test.asp , надо написать:

Чтобы из программы получить значение этой переменной, надо написать:

Несколько переменных разделяется знаком &:

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

Так это выглядит:

При этом пользователь увидит форму из одного поля ввода (var1), в нем будет значение по умолчанию «default». Второе поле (var2) будет невидимо и будет передавать всегда фиксированное значение «var2value». Кнопка «Submit Form» завершает заполнение формы и передает все переменные на test.asp (action). Если method=»get», переменные передаются через URL (test.asp?var1=default&var2=var2value). Если method=»post», передаются вместе с запросом так, что внешне передача переменных не заметна. В вызываемой программе безразлично, какой метод изпользовался (почти). Если у вас нет специальных аргументов за метод GET, используйте метод POST.

Формы

Формы HTML используются для организации диалога с пользователем. Поддерживаются стандартные элементы управления. Все многообразие задается немногими тэгами:

  • INPUT (с параметром TYPE=)
  • SELECT
  • TEXTAREA

Описание – в документации по HTML.

Взаимосвязь между отдельными страницами

Обычно сервер WWW не хранит состояние приложения, т.е. все запросы взаимонезависимы, и нет стандартного способа понять, что несколько запросов пришли от одного и того же пользователя. Но это очень нужно для разработки полноценных приложений и является одной из главных проблем разработки Web-приложений.

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

ASP, используя cookies, предоставляет программисту более простое средство — объект Session (сессия). Сессия стартует, когда новый пользователь обращается к любому asp-файлу приложения. Сессия заканчивается при отсутствии активности пользователя в течение 20 минут, либо по явной команде. Специальный объект Session хранит состояние сессии. Туда можно записывать переменные, которые доступны из любой страницы в этой сессии. Записать данные в этот объект можно просто:

Считать потом еще проще:

Сессия, таким образом, – это еще один метод передачи данных между страницами. Одна страница пишет данные в сессию, другая – берет потом оттуда.

Наряду с объектом Session существует объект Application . Если сессия создается для каждого нового пользователя, до Application существует в единственном экземпляре, и может использоваться всеми страницами приложения.

Управление приложением

Программисту предоставляется возможность реагировать на 4 события: старт/стоп приложения и старт/стоп каждой сессии. Для реализации этих событий предназначен файл global.asa , который должен располагаться в корневом каталоге приложения. Вот его примерный скелет:

Нужно «просто» вписать Ваш код на соответствующее место. Нужно заметить, что отлаживать код для global.asa довольно непросто, так как он выполняется при очень специфических обстоятельствах (к примеру при старте или остановке сервера).

Использование внешних компонент

Если на сервере установлены дополнительные компоненты, их можно использовать из ASP. Стандартные объекты (например из библиотек ADO (Connection и Recordset) и Scripting (Dictionary, FileSystemObject)) доступны всегда. Установка новой компоненты обычно состоит в копировании dll-файла в каталог на сервере и ее регистрации с помощью программы regsvr32.exe. [В COM+ используется своя процедура инсталляции объектов, это однако не влияет на использования объектов.]

Создать экземпляр объекта можно так:

Class.Object указываются в документации на компоненту. В переменной var запоминается ссылка на созданный экземпляр объекта. Когда объект не нужен, ссылку нужно обнулить с помощью команды:

Пожалуйста всегда обнуляйте все ссылки на объекты, когда они больше не нужны. Теоретически это должно происходить автоматически при завершении процедуры/страницы, однако в стандартной сборке мусора есть определенные «проблемы».

В остальном использование компоненты зависит от самой этой компоненты.

Работа с базами данных

Из ASP можно легко и просто работать с любыми базами данных. Это делается через две промежуточные технологии: ODBC и ADO.

ODBC позволяет организовать доступ к любым базам данных через унифицированный интерфейс с помощью языка SQL. Специфика конкретных СУБД учитывается при помощи специальных драйверов БД. Такие драйверы существуют для всевозможных СУБД (в частности SQL Server, Oracle, Access, FoxPro). Поддержка ODBC обеспечивается на уровне операционной системы Windows (NT). Настройка – через Control Panel/ODBC. Базовым понятием является источник данных или data source. Источник данных – это совокупность сведений о базе данных, включая ее драйвер, имя компьютера и файла, параметры. Чтобы пользоваться базой надо создать источник данных для нее. Важно, чтобы источник данных был «системным», в отличии от «пользовательского». После этого надо лишь знать имя источника данных. [В настоящее время ODBC отступает перед натиском технологии OLE DB. На практике это однако практически ничего не изменяет. Вместо имени источника данных нужно использовать Connection String, в которой указывается имя ODBC-драйвера и все его параметры.]

ADO – это совокупность объектов, доступных из ASP, позволяющих обращаться к источнику данных ODBC [или OLE DB]. Фактически нужны лишь 2 объекта – Connection , представляющий соединение с базой данных и Recordset , представляющий набор записей, полученный от источника. Сначала необходимо открыть соединение, потом к нему привязать Recordset, потом, пользуясь методами Recordset’а, обрабатывать данные. Вот пример:

Если команда SQL не возвращает данных, recordset не нужен, надо пользоваться методом Conn. Execute (SQL_COMMAND).

Если Вы хотите вызывать хранимые процедуры сервера БД с параметрами, нужно воспользоваться объектом Command , который в свою очеред содержит объекты Parameter .

Методики программирования, советы


Описание переменных

VBScript — очень нетребовательный к программисту язык. Так он не требует описывать переменные и не содержит явных типов данных. Все переменные принадлежат одному типу Variant . Из-за отсутствия описаний могут произойти очень трудно обнаруживаемые ошибки. Одна опечатка может стоить полдня поисков.

Однако, есть возможность явно потребовать описания переменных. Для этого первой строкой в ASP-файле нужно написать Option Explicit . После этого обращение к переменной, которая не была объявлена с помощью Dim , вызывает ошибку с указанием номера строки.

Кстати, где расположены описания Dim в процедуре — совершенно не важно. Они могут стоять как до использования переменной, так и после, и даже в цикле. Видимо они отрабатываются препроцессором. Явно задать тип переменной с помощью Dim Var as Typ , как в Visual Basic, все равно нельзя.

Чередование ASP/HTML

Если нужно выдать большой кусок HTML, можно не пользоваться Response.Write. Если в asp-файле встречается кусок текста вне скобок , он трактуется просто как HTML, который надо вывести. Пример:

Обработка ошибок

Для отслеживания ошибок используется специальный объект Err . Он устанавливается в ненулевое значение, если предыдущая команда породила ошибку. Ее можно проверять с помощью If, и таким образом реагировать на ошибки. Чтобы из-за ошибки не прерывалось выполнение программы, в начале нужно включить команду

Включение других файлов

Можно выносить повторяющийся код в отдельный файл, и подключать к разным другим по мере необходимости с помощью команды include . Это очень удобно, если вы хотите вынести повторяющийся код в отдельный файл и использовать снова и снова в разных страницах:

Важно: все includes в тексте отрабатываются до исполнения файла. Т.е. даже если include стоит внутри if, то сначала будут включены все includes во всех ветках, и только потом, во время исполнения, будет принятно решение, какую ветку выполнять. Т.е. следующий код не дает условного включения файлов:

Обработка форм

Если надо что-то спросить у пользователя и на основании этого что-то сделать, в простейшем случае создается два файла: один с формой, второй – с ее обработчиком. Обработчик выполняет все действия. Пример:

Рекурсивная обработка форм

Удобный метод состоит в том, чтобы сбор данных и обработку осуществлял один и тот же файл. Для этого пишется asp, в котором есть разные разделы. Специальная переменная отвечает за выбор раздела при запуске. Пример:

Переменные HTTP

Запрос от браузера, кроме запрашиваемой страницы несет еще некоторые данные. Эти данные, например, IP-адрес клиента, доступны через специальные переменные объекта Request. IP-адрес – Request(«REMOTE_ADDR»). Другие — см.документацию (ASPSamp\Samples\srvvar.asp).

Переадресация

Очень легко написать на ASP скрипт, который будет производить некоторые расчеты, и в зависимости от результатов переадресовывать браузер на разные URL (например, подставлять нужный баннер). Делается это так:

Только надо следить, чтобы до выполнения команды redirect ничего не было записано в Response (даже коментарии HTML).

Электронная почта

Одна из часто встречающихся задач – отправить электронную почту с Web-страницы. На первый взгляд, можно просто написать

Но это приводит к тому, что при отправке формы делается попытка на клиентской машине запустить почтовую программу и создать новое сообщение с данными формы. Если это не получается (почтовая программа не настроена, пользователь не отправил почту, и т.д.) — письмо и не будет отправлено. Гораздо надежнее работает серверное решение.

Для этого существуют внешние компоненты, есть и бесплатные. Например, компонента Jmail от Dimac. Все, что для нее нужно – это адрес SMTP-сервера. Вот пример ее использования:

ASP — Доступ к источнику данных

Объекты ADO (ActiveX Data Objects) представляют собой простую, но мощную технологию предоставления доступа к базам данных с веб-страниц. Объекты ADO позволяют писать компактные и расширяемые сценарии для подключения к совместимым с интерфейсом OLE DB источникам данных, например, базам данных, электронным таблицам, последовательным файлам данных или каталогам электронной почты. OLE DB представляет собой программный интерфейс системного уровня, который предоставляет стандартный набор интерфейсов COM для обеспечения работы системы управления данными. С помощью модели объектов ADO нетрудно получить доступ к этим интерфейсам (с помощью языков сценариев, таких как VBScript или JScript) для добавления в свои веб-приложения работы с базами данных. Кроме того, можно использовать интерфейс ADO для доступа к базам данных, совместимым со стандартом ODBC (Open Database Connectivity).

Для тех, кто имеет представление о современных средствах подключения к базам данных, синтаксис команд ADO является несложным и удобным для применения. Для опытного разработчика интерфейс ADO предоставляет расширяемый, быстродействующий доступ к разным источникам данных.

Для получения дополнительных сведений об интерфейсе ADO посетите веб-узел UDA (Microsoft Universal Data Access) по адресу http://www.microsoft.com/data/.

Создание строки подключения

Первый шаг по созданию веб-приложения с доступом к данным состоит в указании способа, с помощью которого интерфейс ADO находит и задает источник данных. Это выполняется с помощью строки подключения, — набора разделенных точкой с запятой аргументов, определяющих такие параметры, как поставщик данных и размещение источника данных. Интерфейс ADO использует строку подключения для задания поставщика OLE DB и направляет этого поставщика на источник данных. Поставщик данных является компонентом, который представляет источник данных, а также предоставляет сведения для приложения в форме наборов строк.

В следующей таблице приведены строки подключения OLE DB для нескольких общих источников данных:

Источник данных (Data Source) Строка подключения OLE DB
Microsoft® Access Prov >
Microsoft SQL Server Prov >
Oracle Prov >
Microsoft Indexing Service Prov >

Для обеспечения обратной совместимости поставщик данных OLE DB для ODBC поддерживает синтаксис строк подключения ODBC. В следующей таблице содержатся типичные строки подключения ODBC:

Драйвер источника данных (Data Source Driver) Строка подключения ODBC
Microsoft Access Driver=;DBQ=физический путь к файлу .mdb
SQL Server DRIVER=;SERVER=путь к серверу
Oracle DRIVER=;SERVER=путь к серверу
Microsoft Excel Driver=;DBQ=физический путь к файлу .xls; Driver >
Microsoft Excel 97 Driver=;DBQ=физический путь к файлу .xls;Driver >
Paradox Driver=;DBQ=физический путь к файлу .db;Driver >
Текст Driver=;DefaultDir=физический путь к файлу .txt
Microsoft Visual FoxPro® (с контейнером баз данных) Driver=;SourceType=DBC;SourceDb=физический путь к файлу .dbc
Microsoft Visual FoxPro (без контейнера баз данных) Driver=;SourceType=DBC;SourceDb=физический путь к файлу .dbf

Примечание. Для строк подключения, которые используют путь в формате UNC для ссылки на источник данных, расположенный на удаленном компьютере, могут возникнуть неполадки, связанные с безопасностью. Чтобы предотвратить несанкционированный доступ к вашему источнику данных, создайте учетную запись Windows для компьютеров, которым требуется доступ к этим данным, а затем примените соответствующие разрешения NTFS к источнику данных. Для получения дополнительных сведений см. раздел Защита файлов средствами NTFS.

Дополнительные вопросы разработки веб-приложений с доступом к данным

Чтобы при обслуживании веб-приложений, доступ к данным которых одновременно осуществляют более 10 пользователей, обеспечить высокое быстродействие и надежность работы, настоятельно рекомендуем использовать обработчик баз данных типа «клиент-сервер». Хотя интерфейс ADO работает с любым источником данных, совместимым со стандартом OLE DB, он был разработан и лучше всего проверен для работы с базами данных типа «клиент-сервер», такими как Microsoft SQL Server или Oracle.

Страницы ASP поддерживают в качестве допустимых источников данных базы данных с общими файлами (Microsoft Access или Microsoft FoxPro). Хотя некоторые примеры в документации ASP используют базу данных с общим файлом, желательно использовать обработчики таких типов баз данных только для средств разработки или для ограниченных сценариев развертывания. Базы данных с общими файлами могут хуже подходить для профессионально разработанных веб-приложений, которые должны обслуживать большое число запросов, по сравнению с базами данных типа «клиент-сервер».

При разработке ASP-приложения с доступом к базам данных, предназначенного для подключения к удаленной базе данных на SQL Server, следует иметь представление о приведенных ниже вопросах.

  • Выбор схемы подключения для SQL Server. Имеется возможность выбрать один из двух методов доступа к удаленной базе данных SQL Server: соединители TCP/IP и именованные каналы. Для именованных каналов проверка подлинности клиентов баз данных должна выполняться с помощью Windows перед установкой подключения. При этом имеется возможность, что удаленный компьютер, на котором запущены именованные каналы, откажет в доступе пользователю, имеющему необходимые учетные сведения для доступа к SQL Server, но не имеющему учетной записи пользователя Windows на данном компьютере. Напротив, подключения с помощью соединителей TCP/IP напрямую соединяются с сервером баз данных, без использования промежуточного компьютера, как при использовании именованных каналов. И поскольку подключения, выполненные с помощью соединителей TCP/IP соединяются напрямую с сервером баз данных, пользователи могут получить доступ через проверку подлинности SQL Server, а не через проверку подлинности Windows.
  • Ошибка ODBC 80004005. Если схема подключения для доступа к SQL Server задана неправильно, пользователи, просматривающие приложение с доступом к базам данных, могут получить сообщение об ошибке ODBC 80004005. Для исправления ситуации попробуйте использовать вместо сетевых подключений локальные подключения через именованный канал, если SQL Server запущен на том же компьютере, что и службы IIS. Правила безопасности Windows 2000 не будут использованы, поскольку канал является локальным, а не сетевым подключением, которое может олицетворяться с помощью учетной записи анонимного пользователя. Крое того, в строке подключения к SQL Server (либо в файле Global.asa, либо в сценарии страничного уровня) измените параметр SERVER=имя сервера на SERVER=(local). Ключевое слово (local) является специальным параметром, распознаваемым ODBC драйвером SQL Server. Если это решение не работает, попробуйте использовать протокол без проверки подлинности для связи между IIS и SQL Server, например соединители TCP/IP. Этот протокол будет работать при локальном запуске SQL Server или на удаленном компьютере.

Примечание. Для увеличения быстродействия при подключении к удаленным базам данных воспользуйтесь соединителями TCP/IP.

  • Безопасность SQL Server. При использовании встроенных или смешанных средств безопасности SQL Server и при размещении базы данных SQL Server на удаленном сервере невозможно использование встроенной проверки подлинности Windows. Специфика заключается в том, что невозможно пересылать учетные сведения для встроенной проверки подлинности Windows на удаленный компьютер. Это означает, что может потребоваться использовать обычную проверку подлинности, при которой требуется ввод имени пользователя и пароля.
  • Для получения дополнительных сведений по этим вопросам посетите веб-узел Microsoft Product Support Services по адресу http://www.microsoft.com/support/.

    Подключение к источнику данных

    Интерфейс ADO предоставляет объект Connection для установления и обработки связей между приложением и совместимыми со стандартом OLE DB источниками данных или совместимыми со стандартом ODBC базами данных. Объект Connection имеет свойства и методы, которые можно использовать для открытия и закрытия подключений к базам данных, а также для выполнения запросов на обновление данных.

    Чтобы установить подключение к базе данных, необходимо сначала создать экземпляр объекта Connection. Например, следующий сценарий создает экземпляр объекта Connection и открывает подключение:

    Примечание. Строка подключения не содержит пробелы перед или после знака равено (=).

    В этом случае для объекта Connection строку подключения указывает метод Open.

    Выполнение SQL-запросов с помощью объекта Connection

    С помощью метода Execute объекта Connection можно выдавать команды для источников данных, например SQL-запросы (Structured Query Language). (Язык SQL является стандартным языком, используемым для связи с базами данных, и определяет команды для получения и обновления данных.) Метод Execute может принимать параметры, задающие команду (или запрос), число обрабатываемых записей данных и тип используемой команды.

    Следующий сценарий использует метод Execute для выдачи запроса в форме SQL-команды INSERT, которая вставляет данные в определенную таблицу базы данных. В данном случае блок сценария вставляет имя Jose Lugo в таблицу базы данных с именем Customers.

    Следует отметить, что два указанных в инструкции параметра используются для выполнения запроса: adCmdText и adExecuteNoRecords. Необязательный параметр adCmdText задает тип команды, указывая, что поставщик должен использовать инструкцию запроса (в данном случае, SQL-запрос) в качестве текстового определения команды. Параметр adExecuteNoRecords указывает ADO не создавать набор записей данных, если в приложение не возвращаются результаты. Это параметр работает только с типами команд, определенными в текстовом виде, например с SQL-запросами или сохраненными процедурами баз данных. Хотя параметры adCmdText и adExecuteNoRecords являются необязательными, следует указывать эти параметры при использовании метода Execute для повышения быстродействия приложения с доступом к данным.

    Важно! Параметры ADO, такие как adCmdText, должны быть определены перед их использованием в сценарии. Удобный способ определения параметров состоит в использовании библиотеки типов компонентов, которая представляет собой файл, содержащий определения для всех параметров ADO. Для применения такой библиотеки необходимо сначала описать ее. Чтобы определить библиотеку типов ADO, добавьте следующий тег в свой файл .asp или файл Global.asa:

    Дополнительные сведения о применении библиотек типов компонентов см. в подразделе Использование констант раздела Использование переменных и констант.

    В дополнение к команде SQL INSERT можно использовать команды SQL UPDATE и DELETE для изменения и удаления информации в базе данных.

    С помощью команды SQL UPDATE можно изменить значения элементов в таблице базы данных. Приведенный ниже сценарий использует команду UPDATE для изменения значения поля FirstName в таблице Customers на Jeff для всех записей, в которых поле LastName содержит фамилию Smith .

    Чтобы удалить определенные записи из таблицы базы данных, используйте команду SQL DELETE. Приведенный ниже сценарий удаляет из таблицы Customers все строки, в которых фамилия равна Smith :

    Примечание. Следует быть очень внимательным при использовании команды SQL DELETE. Команда DELETE без сопутствующего предложения WHERE удалит все строки из таблицы. Проверьте наличие предложения SQL WHERE, которое указывает конкретные удаляемые строки.

    Использование объекта Recordset для обработки результатов

    Для извлечения данных, проверки результатов и внесения изменений в базу данных ADO предоставляет объект Recordset. Как подразумевает его имя, объект Recordset имеет возможности, которые можно использовать (в зависимости от ограничений запроса) для извлечения и отображения набора строк базы данных, или записей. Объект Recordset поддерживает положение каждой записи, возвращенной запросом, предоставляя возможность просматривать результаты по одному элементу.

    Извлечение набора записей

    Успешно выполняемые веб-приложения используют объект Connection для установления соединения и объект Recordset для обработки возвращенных данных. Комбинируя специализированные функции обоих объектов, можно разработать приложение для работы с базой данных, выполняющее практически любую задачу обработки. Например, приведенный ниже сценарий на стороне сервера использует объект Recordset для выполнения команды SQL SELECT. Команда SELECT извлекает определенный набор информации на основании ограничений, налагаемых запросом. Запрос также содержит предложение SQL WHERE, используемое для сужения результатов запроса заданным условием. В данном примере предложение WHERE ограничивает запрос всеми записями в таблице Customers базы данных, имеющими фамилию Smith.

    Обратите внимание, что в предыдущем примере объект Connection устанавливает подключение к базе данных, а объект Recordset использует то же самое подключение для извлечения результатов из базы данных. Данный метод является предпочтительным, если необходимо точно настроить способ установления соединения с базой данных. Например, если необходимо указать время задержки перед прекращением попыток подключения, необходимо использовать объект Connection для установки этого свойства. Однако если нужно просто установить соединение с помощью свойств соединения ADO, заданных по умолчанию, для установления соединения можно использовать метод Open объекта Recordset:

    Если подключение устанавливается с помощью метода Open объекта Recordset, неявно используется объект Connection для обеспечения безопасности соединения. Дополнительные сведения см. в документации Microsoft ActiveX Data Objects (ADO), доступной на веб-узле Microsoft Universal Data Access по адресу http://www.microsoft.com/data/.

    Примечание. Чтобы существенно повысить быстродействие приложений ASP, работающих с базами данных, предусмотрите кэширование набора данных в состоянии Application. Дополнительные сведения см. в разделе Кэширование данных.


    Часто бывает полезно считать число записей, возвращаемых в наборе записей. Метод Open объекта Recordset позволяет указать необязательный параметр cursor, определяющий способ извлечения и перемещения по набору записей. Добавляя параметр курсора adOpenKeyset к инструкции, выполняющей запрос, клиентскому приложению предоставляется возможность полного просмотра набора записей. В результате, приложение может использовать свойство RecordCount для точного подсчета числа записей в наборе записей. См. приведенный ниже пример:

    Усовершенствование запросов с помощью объекта Command

    С помощью объекта ADO Command можно выполнять запросы таким же образом, как и с помощью объектов Connection и Recordset, за исключением того, что объект Command позволяет подготавливать, или компилировать, запрос к источнику данных и затем многократно выполнять запрос с разными наборами значений. Преимущества компиляции запросов состоит в том, что это позволяет существенно уменьшить время для внесения изменений в существующий запрос. Кроме того, можно оставить SQL-запросы частично неопределенными, предоставляя возможность изменения частей запросов непосредственно перед выполнением.

    Семейство Parameters объекта Command избавляет от необходимости восстанавливать запрос при каждом его вызове. Например, если необходимо регулярно обновлять информацию о поставках и стоимости в складской системе, использующей веб-технологию, можно определить запрос в следующем виде:

    Важно! Параметры ADO, например adCmdText, являются просто переменными, это означает, что перед использованием параметра ADO в сценарии, осуществляющем доступ к данным, необходимо определить его значение. Поскольку ADO использует большое число параметров, наиболее простым способ определения параметров является использование библиотеки типов компонента — файла, содержащего описание каждого параметра и каждой константы ADO. Дополнительные сведения о применении библиотеки типов ADO см. в подразделе Использование констант раздела Использование переменных и констант.

    В приведенном выше примере следует обратить внимание, что сценарий многократно создает и выполняет SQL-запрос с разными значениями, не переопределяя и повторно не отправляя запрос к базе данных источника. Компиляция запросов с помощью объекта Command также обеспечивает отсутствие проблем, связанных со сцеплением строк и переменных для формирования запросов SQL. В частности, с помощью семейства Parameter объекта Command можно избежать проблем, связанных с определением конкретных типов строковых переменных и переменных, хранящих дату и время. Например, запрос SQL, содержащий апостроф (‘), может вызвать сбой запроса:

    Обратите внимание, что фамилия O’Hara содержит апостроф, который вступает в конфликт с апострофами, используемыми как ограничители данных в ключевом слове SQL VALUES. Привязав значение строки запроса к параметру объекта Command, можно избежать проблем этого типа.

    Объединение форм HTML и доступа к базе данных

    Веб-страницы, содержащие формы HTML, могут позволять пользователям запрашивать базу данных в удаленном режиме и извлекать определенные сведения. С помощью ADO можно создать удивительно простые сценарии, которые собирают информацию из пользовательских форм, создают настраиваемый запрос к базе данных и возвращают информацию пользователю. Используя объект ASP Request, можно извлечь информацию, введенную в форму HTML, и включить эти сведения в предложения SQL. Например, приведенный ниже фрагмент сценария вставляет сведения, предоставляемые формой HTML, в таблицу. Сценарий собирает сведения от пользователей с помощью семейства Form объекта Request.

    Дополнительные сведения о формах и использовании объекта ASP Request см. в разделе Обработка сведений, введенных пользователем.

    Управление подключениями к базам данных

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

    Превышение времени ожидания подключения

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

    Свойство ConnectionTimeout объекта Connection позволяет ограничить время, которое приложение ожидает перед завершением попытки соединения и выдачей сообщения об ошибке. Например, приведенный ниже сценарий устанавливает свойство ConnectionTimeout для ожидания в течение 20 секунд перед отменой попытки соединения:

    Значение свойства ConnectionTimeout, устанавливаемое по умолчанию, равно 30 секундам.

    Примечание. До применения свойства ConnectionTimeout в приложении убедитесь в том, что источник данных и поставщик подключений поддерживают это свойство.

    Группировка подключений

    Группировка подключений позволяет веб-приложению использовать подключения из группы — набора свободных подключений, которые не нужно устанавливать заново. После того как подключение будет создано и помещено в группу, приложение сможет повторно использовать его, не выполняя каждый раз процесс установления подключения. Это может дать значительный выигрыш в производительности, особенно если приложение подключается по сети или часто подключается и отключается. Кроме того, помещенные в группу подключения могут использоваться несколькими различными приложениями.

    Группировка сеансов OLE DB

    OLE DB имеет средство группировки, называемое группировкой сеансов, оптимизированное для повышения производительности подключения при работе с большими веб-приложениями баз данных. Группировка сеанса сохраняет безопасность подключения и другие свойства. Подключение из группы используется только в том случае, если с обоих концов подключения поступают совпадающие запросы. По умолчанию поставщики OLE DB для Microsoft SQL Server и Oracle поддерживают группировку сеансов. Это означает, что вам не нужно специально настраивать свое приложение, сервер или базу данных для использования группировки сеансов. Если поставщик не поддерживает по умолчанию группировку сеансов, то для ее включения нужно будет создать параметр реестра. Дополнительные сведения о группировке сеансов см. в документации по OLE DB 2.0 Software Development Kit (SDK).

    Группировка подключений ODBC

    Чтобы драйвер ODBC мог использовать группировку подключений, нужно настроить драйвер используемой базы данных и задать в реестре Windows значение для его свойства CPTimeout . Свойство CPTimeout определяет длительность интервала времени, в течение которого подключение остается в группе подключений. Если время нахождения подключения в группе начинает превышать значение, указанное в свойстве CPTimeout, то подключение закрывается и удаляется из группы. По умолчанию свойство CPTimeout имеет значение 60 секунд.

    Можно настроить свойство CPTimeout для группировки подключений для драйвера определенной базы данных ODBC, создав следующий параметр реестра:

    Например, следующий параметр задает время ожидания 180 секунд (3 минуты) для драйвера SQL Server.

    Примечание. По умолчанию веб-сервер включает группировку подключений для SQL Server, устанавливая свойство CPTimeout в значение 60.

    Использование подключения несколькими страницами

    Хотя и можно повторно использовать подключение на нескольких страницах, сохраняя подключение в ASP-объекте Application, это может привести к сохранению ненужного подключения в открытом состоянии и к потере преимуществ от использования группировки подключения. Если имеется много пользователей, которым требуется подключение к одному и тому же ASP-приложению с доступом к базам данных, лучшим подходом повторного использования строки подключения к базе данных на нескольких веб-страницах, является роазмещение этой строки в ASP-объекте Application. Например, можно задать строку подключения в файле Global.asa в связанной с событием процедуре Application_OnStart, как это сделано в следующем сценарии:

    Затем в каждом ASP-файле, обращающемся к этой базе данных, следует написать

    для создания экземпляра объекта Connection для этой страницы, а воспользоваться сценарием

    для открытия подключения. В конце страницы закройте подключение с помощью строки

    В случае отдельного пользователя, которому требуется повторно использовать подключение на нескольких веб-страницах, возможно, более удобным для хранения строки подключения является использование объекта Session, а не объекта Application .

    Закрытие подключений

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

    Чтобы явно закрыть подключение объекта Connection к базе данных, можно воспользоваться методом Close объекта Connection. Следующий сценарий открывает и закрывает подключение:

    IT-ЗАМЕТКИ

    Инструменты пользователя

    Инструменты сайта

    Содержание

    Элементы управления источниками данных включают любые элементы управления, реализующие интерфейс IDataSource. Среда .NET Framework поддерживает следующие элементы управления источниками данных.

    Все элементы управления источниками данных можно найти на вкладке Data (Данные) панели инструментов в Visual Studio.

    SqlDataSource

    SqlDataSource представляет подключение к базе данных, использующее поставщика ADO.NET.

    Источник данных выбирается установкой имени поставщика. Вот SqlDataSource для подключения к базе данных SQL Server:

    Следующий шаг предполагает применение требуемой строки соединения — без нее установка соединения невозможна.

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

    Извлечение записей

    Каждый созданный элемент управления SqlDataSource можно использовать для выполнения одного запроса. Дополнительно можно также добавить соответствующие команды для удаления, вставки и обновления строк.

    Теперь необходимо у связующего элемента вызвать свойства DataSourcelD и передать туда ID нашего SqlDataSource.
    Потом установите ListBox.DataTextField в столбец, который должен отображаться (в этом случае EmployeelD).

    Параметризованные команды

    Трюк состоит в том, что запрос записан с использованием параметра. Параметры всегда отмечаются символом @, в рассматриваемом случае это @City. Определить можно столько параметров, сколько необходимо, но каждый должен быть отображен на отдельное значение. В этом примере значение параметра @City выбирается из свойства IstCities.SelectedValue.

    Дополнительные сведения о типах параметров

    Источник Управляющий дескриптор Описание
    Свойство элемента управления Свойство другого элемента управления на странице
    Строковое значение запроса Значение из текущей строки запроса
    Значение состояния сеанса Значение, сохраненное в текущем сеансе пользователя
    Значение cookie-набора Значение из любого cookie-набора, присоединенного к текущему запросу.
    Значение профиля Значение из текущего пользовательского профиля
    Переменная формы Значение, отправленное странице от элемента управления вводом.
    Значение маршрута Значение из маршрутизированного URL

    Иногда может понадобиться модифицировать значение параметра перед его использованием.
    В SqlDataSource имеется ряд событий, специально предусмотренных для этой. Например, реагируя на событие Selecting, можно заполнить параметры для операции выбора. Аналогично можно использовать события Updating, Deleting и Inserting при обновлении, удалении и вставке записи. В обработчиках этих событий через свойство SqlDataSourceSelectingEventArgs.Command имеется доступ к команде, которая должна быть выполнена, и ее можно модифицировать вручную.

    Обратите внимание, что для обращения к параметру в коллекции Parameters перед его именем должен быть добавлен символ @.

    Обработка ошибок

    Чтобы сделать это, необходимо обработать событие источника данных, которое происходит немедленно после ошибки. Если выполняется запрос, то это будет событие Selected. Если же выполняется операция обновления, удаления или вставки, то понадобится обработать события Updated, Deleted или Inserted. (Если вы не хотите предоставлять настраиваемые сообщения об ошибках, можно обработать все эти события в одном обработчике.)

    В обработчике ошибок можно получить доступ к объекту исключения через свойство SqlDataSourceStatusEventArgs.Exception.

    Чтобы предотвратить дальнейшее распространение ошибки, просто установите значение свойства SqlDataSourceStatusEventArgs.ExceptionHandled в true. Затем отобразите на веб-странице соответствующее сообщение об ошибке, чтобы проинформировать пользователя о том, что команда не была завершена.

    Обновление записей

    Извлечение данных — это только полдела. SqlDataSource также может применять изменения. Единственная ловушка в том, что не все элементы управления поддерживают обновление. Так, например, простой ListBox не предоставляет никакой возможности пользователю редактировать значения, удалять существующие элементы или вставлять новые.

    Команды InsertCommand, DeleteCommand и UpdateCommand определяются таким же образом, как команда для свойства SelectCommnad — с использованием параметризованного запроса или вызова хранимой процедуры.

    Например, вот как выглядит элемент SqlDataSource, который определяет базовую команду обновления каждого столбца:

    Чтобы разрешить редактирование, установите свойство GridView.AutoGenerateEditButton в true. Слева в экранной таблице появится новый столбец. GridView использует этот столбец для отображения ссылок для управления процессом редактирования.

    Можно создать аналогичные параметризованные команды для DeleteCommand и InsertCommand. Чтобы разрешить удаление и вставку, вы должны добавить столбец к Gr >

    Строгая проверка параллелизма

    Для противостояния такого рода проблемам можно реализовать строгую проверку параллелизма. Один из способов сделать это — создать команду, которая выполняет обновление, только если каждое полей совпадает, используя более подробную конструкцию WHERE.

    Для начала необходимо сообщить SqlDataSource о том, что нужен доступ к исходным значениям, установив свойство SqlDataSource .Conf lictDetection в Conf lie tOpt ions. Compare Al lvalues вместо Conf lie tOpt ions. Over writeChanges (принятого по умолчанию).

    Второй шаг состоит в том, чтобы сообщить SqlDataSource, как следует именовать параметры, хранящие исходные значения. По умолчанию исходные значения получают те же имена параметров, что и измененные значения. Фактически они переопределяют исходные значения параметров. Чтобы предотвратить такое поведение, необходимо установить свойство SqlDataSource.OldValuesParameterFormatString. Это свойство принимает строку, содержащую заполнитель <0>, где <0>указывает на имя исходного параметра. Например, если вы установите OldValuesParameterFormatString в original! 0> (как это часто делается), то параметры, хранящие исходные значения, получат префикс original_. Например, @FirstName станет @original _ FirstName, a @LastName — @original_LastName, как в команде обновления, показанной выше. Зная эти детали, вы можете создать полностью сконфигурированный SqlDataSource, который реализует этот прием:

    Недостатки SqlDataSource

    Сопровождение больших приложений. Каждая страница, которая обращается к базе данных, нуждается в собственном наборе элементов управления SqlDataSource. Это может превратить задачу поддержки в настоящий кошмар, особенно если есть несколько страниц, использующих один и тот же запрос (и каждая из них требует дублирующего экземпляра SqlDataSource). В основанном на компонентах приложении вы будете использовать более высокоуровневую модель. Веб-страницы будут взаимодействовать с библиотекой доступа к данным, которая содержит все детали, касающиеся базы данных.

    Недостаток гибкости. Каждая задача доступа к данным требует отдельного элемента SqlDataSource. Если вы хотите предоставить пользователю несколько способов просмотра запрошенных данных, то это может просто «утопить» страницу в объектах доступа к данным — по одному для каждого варианта команды. В таком случае страница быстро усложниться.

    Неприменимость для других задач. SqlDataSource не может правильно представлять некоторые типы задач. Элемент SqlDataSource предназначен для сценариев отображения и редактирования данных. Однако эта модель не работает, если нужно подключаться к базе данных и выполнять другую задачу, такую как размещение запроса на поставку в канале заказов или протоколирование событий. В ситуациях подобного рода потребуется разрабатывать собственный код обращения к базе данных. Применение единой библиотеки доступа к базе, инкапсулирующей такие задачи вместе с операциями извлечения и обновления данных, упростит приложение.

    ObjectDataSource

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

    Извлечение записей

    Интерфейс компонента

    В ObjectDataSource определены свойства SelectMethod, DeleteMethod,UpdateMethod и InsertMethod, используемые для связывания класса доступа к данным с различными задачами. Каждое свойство принимает имя метода класса доступа к данным. В рассматриваемом примере нужно просто разрешить извлечение данных, для чего установить значение свойства SelectMethod:

    GetEmployees() возвращает массив объектов EmployeeDetails. Эти объекты отвечают критериям ObjectDataSource — они предоставляют все данные записи через общедоступные свойства.

    Вспомните, что класс EmployeeDB использует блоки обработки ошибок, чтобы обеспечить корректное закрытие соединений, но он не перехватывает исключений. (Наилучшая практика проектирования состоит в том, чтобы позволить исключениям уведомлять веб-страницу, которая затем может решить, как лучше всего информировать пользователя.) Ошибки, связанные с ObjectDataSource, можно обработать таким же образом, как это делалось в случае SqlDataSource: во-первых, обработать события Selected, Inserted, Updated и Deleted; во-вторых, проверить на наличие исключений и, в-третьих, пометить их как обработанные.

    Использование параметров методов

    Ранее уже было показано, как использовать SqlDataSource для выполнения параметризованных команд. То же самое возможно с Ob jectDataSource, если предоставить подходящий метод выборки, принимающий один или более параметров. Затем каждый параметр можно отобразить на значение из элемента управления, строковый аргумент запроса и т.п.

    Чтобы попробовать это, можете воспользоваться методом EmployeeDB.GetEmployee(), извлекающим запись об отдельном сотруднике по идентификационному номеру. Вот объявление этого метода:

    Имя, определенное для параметра, в точности должно соответствовать имени параметра, использованному в методе. Когда ObjectDataSource вызывает этот метод, он применяет рефлексию для его анализа и проверяет имена параметров, чтобы определить порядок аргументов. Эта система позволяет перегружать методы, поскольку ObjectDataSource в состоянии корректно идентифицировать перегрузку, которую вы хотите использовать, на основе количества переданных параметров и их имен.

    Обновление записей

    Элемент ObjectDataSource предоставляет того же рода привязку обновляемых данных, что и SqlDataSource. Первый шаг связан с указанием метода UpdateMethod, который должен быть общедоступным методом экземпляра того же класса:

    Сложность связана с обеспечением правильной сигнатуры для метода UpdateMethod. Предположим, что вы создаете экранную таблицу, которая отображает список объектов EmployeeDetails. Вы добавляете столбец со ссылками редактирования. Когда пользователь фиксирует изменения, GridView заполняет коллекцию ObjectDataSource.UpdateParameters — по одному параметру для каждого свойства класса EmployeeDetails, включая E’mployeelD, FirstName, LastName и TitleOfCourtesy. Затем ObjectDataSource ищет метод по имени UpdateEmployeeO в классе EmployeeDB. Этот метод должен иметь те же параметры с теми же именами. Это значит, что приведенный ниже метод подходит:

    А следующий метод не подходит, потому что имена не совпадают в точности:

    Показанный далее метод также не подходит, т.к. имеет дополнительный параметр:

    Алгоритм сравнения метода не учитывает регистр и не рассматривает порядок или типы параметров. Он просто пытается найти метод с правильным количеством параметров и теми же именами. До тех пор, пока такой метод присутствует, обновление может быть выполнено автоматически, без какого-либо дополнительного кода.

    Обновление с помощью объекта данных

    Одна проблема, связанная с методом UpdateEmployee (), показанным в предыдущем примере, заключается в том, что его сигнатура несколько неуклюжа — требуется один параметр для каждого свойства объекта. Глядя на определение класса EmployeeDetails. имело бы смысл создать UpdateEmployeeO, который бы использовал его и получал всю необходимую информацию из объекта EmployeeDetails. Вот пример:

    ObjectDataSource поддерживает такой подход. Однако чтобы применить его, необходимо установить в DataObjectTypeName полное имя класса, который должен использоваться. Ниже показано как это работает:

    . Часть 1

    Интерфейс к базе данных с помощью ASP

    Постановка задачи

    Предположим, перед нами стоит задача создания газетного сайта, причем некоторые из его читателей должны иметь право пополнять его новыми статьями, снабжаемыми фотографиями непосредственно с самого сайта и без программирования. Предположим также, что такой сайт должен иметь возможности удаления статей, их поиска, а также сортировки. С первого взгляда может показаться, что решение такой задачи не под силу начинающему программисту ASP, однако, как вы скоро увидите, это далеко не так.

    Для начала давайте все-таки разберемся, что же от нас требуется. По сути, необходимо создать базу данных всех статей, подготовить несколько HTML-форм для загрузки статей на сервер, их поиска, сортировки, удаления и, наконец, отображения результата.

    Я почти уверен, что подобная задача актуальна применительно практически к любому сайту, тем более что подобным образом (разве что без возможностей поиска, сортировки и удаления) работает большинство гостевых книг (guestbook).

    Что нам понадобится

    Для реализации вышеизложенной задачи нам потребуется персональный компьютер с Microsoft Windows NT или Windows 2000 (можно и Workstation, и Server), установленный IIS (Internet Information Server), какой-нибудь HTML-редактор (советую использовать Macromedia Dreamweaver), Microsoft Access (версии 95, 97 или 2000) и самый обычный текстовый редактор.

    Создание и подготовка базы данных

    Прежде всего создадим базу данных статей, для чего:

    • запустим приложение Microsoft Access;
    • любым из известных способов создадим новую базу данных. Назовем ее «Articles»;
    • в созданной базе данных создадим таблицу с именем, например «Articles»;
    • пользуясь инструментом «Конструктор», определим поля нашей таблицы и типы принимаемых ими значений (рис. 1);
    • заполним таблицу несколькими статьями в соответствии с созданными полями (рис. 2);
    • сохраним базу данных в файле «ArticlesDB.mdb».

    Далее необходимо прописать нашу базу данных в соответствующем разделе источников данных системы, для этого:

    • запустим программу-конфигуратор источников данных (Data Sources ODBC) — Start->Settings->Control Panel->Administrative Tools->Data Sources ODBC;
    • перейдем во вкладку «System DSN» и создадим новый источник данных, нажав на «Add…»;
    • в появившемся списке драйверов выберем драйвер баз данных Microsoft Access — «Microsoft Access Driver (*.mdb)» и нажмем на «Finish»;
    • в строке «Data Source Name» зададим имя нашей базы данных, например «Articles» (это то имя, по которому мы в дальнейшем будем обращаться к ней);
    • нажмем на «Select…», выберем подготовленный нами файл «ArticlesDB.mdb» и нажмем «OK».

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

    Оформляем главную страницу (index.asp)

    С ASP работать очень просто. Для этого надо всего лишь вставить текст скрипта ASP в пару тэгов . В остальном ASP-файл ничем не отличается от HTML-файла (за исключением, пожалуй, расширения). Комментарии в HTML, как известно, вставляются в пару тэгов , в ASP же закомментировать строку можно при помощи символа ‘ (апостроф) в ее начале.

    Теперь давайте разберемся. Во-первых, как вы наверняка заметили, ASP-код легко сочетается с HTML-тэгами; в этом его достоинство. Так, к примеру, строка Response.Write Link & «
    » отображает на экране браузера клиента подготовленное сервером значение переменной Link и HTML-тэг
    , то есть перевод строки. Особый интерес вызывает переменная rs. Для искушенных программистов сразу скажу — это указатель. Однако в ASP с целью облегчения работы начинающих указатели маскируются. Здесь не встретишь громоздких С’шных конструкций, типа «я знаю, что ты знаешь, что я знаю», или, выражаясь программистским языком, указатель на указатель… Однако сделано это так искусно, что гибкость программирования при этом не теряется, нет лишь прямой работы с указателями, а только работа с помощью специальных функций, скрывающих от программиста рутину и защищающих указатели от некорректных действий. Таким образом, выражение rs.Fields («Article»).value означает значение поля «Article» текущего значения указателя на элемент базы данных (в нашем случае статей) и содержит текст статьи, которая соответствует текущей позиции указателя на все статьи. Переход к следующему элементу базы (смещение указателя) выполняется с помощью инструкции Rs.MoveNext. В приведенном выше примере это не делается, а попросту формируется ссылка на текст статьи в виде ее названия и отображается комментарий самой первой статьи, соответствующей результату запроса. Давайте попробуем отобразить все статьи нашей базы данных на главной странице в виде HTML. И еще, обратите особое внимание на директиву:

    Она по сути формирует ссылку на файл, содержащий шаблон отображения самой статьи, причем передает идентификатор статьи ему в качестве параметра. Полностью файл шаблона приведен в приложении к настоящей статье, а механизм его работы может быть кратко представлен следующим образом:

    Первая строчка скрипта шаблона HTML присваивает переменной TheID значение, переданное ссылкой с использованием метода Request.QueryString. Далее открывается база данных, из которой читается статья (запись), соответствующая идентификатору, переданному из главного скрипта (index.asp).

    Создаем главную страницу

    Таким образом в таблицу в цикле будут добавляться ряды со ссылками на статьи и с аннотациями, пока не будут отображены все статьи из базы данных. Следует обратить внимание на переменную Cnt. По окончании цикла она будет содержать число обработанных статей (рядов таблицы).

    Язык структурированных запросов — SQL

    Настала пора разобраться с тем, что таится за строчками:

    По сути, именно за этими двумя строчками кроется работа с нашей базой данных: первая представляет собой текстовую строку с запросом к базе данных (текстовые строки в ASP записываются в двойных кавычках); вторая — содержит директиву выполнения этого запроса с одновременным присвоением результата переменной (указателю на записи в базе данных). В рамках настоящей статьи мы не будем рассматривать SQL (Structured Query Language) во всех деталях, а остановимся лишь на тех его операторах, без понимания которых дальнейшая работа будет невозможна. Для тех, кому этого покажется недостаточным, советую посетить отобранные мною сайты с детальной документацией по SQL.


    Для полноценной работы нам необходимо познакомиться с четырьмя операторами этого мощного языка, предназначенного специально для работы с базами данных.

    DELETE удаляет те ряды из «Имя Таблицы», которые удовлетворяют условию, определенному в «Определении», и возвращает число удаленных рядов. Если выполнить команду DELETE без условия WHERE, то все ряды указанной таблицы будут удалены. В этом случае DELETE возвратит 0. Ключевое слово LOW_PRIORITY откладывает выполнение операции DELETE до завершения работы чтения из таблицы других клиентов.

    SELECT используется для извлечения рядов (записей) из одной или более таблиц. Выражение_Select определяет столбцы таблицы, значения которых необходимо извлечь. Все ключевые поля должны быть заданы в строгой последовательности. К примеру, выражение HAVING должно следовать за любым выражением GROUP BY и до любого выражения ORDER BY.

    Выражение_Select можно заменить псевдонимом (alias) с помощью ключевого слова AS. Псевдоним используется в качестве идентификатора имени столбца и может быть использован наряду с ключевыми словами ORDER BY или HAVING.

    Выражение HAVING может относиться к любому столбцу или псевдониму в Выражении_Select. Оно применяется к запросу в последнюю очередь, непосредственно перед посылкой данных клиенту. SELECT . INTO OUTFILE ‘имя_файла’ заносит отобранные записи в файл. Файл создается непосредственно на сервере и не может «уже существовать» (одна из основных причин такого механизма заключается в предотвращении случайного «затирания» различных важных файлов).

    INSERT используется для добавления новых записей в существующую таблицу. Допустимо две формы использования INSERT.

    Первая форма — INSERT . VALUES — вставляет ряды на основании заданных значений. Вторая форма — INSERT . SELECT — вставляет ряды, выбранные из другой таблицы.

    Ключевое слово LOW_PRIORITY откладывает выполнение операции до завершения работы чтения из таблицы других клиентов. Ключевое слово IGNORE в команде INSERT позволяет избегать вставки повторяющихся строк (используется в сочетании с ключевыми словами PRIMARY или UNIQUE). Для второй формы INSERT INTO . SELECT операция не может содержать выражения ORDER BY. Таблица, в которую производится добавление записей, не может присутствовать в выражении FROM части SELECT запроса потому, что запрещено производить выделение из той же самой таблицы, в которую производится вставка.

    REPLACE служит для редактирования содержимого таблицы и работает в точности как INSERT, за исключением того, что если старая запись в таблице имеет то же значение, что и записываемая, то старая запись удаляется прежде, чем добавляется новая.

    UPDATE обновляет поля существующей таблицы новыми значениями. Выражение SET показывает, какие поля (столбцы) должны быть изменены, и значения, которые должны быть им присвоены. Выражение WHERE, если оно есть, указывает, какие ряды должны быть обновлены. В противном случае операция применяется ко всем рядам таблицы. Ключевое слово LOW_PRIORITY откладывает выполнение операции до завершения работы чтения из таблицы других клиентов. Выражения UPDATE выполняются слева направо.

    Обновляет значение поля Password в таблице WAPassword, записывая в поле, чей идентификатор ID равен 1 значение ‘passw’.

    Увеличивает значение поля counter таблицы Счетчик на 1.

    Удваивает поле age, а затем прибавляет 1 к его значению в таблице persondata.

    Что такое Global.asa

    Global.asa позволяет выполнять определенные скрипты в начале работы клиентской сессии или при инициализации IIS. Примером тому может служить простейший счетчик числа посещений сайта. Более того, допустимо использовать множественные файлы Global.asa. Однако следует помнить, что ASP-скрипт ищет самый близкий (расположенный в том же каталоге) файл Global.asa и использует именно его.

    По сути, этот файл может содержать четыре скрипта: первый будет выполняться при инициализации службы IIS/PWS (Application_OnStart), второй — при остановке службы IIS/PWS (Application_OnEnd) (обычно эти первые два скрипта отрабатывают в процессе перезагрузки компьютера), и еще два скрипта выполняются дополнительно при инициализации сессии пользователя (Session_OnStart) и по ее окончании (Session_OnEnd). Данная схема очень сильно напоминает пары «конструктор-деструктор». Неспроста всякая переменная, которая должна быть использована (например, в текущей сессии), может быть инициализирована в Session_OnStart с тем, чтобы быть использованной в процессе работы сессии, она же уничтожается (обнуляется) в Session_OnEnd.

    Global.asa не может содержать тэгов HTML. Недопустимо использование JavaScript. Не рекомендуется писать файл Global.asa с помощью каких-либо HTML-редакторов, для этого гораздо лучше использовать NotePad. И еще один совет: прежде чем вставлять скрипт в файл Global.asa, попробуйте его в работе в обычном ASP-файле.

    Пример файла Global.asa

    Добавляем новую статью (UploadForm.asp и Upload2DBS.asp)

    Теперь, когда мы разобрались с SQL, можно приступать к добавлению новой статьи, причем делать мы это будем прямо с сайта, а если быть точнее — непосредственно с HTML-формы. Для этого сначала создадим файл с самой формой и определим скрипт-реакцию на подтверждение (кнопку «Publish the article!»). (Предполагается, что читатель знаком с азами построения HTML-форм, поэтому мы рассмотрим этот процесс, не вдаваясь в детали построения форм.)

    Прежде всего следует уточнить задачу на этом этапе. Итак, очевидно следующее:

    • на загрузку статьи с сайта должен иметь право не каждый (следовательно, желательно предусмотреть пароль для доступа к этой функции);
    • у каждой статьи есть определенная тема (рубрика), причем она не может быть произвольной, а должна выбираться из списка;
    • список можно хранить непосредственно в HTML-файле и, каждый раз изменяя его, изменять сам файл. Это самый простой и быстрый способ;
    • однако для того, чтобы позволить динамически изменять и пополнять этот список, рекомендуется держать его в базе данных. Это позволит пользователям произвольным образом изменять его содержимое и не потребует переделки формы. Для простоты сначала рассмотрим вариант со встроенным («жестко прошитым») рубрикатором.

    Как видим, передача управления осуществляется благодаря директиве ACTION=»http://localhost/Upload2DBS.asp»> в тэге формы. Тем самым указывается скрипт-ответ на реакцию пользователя после нажатия на кнопку «Publish the article!». Теперь остановимся на селекторе рубрик. Как уже отмечалось, желательно перевести его содержимое в базу данных. Для этого в нашей базе данных (файл ArticlesDB.mdb) создадим новую таблицу с именем, к примеру «Topics», в которой с помощью конструктора определим всего одно поле — «Topic» типа «текст». Далее заполним эту таблицу произвольными значениями нашего рубрикатора и отсортируем полученный список в алфавитном порядке. После чего следует заменить тэг

    Теперь давайте разберемся с самой сутью дальнейшей работы. Что же должен делать наш скрипт-реакция?

    Во-первых, следует позаботиться о том, чтобы все обязательные поля (а они отмечены звездочкой) были введены. Наиболее правильным способом проверки этого является скрипт, написанный на любом языке описания скриптов (например, JavaScript), который будет проверять, введены ли значения обязательных полей. Для этого достаточно добавить в определение тэга формы параметр onsubmit=»preprocess();», где preprocess() — имя функции-скрипта, который и будет осуществлять проверку. Здесь как нельзя кстати видно преимущество языков описания сценариев (JavaScript, Jscript, VBScript) перед ASP. ASP выполняется на стороне сервера, а перегружать связь «клиент-сервер» простой проверкой типа «введены ли значения», согласитесь, неправильно. Однако специально в целях обучения мы будем делать это с помощью ASP.

    И еще. Прежде чем приступить к выполнению нашей задачи, следует сказать еще об одной небольшой проблеме: когда мы будем вставлять в ячейку базы данных текст, его форматирование (даже самое простое) не сохранится, и в дальнейшем его невозможно будет корректно отобразить на HTML-странице, поскольку поле Memo хранит неформатированную строку текста. Чтобы избежать этого, следует написать функцию, которая позволит производить примитивное HTML-форматирование введенного текста статьи, перед тем как записать его в базу данных. Другими словами, в самом примитивном случае (хотя бы для того, чтобы сохранить исходную разбивку на строки) функция должна вставлять символы конца строки там, где во входном потоке имеются символы переноса строк.

    Удаляем статью (RemoveForm.asp и Rem.asp)

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

    Особое внимание следует уделить первым двум строкам. Они получают значение глобальной переменной текущего сеанса (сессии) работы со значением идентификатора текущей статьи (в нашем случае удаляемой), которая была инициализирована (файл ArtTmp.htm) следующей строкой:

    Таким образом, в текущий скрипт передается в качестве параметра сеансовая переменная с идентификатором текущей статьи, которую необходимо удалить. Имеется в виду, что ссылка на удаление присутствует в странице с шаблоном (файл ArtTmp.htm) и удаляемая статья является текущей.

    Организуем поиск (SearchForm.asp и SearchDBS.asp)

    Как известно, без поиска навигация в сколь-нибудь солидной базе данных невозможна в принципе. Попробуем организовать поиск статьи по ее реквизитам, причем постараемся организовать булев (логический) поиск, соединяя отдельные значения критериев поиска с помощью логики «И/ИЛИ».

    Опять же не заостряя внимание на поисковой форме (файл SearchForm.asp), перейдем непосредственно к самому процессу поиска:

    Самое интересное происходит при формировании запроса к базе из составляющих:

    В зависимости от введенной пользователем комбинации исходных полей из этих компонентов формируется окончательный запрос, в частности для полей «Author» и «Title». Возможны четыре случая: оба поля пусты, пусто первое поле, пусто второе поле и оба поля не пусты. Соответствующая строка SQL-запроса в каждом из этих случаев формируется по-своему. То же самое относится к состоянию селекторов рубрик статей и порядку их сортировки. При добавлении той или иной подстроки учитывается состояние «радиокнопок» И/ИЛИ и соответствующая подстрока добавляется в SQL-запрос, предваряясь логическим элементом «and» или «or» соответственно. После того как окончательный запрос сформирован, он выполняется, а результирующая страница формируется исходя из списка статей, удовлетворяющих критериям.

    Полный код приведенных в статье примеров, включая файл базы данных, находится на нашем CD-ROM.

    И в заключение

    Напоследок хотелось бы сориентировать разработчиков ASP-страниц в мире документации и инструментальных средств. Дело в том, что автор настоящей статьи провел не один день сидя в Интернете в поисках всевозможных исходных текстов, документации, инструментальных средств и теоретических основ этого мощного средства.

    Среди множества инструментальных средств, служащих для облегчения создания ASP-приложений, выделяются два: Easy ASP © Eric Banker, 2000 и Microsoft InterDev из комплекта Microsoft Visual Studio 6.0. Первый — очень удобное, несложное и небольшое средство для быстрого создания ASP-приложений. Второй представляет собой мощный, тяжеловесный интегрированный пакет в духе Microsoft для разработки всевозможных Web-приложений.

    Временная версия EasyASP 4.0 находится на нашем CD-ROM.

    Среди огромного числа сайтов мною были отобраны те, посещение которых было для меня особенно полезным и с которыми хотелось ознакомить читателей, а именно:

    http://www.15seconds.com/issue/000210.htm — создание динамичных JavaScript-скриптов с помощью ASP и интерфейсов к базам данных

    http://www.alphasierrapapa.com/iisdev/ — сайт, посвященный разработке серверов IIS с помощью ASP

    http://www.websiteresources.com/ — огромная база исходных текстов всевозможных Web-программ

    Примеры ASP-кода для профессионалов

    http://www.asptoday.com/search.asp?category=ASP Tricks — масса полезных советов для начинающих программировать на ASP

    http://www.oreilly.com/catalog/aspnut/ — замечательная книга популярнейшей серии «In a Nutshell» всемирно известного издательства O’REILLY «ASP in a Nutshell A Desktop Quick Reference». На сайте бесплатно размещена одна из глав книги

    http://www.chilisoft.net/ — версии ASP для различных платформ можно скачать с этого сайта

    http://www.willcam.com/sql/ — введение в структурированный язык запросов SQL

    SQL Reference and Example Site — хорошо структурированный материал по SQL

    ASP.Net. Лекция 7. Работа с базами данных. Продолжение. Элементы-источники данных (Data Source Controls) (исходники)

    Объектная модель источников данных

    Для работы с данными в ASP.NET существуют две группы специальные элементы управления. Первая предназначена для того, чтобы осуществлять связь с источниками данных. Вторая группа служит для отображения данных.

    В Visual Studio .NET 2002 и 2003 можно было создавать привязки данных к странице по технологии «drag-and-drop». Эта технология была удобна тем, что упрощала написание кода, но она усложняла его модификацию. Объекты данных DataAdapter и DataConnection напрямую связывались Visual Studio 2005 формой. Сейчас это тоже возможно, но технология изменилась. Введена новая объектная модель источников данных. Классы-источники данных обеспечивают лучшую абстрактизацию, чем использование классов ADO.

    Один из компонентов это модели — это строка соединения с источником данных. В Vsual Studio 2005 все строки добавляются в конфигурационных файл web.config.

    Разные страницы могут использовать одну и ту же строку соединения. Если по какой-либо причине соединение нужно будет изменить, например, сервер изменил свое местоположение, изменения придется вводить централизованно только в файле web.config.

    Окно Data WebMatrix позволяет соединяться только с базами Access и SQL Server. Также работает перетаскивание, но требуется, чтобы в таблице имелся первичный ключ. Он не поддерживает и представлений (View) Access.

    В WebMatrix существуют собственные элементы управления с префиксом wmx — AccessDataSourceControl и SqlDataSourceControl. Строка соединения записывается в свойство ConnectionString такого элемента управления. Программа WebMatrix служила испытательным полигоном для тех новых возможностей, которые позже были добавлены в Visual Studio .NET 2005.

    Итак, строка соединения состоит из указания провайдера, если это Oledb, сервера и базы на этом сервере. База может находиться в отдельном файле с расширением.mdf. При соединении через ODBC указывается имя источника данных, тип базы, путь к файлу и драйвер.

    Строки могут показаться сложными, но они создаются, когда мы просто перетаскиваем на форму в Design mode таблицу или запрос. При наличии опыта можно писать их и самим.

    Строками соединений можно манипулировать и программно.

    Элементы-источники данных (Data Source Controls)

    Эти элементы облегчают работу с ADO.NET, инкапсулируя работу с соединениями, командами и адаптерами. Они реализуют интерфейс IDataSource, в котором определен базовый набор возможностей работы с источниками данных. Большинство этих классов предоставляют функциональность для чтения и записи. Они являются обертками объектов ADO.NET. В предыдущих версиях надо было создавать объекты ADO самим, и связывать элементы-управления с ними посредством команды DataBind. Например:

    Теперь элементы управления связываются c элементом-источником посредством свойства DataSourceID. Любой класс — источник данных может быть связан почти с любым классом для отображения данных. Это предоставляет большую гибкость.

    Всего в ASP .NET 5 элементов-источников данных: SqlDataSource, AccessDataSource и ObjectDataSource для работы с табличными источниками данных и XmlDataSource и SiteMapDataSource — для работы с иерархическими данными.

    SqlDataSource позволяет соединяться с большинством реляционных СУБД. Sql в названии класса означает, что служит для соединения с базами, которые понимают язык запросов Sql, а не только с MS SQL Server.

    AccessDataSource оптимизирован для работы с базами Access. Например,

    SiteMapDataSource — это специализация XmlDataSource, работает с файлами навигации по сайту и служит источником данных для элементов управления навигации.

    ObjectDataSource нужен для соединения с написанными программистом бизнес-объектами.

    Элементы — источники данных предназначены для двустороннего обмена данными, то есть как для чтения, так и для записи. Сами по себе они ничего не отображают. Данные будут доступны подключенным к ним элементам управления.

    SqlDataSource

    SqlDataSource объединяет в себе возможности SqlConnection и SqlDataAdapter(плюс дополнительные).

    Итак, у нас есть строка подключения в файле web.config.

    В свойство ConnectionString записывается эта строка.

    В свойстве DataSourceMode SqlDataSource задается, посредством DataReader или DataSet получаются данные. При чтении посредством DataReader некоторые возможности не поддерживаются.

    Получение данных связано со свойствами, похожими на свойства SqlDataAdapter: SelectCommand, SelectCommandType, DeleteCommand, DeleteCommandType и так далее. SelectCommandType может быть 2 типов — Text и StoredProcedure. Команды выполняются, когда вызываются соответствующие методы.

    Метод Select вызывается с параметром типа DataSourceSelectArguments и возвращает DataSet или IDataReader в зависимости от значения свойства DataSourceMode, остальные же методы вызываются без параметров и возвращают количество обработанных строк.

    Этот SqlDataSource читает все записи из таблицы Customers с помощью простого запроса в DataSet.

    Метод Select нет необходимости вызывать явно. Он вызывается автоматически, когда связанному с SqlDataSource элементу нужны данные для отображения.

    Процедуры сервера обычно имеют параметры. Поэтому предусмотрены также коллекции параметров. Сами параметры могут быть обычными или связанными с элементами управления.

    Значения параметров можно получать и из других разнообразных источников.

    Есть несколько классов параметров — наследников класса Parameter: CookieParameter использует значение ключа файла cookie, FormParameter — переменных формы, QuerystringParameter адресной строки, ProfileParameter профиля пользователя и SessionParameter -переменной сессии.

    Такой тип параметров используется, если SqlDataSource используется как источник данных для элементов с автоматическим связыванием — GridView, FormView, DetailsView. Значение параметра передается во «внутренностях» этих элементов.

    В других случаях используется ControlParameter, то есть значение параметра берется из элемента управления. Также задается свойство, откуда и берется значение. Хотя если это Text, его можно не писать.

    Источник параметра типа дата — элемент управления календарь. При заданном свойстве параметра ConvertEmptyToNull текстовый параметр конвертируется в Null, если он пустой(равен System.String.Empty).

    Свойство CancelSelectOnNullParameter определяет, будет ли прерван запрос, если значение какого-либо параметра равно Null.

    Этот запрос будет брать параметр из командной строки, например

    Кеширование

    Кеширование нужно для увеличения эффективности работы с данными. При включенном кешировании SqlDataSource «запоминает» большое количество записей на заданное время, даже если все данные не отображаются сразу, но могут понадобиться при перелистывании. Например, студент читает первую страницу лекции, логично, что он вскоре перейдет ко второй. Если сервер хранит в оперативной памяти все страницы лекции, он их оперативно выдаст, не обращаясь к базе.

    При включенном кешировании данные читаются «большим куском», а выборка записей происходит с помощью фильтрования.

    В SqlDataSource кеширование и сортировка возможны только при получении данных через DataSet. Если DataSourceMode равно DataReader, а EnableCaching — True, будет выброшено исключение NonSupportedException.

    Длительность кеширования можно задать в свойстве CacheDuration, это может быть определенное количество секунд или Infinite, то есть данные никогда не обновляются.

    Поведение кеширования зависит от сочетания свойств CacheDuration и CacheExpirationPolicy. Если значение CacheExpirationPolicy равно Absolute, то элемент запрашивает информацию через промежутки времени, определенные в CacheDuration, а старую стирает из памяти. Если CacheExpirationPolicy равен значению Sliding, то SqlDataSource начинает отсчет времени после каждого к нему запроса. Данные из кеша устаревают, если в течение времени CacheDuration не было ни одного Select-запроса.

    В FilterExpression задается выражение для фильтрации, причем формат этих выражений аналогичен тому, что используется для форматирования строк с параметрами в фигурных скобках <0>, <1>, в которые подставляются значения из источника, указанного в FilterParameters.

    У этого элемента включено кеширование, и он является источником данных для GridView.

    А у этого включена фильтрация, и он является источником данных для DetailsView. Контрол DetailsView всегда отображает одну запись, при этом в данном случае эта та запись, которая выбрана в контроле GridView1.

    Сортировка

    В свойстве SortParameterName можно записать список полей, по которым проводится сортировка, возможно с добавлением опции Desc для сортировки в порядке убывания. Параметры передаются в команду Select, если это серверная процедура.

    ObjectDataSource

    Как уже было сказано, этот класс работает с бизнес-объектами. А что же это такое? Это такие классы, которые инкапсулируют логику работы с данными, нужными в приложении. Класс бизнес-объекта может быть написан на любом языке .NET. Как и все классы, он располагается в папке App_Code. ObjectDataSource работает как связующее звено между бизнес-объектами и элементами управления, отображающими данные. Получается многоуровневая компонентная архитектура. Классы бизнес-объектов могут поменять свое внутреннее представление, и это никак не отразится на страницах, которые их используют. ObjectDataSource работает во многом так же, как SqlDataSource, с той разницей, что он имеет дело не с базой данных, а с классом.

    Свойство TypeName класса ObjectDataSource указывает на используемый класс. Класс бизнес-объекта должен поддерживать конструктор и 4 метода(может и больше) — для чтения, редактирования, удаления и добавления данных в источник данных. Элемент управления ObjectDataSource пользуется этими методами.

    Например, свойство SelectMethod указывает на метод класса бизнес-объекта, который возвращает данные.

    Откуда бизнес-объект берет данные, ему не важно. Некоторые бизнес-объекты работают с базами данных, некоторые с сессией или текстовыми файлами. Главное, что метод, который он использует для чтения, должен возвращать класс, реализующий интерфейс IEnumerable. UpdateMethod- метод, который обновляет данные. Аналогичную функцию выполняют DeleteMethod и InsertMethod.

    Класс бизнеса-объект может поддерживать метод SelectCount, который возвращает общее количество объектов в источнике данных.ObjectDataSource вызывает этот метод, чтобы реализовать разбиение на страницы.

    Рассмотрим это на примере:

    Даже такой примитивный класс может использоваться как источник данных для ObjectDataSource, так как ArrayList реализует IEnumerable. Вместо свойств *Command ObjectDataSource использует *Method.

    Достигается тот же эффект, что и раньше, когда данные вставлялись на странице или в классе страницы, но теперь получение данных инкапсулировано в классе Continent. Класс может изменить способ получения данных, не меняя интерфейса. Чаще всего данные все-таки получают из баз данных, XML-файлов или веб-сервисов. Классы бизнес-логики могут разрабатывать одни члены команды, а заниматься дизайном страниц другие. Их можно использовать и в обычных приложениях в Windows Forms.

    ObjectDataSource может работать и с типизированными наборами данных, которые можно создать с помощью мастера. Попробуем это сделать на примере таблицы Customers. Создайте в папке App_Code новый файл и в диалоге выбора типа файла выберите dataset. Назовите его Customers. Мастер предложит выбрать строку соединения. Выберите NorthWindConnectionString (если его нет в проекте, создайте, как показано в предыдущей лекции). На следующем шаге мастер предложит выбрать из трех вариантов: использование запросов SQL, создание хранимых процедур или использование готовых процедур. Выберите второе, так как готовых процедур, которые бы обновляли данные, в базе Northwind нет. На следующем шаге нужно будет создать процедуры, это можно сделать с помощью QueryBuilder, очень похожем на дизайнер запросов в MS Access. В списке таблиц выберите Customers, а в таблице несколько полей. Должен получиться запрос

    SELECT CustomerID, CompanyName, ContactName, ContactTitle, Country, City FROM Customers

    После этого закройте QueryBuilder и нажмите на кнопку AdvancedOptions.

    Как видите, мастер предлагает сгенерировать остальные команды самому. Прекрасно, мы не против. На следующем шаге мастер предложит изменить имена процедур и увидеть, что же он сгенерировал. Через остальные шаги можно пройти без изменений.

    В результате получится файл Customers.xsd, по формату — файл схемы XML(XML Schema Definition, в котором описано и создание процедур, и команды для работы с базой вместе с параметрами, и еще один маленький файл Customers.xss. После этого проект желательно скомпилировать.

    Мы получили компонент данных. Все готово для связывания его с ObjectDataSource. Перетащите значок нужного класса на форму и с помощью SmartTag запустите еще один мастер. На первом шаге настройте его на CustomersDataAdapters.CustomersDataAdapter. На втором надо выбрать подходящие функции для команд Select, Update, Delete, Insert. Вариантов будет немного и Finish. Можно привязывать наш ObjectDataSource к любому подходящему элементу управления, например GridView.

    Класс бизнес-объекта создается неявно. Из файла .xsd vожно получить класс типизированного набора данных на языке C# с помощью утилиты xsd.exe.

    Из одного класса могут получать данные разные элементы ObjectDataSource. В приложении Personal Starter Kit определен класс PhotoManager, который работает с базой данных Personal.mdf.

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

    Заключение

    Мы рассмотрели классы-элементы управления, которые отвечают за получение данных. Эти классы предназначены в первую очередь для облегчения труда программиста по сравнению с предыдущими версиями. Наиболее простые страницы с помощью этих элементов создаются даже без написания программного кода. В следующих двух лекциях подробнее займемся отображением данных. XMLDataSource будет рассмотрен в лекции 10, а SiteMapSource — в 11.


    asp:SqlDataSource to DataSet Items

    I have an asp:SqlDataSource tool on my aspx page, what I want to do in the c# sharp code behind is transfer the records returned by the datasource and put them into a DataSet, so that I can add paging to my page, how do I do that, my attempts so far have failed?!

    My attempts so far have been along the lines of:

    DataSet Items = new DataSet(); Items = SqlDataSource1.Data();

    But the error I am getting is that the SqlDataSource1 control is not accessible in this context and so obviously the intellisense is not picking it up, so the ‘Data()’ bit is complete fiction on my part.

    Авторизация в ASP.NET Core MVC

    В статье описаны паттерны и приемы авторизации в ASP.NET Core MVC. Подчеркну, что рассматривается только авторизация (проверка прав пользователя) а не аутентификация, поэтому в статье не будет использования ASP.NET Identity, протоколов аутентификации и т.п. Будет много примеров серверного кода, небольшой экскурс вглубь исходников Core MVC, и тестовый проект (ссылка в конце статьи). Приглашаю интересующихся под кат.

    Claims

    Принципы авторизации и аутентификации в ASP.NET Core MVC не изменились по сравнению с предыдущей версией фреймворка, отличаясь лишь в деталях. Одним из относительно новых понятий является claim-based авторизация, с нее мы и начнем наше путешествие. Что же такое claim? Это пара строк «ключ-значение», в качестве ключа может выступать «FirstName», «EmailAddress» и т.п. Таким образом, claim можно трактовать как свойство пользователя, как строку с данными, или даже как некоторое утверждение вида «у пользователя есть что-то«. Знакомая многим разработчикам одномерная role-based модель органично содержится в многомерной claim-based модели: роль (утверждение вида «у пользователя есть роль X«) представляет собой один из claim и содержится в списке преопределенных System.Security.Claims.ClaimTypes. Не возбраняется создавать и свои claim.

    Следующее важное понятие — identity. Это единое утверждение, содержащее набор claim. Так, identity можно трактовать как цельный документ (паспорт, водительские права и др.), в этом случае claim — строка в паспорте (дата рождения, фамилия. ). В Core MVC используется класс System.Security.Claims.ClaimsIdentity.

    Еще на уровень выше находится понятие principal, обозначающее самого пользователя. Как в реальной жизни у человека может быть на руках несколько документов одновременно, так и в Core MVC — principal может содержать несколько ассоциированных с пользователем identity. Всем известное свойство HttpContext.User в Core MVC имеет тип System.Security.Claims.ClaimsPrincipal. Естественно, через principal можно получить все claim каждого identity. Набор из более чем одного identity может использоваться для разграничения доступа к различным разделам сайта/сервиса.

    На диаграмме указаны лишь некоторые свойства и методы классов из пространства имен System.Security.Claims.

    Зачем это все нужно? При claim-based авторизации, мы явно указываем, что пользователю необходимо иметь нужный claim (свойство пользователя) для доступа к ресурсу. В простейшем случае, проверяется сам факт наличия определенного claim, хотя возможны и куда более сложные комбинации (задаваемые при помощи policy, requirements, permissions — мы подробно рассмотрим эти понятия ниже). Пример из реальной жизни: для управления легковым авто, у человека должны быть водительские права (identity) с открытой категорией B (claim).

    Подготовительные работы

    Здесь и далее на протяжении статьи, мы будем настраивать доступ для различных страниц веб-сайта. Для запуска представленного кода, достаточно создать в Visual Studio 2015 новое приложение типа «ASP.NET Core Web Application», задать шаблон Web Application и тип аутентификации «No Authentication».

    При использовании аутентификации «Individual User Accounts» был бы сгенерирован код для хранения и загрузки пользователей в БД посредством ASP.NET Identity, EF Core и localdb. Что является совершенно избыточным в рамках данной статьи, даже несмотря на наличие легковесного EntityFrameworkCore.InMemory решения для тестирования. Более того, нам в принципе не потребуется библиотека аутентификации ASP.NET Identity. Получение principal для авторизации можно самостоятельно эмулировать in-memory, а сериализация principal в cookie возможна стандартными средствами Core MVC. Это всё, что нужно для нашего тестирования.

    Для эмуляции хранилища пользователей достаточно открыть Startup.cs и зарегистрировать сервисы-заглушки во встроенном DI-контейнере:

    Кстати, мы всего лишь проделали ту же работу, что проделал бы вызов AddEntityFrameworkStores :

    Начнем с авторизации пользователя на сайте: на GET /Home/Login нарисуем форму-заглушку, добавим кнопку для отправки пустой формы на сервер. На POST /Home/Login вручную создадим principal, identity и claim (в реальном приложении эти данные были бы получены из БД). Вызов HttpContext.Authentication.SignInAsync сериализует principal и поместит его в зашифрованный cookie, который в свою очередь будет прикреплен к ответу веб-сервера и сохранен на стороне клиента:

    Включим cookie-аутентификацию в методе Startup.Configure(app):

    Этот код с небольшими модификациями будет основой для всех последующих примеров.

    Атрибут Authorize и политики доступа

    Атрибут [Authorize] никуда не делся из MVC. По-прежнему, при маркировке controller/action этим атрибутом — доступ внутрь получит только авторизованный пользователь. Вещи становятся интереснее, если дополнительно указать название политики (policy) — некоторого требования к claim пользователя:

    Политики создаются в уже известном нам методе Startup.ConfigureServices :

    Такая политика устанавливает, что попасть на страницу About сможет только авторизованный пользователь с claim-ом «age», при этом значение claim не учитывается. В следующем разделе, мы перейдем к примерам посложнее (наконец-то!), а сейчас разберемся, как это работает внутри?

    [Authorize] — атрибут маркерный, сам по себе логики не содержащий. Нужен он лишь для того, чтобы указать MVC, к каким controller/action следует подключить AuthorizeFilter — один из встроенных фильтров Core MVC. Концепция фильтров та же, что и в предыдущих версиях фреймворка: фильтры выполняются последовательно, и позволяют выполнить код до и после обращения к controller/action. Важное отличие от middleware: фильтры имеют доступ к специфичному для MVC контексту (и выполняются, естественно, после всех middleware). Впрочем, грань между filter и middleware весьма расплывчата, так как вызов middleware возможно встроить в цепочку фильтров при помощи атрибута [MiddlewareFilter].

    Вернемся к авторизации и AuthorizeFilter. Самое интересное происходит в его методе OnAuthorizationAsync:

    1. Из списка политик выбирается нужная на основе указанного в атрибуте [Authorize] значения (либо берется AuthorizationPolicy — политика по-умолчанию, содержащая всего одно требование с говорящим названием — DenyAnonymousAuthorizationRequirement.
    2. Выполняется проверка, соответствует ли набор из identity и claim-ов пользователя (например, полученных ранее из cookies запроса) требованиям политики.

    Надеюсь, приведенные ссылки на исходный код дали вам представление об внутреннем устройстве фильтров в Core MVC.

    Настройки политик доступа

    Создание политик доступа через рассмотренный выше fluent-интерфейс не дает той гибкости, которая требуется в реальных приложениях. Конечно, можно явно указать допустимые значения claim через вызов RequireClaim(«x», params values) , можно скомбинировать через логическое И несколько условий, вызвав RequireClaim(«x»).RequireClaim(«y») . Наконец, можно навесить на controller и action разные политики, что, впрочем, приведет к той же комбинации условий через логическое И. Очевидно, что необходим более гибкий механизм создания политик, и он у нас есть: requirements и handlers.

    Requirement — не более чем DTO для передачи параметров в соответствующий handler, который в свою очередь имеет доступ к HttpContext.User и волен налагать любые проверки на principal и содержащиеся в нем identity/claim. Более того, handler может получать внешние зависимости через встроенный в Core MVC DI-контейнер:

    Регистрируем сам handler в Startup.ConfigureServices(), и он готов к использованию:

    Handler-ы возможно сочетать как через AND, так и через OR. Так, при регистрации нескольких наследников AuthorizationHandler , все они будут вызваны. При этом вызов context.Succeed() не является обязательным, а вызов context.Fail() приводит к общему отказу в авторизации вне зависимости от результата других handler. Итого, мы можем комбинировать между собой рассмотренные механизмы доступа следующим образом:

    • Policy: AND
    • Requirement: AND
    • Handler: AND / OR.

    Resource-based авторизация

    Как уже говорилось ранее, policy-based авторизация выполняется Core MVC в filter pipeline, т.е. ДО вызова защищаемого action. Успех авторизации при этом зависит только от пользователя — либо он обладает нужными claim, либо нет. А что, если необходимо учесть также защищаемый ресурс и его свойства, получить какие данные из внешних источников? Пример из жизни: защищаем action вида GET /Orders/ , считывающий по id строку с заказом из БД. Пусть наличие у пользователя прав на конкретный заказ мы сможем определить только после получения этого заказа из БД. Это автоматически делает непригодными рассмотренные ранее аспектно-ориентированные сценарии на основе фильтров MVC, выполняемых перед тем, как пользовательский код получает управление. К счастью, в Core MVC есть способы провести авторизацию вручную.

    Для этого, в контроллере нам потребуется реализация IAuthorizationService . Получим ее, как обычно, через внедрение зависимости в конструктор:

    Затем создадим новую политику и handler:

    Наконец, проверяем пользователя + ресурс на соответствие нужной политике внутри action (заметьте, атрибут [Authorize] больше не нужен):

    У метода IAuthorizationService.AuthorizeAsync есть перегрузка, принимающая список из requirement — вместо названия политики:

    Что позволяет еще более гибко настраивать права доступа. Для демонстрации, используем преопределенный OperationAuthorizationRequirement (да, этот пример перекочевал в статью прямо с docs.microsoft.com):

    что позволит вытворять следующие вещи:

    В методе HandleRequirementAsync(context, requirement, resource) соответствующего handler — нужно лишь проверить права соответственно операции, указанной в requirement.Name и не забыть вызвать context.Fail() если пользователь провалил авторизацию:

    Handler будет вызван столько раз, сколько requirement вы передали в AuthorizeAsync и проверит каждый requirement по-отдельности. Для единовременной проверки всех прав на операции за один вызов handler — передавайте список операций внутри requirement, например так:

    На этом обзор возможностей resource-based авторизации закончен, и самое время покрыть наши handler-ы тестами:

    Авторизация в Razor-разметке

    Выполняемая непосредственно в разметке проверка прав пользователя может быть полезна для скрытия элементов UI, к которым пользователь не должен иметь доступ. Конечно же, во view можно передать все необходимые флаги через ViewModel (при прочих равных я за этот вариант), либо обратиться напрямую к principal через HttpContext.User:

    Если вам интересно, то view наследуются от RazorPage класса, а прямой доступ к HttpContext из разметки возможен через свойство @Context .

    С другой стороны, мы можем использовать подход из предыдущего раздела: получить реализацию IAuthorizationService через DI (да, прямо во view) и проверить пользователя на соответствие требованиям нужной политики:

    Не пытайтесь использовать в нашем тестовом проекте вызов SignInManager.IsSignedIn(User) (используется в шаблоне веб-приложения с типом аутентификации Individual User Accounts). В первую очередь потому, что мы не используем библиотеку аутентификации Microsoft.AspNetCore.Identity , к которой этот класс принадлежит. Сам метод внутри не делает ничего, помимо проверки наличия у пользователя identity с зашитым в коде библиотеки именем.

    Permission-based авторизация. Свой фильтр авторизации

    Декларативное перечисление всех запрашиваемых операций (в первую очередь из числа CRUD) при авторизации пользователя, такое как:

    … имеет смысл, если в вашем проекте построена система персональных разрешений (permissions): имеется некий набор из большого числа высокоуровневых операций бизнес-логики, есть пользователи (либо группы пользователей), которым были в ручном режиме выданы права на конкретные операции с конкретным ресурсом. К примеру, у Васи есть права «драить палубу», «спать в кубрике», а Петя может «крутить штурвал». Хорош или плох такой паттерн — тема для отдельной статьи (лично я от него не в восторге). Очевидная проблема данного подхода: список операций легко разрастается до нескольких сотен даже не в самой большой системе.

    Ситуация упрощается, если для авторизации нет нужды учитывать конкретный экземпляр защищаемого ресурса, и наша система обладает достаточной гранулярностью, чтобы просто навесить на весь метод атрибут со списком проверяемых операций, вместо сотен вызовов AuthorizeAsync в защищаемом коде. Однако, использование авторизации на основе политик [Authorize(Policy = «foo-policy»)] приведет к комбинаторному взрыву числа политик в приложении. Почему бы не использовать старую добрую role-based авторизацию? В примере кода ниже, пользователю необходимо быть членом всех указанных ролей для получения доступа к FooController:

    Подобное решение так же может не дать достаточной детализации и гибкости для системы с большим количеством permissions и их возможных комбинаций. Дополнительные проблемы начинаются, когда нужна и role-based и permission-based авторизация. Да и семантически, роли и операции — разные вещи, хотелось бы обрабатывать их авторизацию отдельно. Решено: пишем свою версию атрибута [Authorize] ! Продемонстрирую конечный результат:

    Начнем с создания enum для операций, requirement и handler для проверки пользователя:

    Ранее я рассказывал, что атрибут [Authorize] сугубо маркерный и нужен для применения AuthorizeFilter . Не будем бороться с существующей архитектурой, поэтому напишем по аналогии собственный фильтр авторизации. Поскольку список permissions у каждого action свой, то:

    1. Необходимо создавать экземпляр фильтра на каждый вызов;
    2. Невозможно напрямую создать экземпляр через встроенный DI-контейнер.

    К счастью, в Core MVC эти проблемы легко разрешимы при помощи атрибута [TypeFilter]:

    Мы получили полностью работающее, но безобразно выглядящее решение. Для того, чтобы скрыть детали реализации нашего фильтра от вызывающего кода, нам и пригодится атрибут [AuthorizePermission] :

    Обратите внимание: фильтры авторизации работают независимо, что позволяет сочетать их друг с другом. Порядок выполнения нашего фильтра в общей очереди можно скорректировать при помощи свойства AuthorizePermissionAttribute.Order .

    Дополнительные материалы для чтения по теме (также приветствуются ваши ссылки для включения в список):

    Data Access Layer как инструмент управления хранением данных

    При проектировании полного жизненного цикла Enterprise-приложений большое значение приобретает вопрос организации их доступа к данным. Тому есть ряд причин:

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

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

    Проблему разделения бизнес-логики и работы с данными на уровне отдельного приложения решает широко известный и не раз описанный на «Хабрахабре» архитектурный шаблон Data Access Layer (DAL). Для того, чтобы этот шаблон можно было масштабировать до уровня всего предприятия, необходимо дополнить его рядом архитектурных принципов, которые рассматриваются в данной статье. Следование этим принципам позволит предприятию осуществлять контролируемую (управляемую) замену или добавлять технологии хранения данных в свою архитектуру ИТ.

    Проблематика

    Данный раздел более подробно описывает исходную проблематику и предпосылки, которые привели к разработке концепции DAL.

    Необходимость работы со специализированными БД

    В настоящее время классические реляционные СУБД (РСУБД) перестали быть единственным средством для решения задачи по хранению данных при разработке приложений. От универсальных СУБД происходит переход к специализированным. При этом специализация средств хранения идет по разным направлениям: по объему (класс Big Data), нагрузке (класс HighLoad), производительности (классы High Performance, Fast Data) и т. д.

    Для архитектуры конкретного приложения входит в норму подбор средства или класса средств хранения под конкретную решаемую задачу. Для масштабных ИТ-систем оптимальным нередко становится одновременное использование нескольких БД различного типа в рамках одного приложения (гетерогенное хранение, рис. 1) для разных групп данных.

    Рис. 1. Универсальные и специализированные базы данных

    Например, для отдельных задач, в которых не требуется представлять в реляционной модели данные простой структуры, но при этом необходимо обеспечить повышенные требования к производительности и масштабируемости, могут применяться специализированные хранилища «ключ-значение» (key-value). Для иных специальных видов данных (document, photo, video, excel, text) и различных нефункциональных требований существует и широко используется масса других средств хранения с различными интерфейсами доступа (NoSQL).

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

    Таким образом, современное предприятие с развитой ИТ-архитектурой все чаще сталкивается с необходимостью отхода от «единого золотого стандарта» применяемой СУБД (часто это БД компаний Oracle или Microsoft) и оказывается лицом к лицу с необходимостью обеспечивать инфраструктуру приложений в виде множества баз данных и хранилищ, в том числе класса NoSQL.

    На уровне архитектуры приложений это ведет к появлению множества ранее недоступных возможностей по применению специализированных БД, что позволяет ускорять разработку, снижать стоимость сопровождения, обеспечивать принципиально новые возможности для бизнеса (если, конечно, новые возможности используются с умом). Например, использование кластерных БД с хранением в памяти (так называемых in-memory database, характерные представители — VoltDB или SAP HANA) может реализовать радикально отличающийся подход к решению задач бизнес-аналитики за счет ускорения вычислений на несколько порядков.

    В свою очередь, на уровне технической архитектуры предприятия возникает необходимость работы с большим количеством разнородных БД, что значительно усложняет и удорожает все процессы ИТ-службы, требует переподготовки специалистов, приводит к усложнению задач управления, в том числе управления жизненным циклом используемых технологий.

    Оптимальное решение перечисленных проблем должно сочетать, с одной стороны, возможность одновременного использования нескольких современных специализированных БД, а с другой — управляемость этой конструкции на уровне общей политики и технологической стратегии предприятия.

    Воздействие внешних условий

    Вторым существенным фактором, инициирующим процесс перемен в области технической инфраструктуры предприятия, является изменение коммерческих (или иных) условий поставщиков решений для предприятия. Особенно это касается РСУБД, с которыми прикладные бизнес-приложения зачастую оказываются связаны более тесно, чем с операционными системами, сетевым оборудованием или файловыми системами хранения.

    При определенных условиях может возникнуть острая необходимость в замене РСУБД тех или иных поставщиков. В таком случае срочная замена БД во многих активно работающих бизнес-приложениях может оказаться чрезвычайно дорогим и сложным проектом, чреватым сбоями и простоями информационных систем, а как следствие — и бизнеса. Снять риск попадания в такую непростую для предприятия ситуацию могла бы постепенная и планомерная подготовка бизнес-приложений к смене СУБД в случае появления необходимости.

    Потребность в модернизации и технологическом развитии

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

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

    Во втором случае — даже при условии сохранения конкурентоспособности конкретного средства хранения — тренды и задачи технологического развития могут требовать перехода к новым технологиям, открывающим принципиально иные возможности для развития функционала приложений. Если существующее приложение тесно связано с одним типом БД или в рамках архитектуры всего предприятия зафиксирован только один тип БД, то многие возможности развития бизнес-приложений оказываются закрытыми.

    Концепция Data Access Layer

    В данном разделе описывается общая концепция и принципы DAL, с помощью которых можно решить вышеупомянутые проблемы. Здесь концепция описана абстрактно и пока не связана с применением тех или иных технологий или программных продуктов.

    Принцип управляемого специализированного хранения данных

    Итак, разрабатываемая концепция должна отвечать поставленной проблематике:

    • обеспечивать возможность использования специализированных БД в ИТ-архитектуре предприятия одновременно с сохранением управляемости (например, за счет контроля их разнообразия и применения);
    • подготавливать бизнес-приложения к плавной и технологичной смене СУБД в случае обострения отношений с поставщиком СУБД или, возможно, из соображений технологической модернизации и технологического развития.

    В основе концепции лежит принцип управляемого специализированного хранения данных, который вводит унифицированный и контролируемый способ доступа к различным данным для приложений (рис. 2).

    Рис. 2. Принцип управляемого специализированного хранения данных

    На уровне технологической политики предприятия определяется фиксированный набор классов данных, для которых в инфраструктуре предоставляются некоторые средства хранения. Каждый класс данных при этом предполагает специализированный интерфейс доступа (пока — на логическом уровне), оптимальный для данного класса. Например, для класса данных key-value интерфейс доступа должен предоставлять операции чтения и записи данных по ключу. А для класса данных «реляционная модель» интерфейс доступа представлен в виде некоторого фиксированного диалекта SQL.

    Для каждого такого логического класса данных инфраструктура может предоставить средства хранения с разным уровнем обеспечения нефункциональных требований, который четко зафиксирован некоторым SLA (определяемым классом средств хранения).

    Корпоративные приложения запрашивают и используют различные классы данных и соответствующие интерфейсы доступа, абстрагируясь от конкретных технологий, которые в данный момент реализуют тот или иной интерфейс. Управление доступом к различным БД предоставляется в контролируемом режиме, а приложение «не знает», с какой именно реализацией БД оно работает.

    В результате, с одной стороны, приложение может использовать специализированные средства хранения, получая к ним доступ через четко определенный программный интерфейс. С другой стороны, если потребуется замена какой-то конкретной СУБД на аналогичную, не придется осуществлять серьезные переделки в приложении. В крайнем случае — относительно недорогая адаптация к мелким особенностям новой технологии без необходимости пересмотра архитектуры. Вся структура доступа к данным «приложения — различные СУБД» в масштабе предприятия становится наблюдаемой и контролируемой.

    Ограничение способа доступа к данным на уровне программной архитектуры

    Рис. 3. Ограничение способа доступа к данным на уровне программной архитектуры

    Еще один важный принцип DAL связан с механизмом обеспечения выбранного способа доступа к данным для бизнес-приложений (рис. 3). Теоретически достаточно было бы зафиксировать ряд ограничений доступа к данным на уровне архитектурной политики предприятия и контролировать соблюдение этих ограничений при проектировании и разработке информационных систем.

    Однако на практике такой контроль организовать достаточно сложно. Это требует от предприятия затрат времени дорогостоящих экспертов-архитекторов. При этом все равно не исключено, что производитель информационной системы по тем или иным причинам не выйдет за рамки оговоренного контрактом класса данных и SLA. Накопление таких прецедентов со временем приводит к тому, что приложение оказывается непереносимым на другую СУБД, несмотря на формально ограниченный интерфейс доступа к данным.

    Решением этой проблемы может быть только жесткое отделение приложения от СУБД таким образом, чтобы приложение в принципе не получало прямого доступа к СУБД, а работало только через специализированный модуль доступа к данным — это и есть Data Access Layer. По сути, получается, что DAL фиксирует архитектурную политику предприятия в части доступа к данным на уровне программной архитектуры, что дает гораздо больше гарантий выполнения контракта класса данных по сравнению с фиксацией на уровне спецификаций и соглашений.

    Для информационных систем, реализованных на разных базовых технологиях и требующих разных интерфейсов доступа к данным, реализации модулей DAL могут быть различными. Экземпляры этих модулей также могут быть различны для разных приложений, а могут быть общими — из соображений экономии ресурсов или, напротив, для обеспечения независимости функционирования систем. Но во всех случаях должен соблюдаться принцип непрямого доступа приложения к средствам хранения.

    Вынос бизнес-логики из БД

    Принцип отделения приложений от средств хранения через унифицированные интерфейсы доступа способен решить проблему быстрого перехода на альтернативную технологию хранения, но только в том случае, если само приложение разворачивается вне БД. На практике до сих пор часто встречаются и активно используются информационные системы, в которых существенная часть бизнес-логики приложения реализована внутри СУБД на встроенном процедурном языке. Для таких систем легкая переносимость на другие СУБД может быть обеспечена только путем переработки системы с выносом бизнес-логики из СУБД на отдельный сервер приложений.

    Для всех вновь разрабатываемых или активно развиваемых систем также необходимо осуществлять контроль за тем, чтобы внутри СУБД не накапливался большой объем функционала, который может затруднить переход на другое средство хранения. Проконтролировать это технически достаточно сложно, так как требуется встраивание промежуточного звена не только в процесс доступа к данным, но и в процесс управления структурами данных и настройками СУБД. Поэтому такой контроль должен обеспечиваться при разворачивании новых систем и их обновлений, а также в процессах архитектурного аудита предлагаемых технических решений с помощью экспертной оценки.

    Понятия

    Этот раздел уточняет и детализирует модель объектов описания DAL, коротко введенную в предыдущем разделе.

    Рис. 4. Понятийная модель концепции DAL

    Концепция вводит несколько понятий (рис. 4):

    • класс данных;
    • средство хранения;
    • характеристика средства хранения;
    • класс средств хранения;
    • группа данных;
    • контейнер данных.

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

    Класс данных

    Определяет идеальную абстракцию данных, не зависящую ни от конкретных технологий, ни от ограничений реализуемости:

    • абстрактную («логико-математическую») модель самих данных (например, «набор реляционных отношений» или «набор пар ключ-значение»);
    • модель (или несколько моделей) доступа к данным и вычисления над данными (например, «реляционная алгебра» или MapReduce);
    • модель безопасности (например, «именованные контейнеры», «пользователи» и «права»);
    • модель структуры данных (например, «схема с описанием таблиц» или «перечень групп атрибутов»).

    На уровне класса данных еще нет ни вопросов транзакционности, ни вопросов производительности, ни характеристик реализации типа in-memory. Бизнес-логика приложения реализована на основе определенного класса данных, и смена класса данных никак не может произойти без перепроектирования логики приложения.

    Структура данных

    Определяет структуру данных в некоторой модели (определяемой классом данных), специфичную для конкретного приложения: например, для реляционной модели — перечень таблиц, колонок, ключей.

    Средства хранения


    Конкретные имеющиеся на рынке или развернутые на предприятии средства хранения (различные виды БД) предоставляют возможности одного или нескольких классов средств хранения для нескольких классов данных.

    Характеристика средства хранения

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

    • производительность чтения/записи;
    • масштабируемость;
    • работа в памяти (in-memory);
    • ограничения;
    • специализация (например, Big Data или Fast Data);
    • поддержка ACID-транзакций и т. д.

    Класс средств хранения (SLA)

    В рамках одного класса данных группирует такой набор характеристик хранения, который, с одной стороны, часто востребован в приложениях, а с другой — обеспечивает альтернативную реализацию (средство хранения).

    Для различных классов данных могут определяться разные SLA. Перевод данных приложения с одного класса хранения на другой может потребовать частичного перепроектирования, поскольку понадобится компенсация ослабевающих или пропадающих свойств SLA. Переделки также вероятны в случае необходимости выделения внутри приложения отдельной группы данных для размещения в другом классе данных или средстве хранения с последующей интеграцией этих данных с другими группами.

    Группа данных

    Данные в рамках конкретного приложения, по логике этого приложения принадлежащие к одному классу данных и требующие одного SLA; например, в приложении может быть выделена группа данных «справочники X», принадлежащая классу key-value и требующая быстрого чтения по ключу.

    Контейнер данных

    Идентифицируемый объем данных, хранимых с помощью некоторого средства хранения и соответствующих одной группе данных одного приложения. В ответ на запрос хранения данных для приложения выделяется один или несколько контейнеров данных.

    Структура Data Access Layer

    Данный раздел описывает принципиальное устройство программного обеспечения DAL, реализующего концепцию унифицированного доступа к данным. В описании структуры DAL рассматриваются в том числе и вопросы выбора и применения конкретных технологий и программных продуктов.

    Функции и границы DAL в ИТ-ландшафте предприятия

    Структура DAL — это набор программных средств, из которых может быть построен слой унифицированного доступа к данным в рамках ИТ-архитектуры предприятия, реализующий принцип «управляемого специализированного хранения данных» и фиксирующий его в жесткой форме программной архитектуры. DAL образует контролируемый «слой» между бизнес-приложениями и средствами хранения (базами данных) (рис. 5).

    Рис. 5. Структура DAL в архитектуре предприятия

    Структура DAL представляет собой набор слабо связанных программных модулей для организации доступа к данным разных приложений. Слабая связанность модулей позволяет избежать проблем в синхронизации процессов разработки и обновления разных приложений и программного обеспечения DAL. Сами модули доступа могут иметь специфические реализации для различных базовых технологий, на которых разработаны бизнес-приложения.

    Принципы, применяющиеся при проектировании DAL

    Варианты размещения компонентов структуры DAL

    Рис. 6. Варианты размещения компонентов структуры DAL

    Структура DAL предполагает два варианта размещения модулей доступа к данным (рис. 6).

    1. В виде библиотеки, включаемой в состав приложения. В этом варианте необходима разработка разных видов модулей доступа для разных технологий разработки АС.
    2. В виде сетевого сервиса. Этот вариант предназначен для тех случаев, когда по каким-то причинам невозможна или нежелательна работа сервиса доступа к данным в виде библиотеки (например, ИС разработана на платформе, у которой нет библиотеки для работы с DAL). В таком варианте DAL доступен для любого приложения, способного работать с сетевыми сервисами по протоколу HTTP. Для этого способа размещения набор предоставляемых интерфейсов доступа к данным может быть ограничен.

    Программные интерфейсы доступа к данным

    Для реализации доступа бизнес-приложений к данным каждого класса следует отдавать предпочтение индустриальным стандартам и стандартам де-факто для программных интерфейсов доступа (API). Это позволит обеспечить не только максимально простую адаптацию существующих АС к работе с DAL, но и долгосрочную устойчивость слоя доступа к данным к последующим технологическим изменениям.

    Программные интерфейсы доступа к данным (API), которые бизнес-приложения получают в пользование, могут различаться для разных базовых технологий приложений. Это оптимизирует разработку и соответствует стандартам де-факто для данной базовой технологии. Важно отметить, что такое разделение не нарушает общие принципы концепции унифицированного доступа к данным, поскольку — и это главное — сохраняется независимость приложения от конкретной используемой технологии БД. Например, для приложений, разработанных на Java, стандартным интерфейсом доступа к реляционным данным может быть принятый в Java-мире интерфейс JDBC, в то время как для приложений на C/C++ предоставляется интерфейс ODBC.

    Ограничение диалекта SQL при работе через интерфейсы ODBC/JDBC

    Рис. 7. Унификация и трансляция SQL

    Для реляционных данных современные СУБД предоставляют большое количество специфических возможностей и диалектов языка SQL. Активное использование разнообразных инструментов в приложениях приводит к ухудшению их переносимости. Поэтому в рамках реализации DAL модуль доступа к реляционным данным на основе SQL должен специально ограничивать используемый диалект SQL таким образом, чтобы приложение в принципе не имело возможности завязаться на особенности конкретной СУБД (рис. 7).

    Кроме задачи ограничения используемого диалекта возникает также задача трансляции отдельных синтаксических элементов SQL в диалект конкретной СУБД. Такая необходимость появляется из-за того, что некоторые общие и широко используемые в приложениях возможности РСУБД хотя и присутствуют в подавляющем их большинстве, но не входят при этом в стандарт SQL.

    Модуль доступа к РСУБД для приложений Java

    Исходя из изложенных выше принципов проектирования, первым и наиболее актуальным модулем для реализации DAL является модуль доступа к реляционным данным. Несмотря на то, что, как было описано в проблематике, все чаще корпоративные бизнес-приложения пользуются потенциальными преимуществами в использовании NoSQL-БД, реляционные БД остаются наиболее широко применяемыми и востребованными видами средств хранения (зачастую просто потому, что большое количество прикладного ПО уже разработано в расчете именно на РСУБД).

    Напомним также, что для приложений, реализованных на разных базовых технологиях, с высокой вероятностью будет необходима разработка разных модулей доступа. В данном разделе описано устройство модуля DAL для приложений на Java. Эта технология широко распространена в крупных корпорациях и банках и отличается большим количеством устойчивых и поддерживаемых индустриальных стандартов, которые могут быть взяты за основу для разработки унифицированного интерфейса доступа к данным.

    Интерфейсы доступа к реляционным данным

    Для Java-приложений широко распространены два стандартных интерфейса доступа к РСУБД:

    • доступ напрямую к реляционным данным через интерфейс JDBC и язык SQL;
    • доступ посредством объектной модели через объектно-реляционный адаптер JPA (Java Persistence API).

    На практике приложения используют комбинацию этих двух способов доступа. Для изменения данных и чтения одиночных объектов часто используется JPA, а для сложных отчетов и выборок — SQL-запросы, выполняемые напрямую через JDBC-соединение или посредством специальных входов в JPA (так называемые native queries).

    Видится целесообразным в качестве унифицированного интерфейса доступа зафиксировать именно эти два способа в совокупности. При этом необходимо, как было указано выше, явно ограничить используемый в прямых запросах диалект SQL некоторым «унифицированным» вариантом, поскольку JDBC и JPA native queries позволяют выполнять произвольные запросы в синтаксисе произвольной СУБД.

    Конструктивная реализация модуля DAL для Java

    Итак, модуль DAL для доступа Java-приложений к РСУБД должен предоставлять интерфейсы JPA и JDBC, но при этом ограничивать использование SQL только его «унифицированным» вариантом, чтобы при необходимости обеспечить максимально оперативный перевод на другую РСУБД.

    Разработку модуля с такими требованиями можно было бы произвести самостоятельно, но оптимальный вариант — использовать для этого готовые программные компоненты с близкой функциональностью. В нашей компании при реализации DAL в качестве такого компонента после анализа ряда имеющихся готовых продуктов был выбран продукт JBoss Teiid, изначально предназначенный для федерирования (виртуализации) доступа к данным в масштабах предприятия (рис. 8).

    Рис. 8. Конструктивная реализация модуля DAL для Java

    Описанным выше требованиям DAL соответствуют следующие функции и свойства JBoss Teiid:

    • предоставление интерфейса JPA для приложений Java;
    • предоставление интерфейса JDBC для приложений Java;
    • использование собственного унифицированного диалекта SQL (на основе стандарта SQL-99);
    • трансляция собственного диалекта SQL в специфические диалекты поддерживаемых БД;
    • наличие коннекторов к большинству используемых РСУБД и простая расширяемость;
    • возможность работы как в режиме встроенного модуля, так и в режиме сетевого сервиса;
    • открытые исходные коды (Open Source), возможность бесплатного использования в коммерческих целях, развитое сообщество и примеры внедрения в крупных предприятиях.

    Кроме того, использование Teiid открывает следующие дополнительные возможности:

    • объединение баз данных путем создания так называемой «виртуальной БД» (virtual DB, VDB) в настройках с помощью визуального дизайнера. Подобная «виртуальная БД» ассоциируется с реальными средствами хранения (не только реляционными);
    • эффективное выполнение «кросс-запросов» — SQL-запросов к «виртуальной БД», которые автоматически транслируются в SQL-запросы к реальным БД;
    • кеширование результатов запросов к «виртуальной БД».

    Примеры использования DAL

    В рамках изучения возможностей миграции на PostgreSQL наша компания провела пилотный проект по переводу одной из ИТ-систем с Oracle на эту СУБД. Объектом стала расчетная бэк-офисная система, построенная по принципу трехзвенной архитектуры. Большая часть бизнес-логики (основные расчеты) ИТ-системы находилась на уровне сервера приложений, часть логики (бухгалтерский учет) — в хранимых процедурах Oracle. При проектировании данной ИТ-системы в архитектуру изначально был заложен принцип доступа к данным через Data Access Layer. Этот слой был построен на основе технологии JPA с реализацией Hibernate.

    Поскольку миграцию нужно было провести в сжатые сроки и перенос логики компонента учета на PostgreSQL занял бы значительное время, решили сначала реализовать промежуточный вариант — гибридное хранение данных одновременно в Oracle и PostgreSQL. В Oracle осталась логика учета и необходимые для нее таблицы, а в PostgreSQL мигрировали остальные данные приложения. Перенос учетной части на PostgreSQL запланировали на второй этап миграции.

    Для организации гибридного доступа было подготовлено решение на основе JBoss Teiid: создана «виртуальная БД», объединившая в себе доступ к таблицам PostgreSQL и хранимым процедурам и таблицам учетной части в Oracle. Это позволило системе обращаться к двум СУБД как к единой базе. Поскольку приложение работало через DAL, все эти тонкости для него были экранированы. Также на уровне DAL были выполнены доработки по преобразованию специфичных для Oracle SQL-конструкций в поддерживаемые Teiid выражения. Эти доработки касались только работы с данными и никак не затронули бизнес-функционал системы. После выполнения доработок система успешно прошла модульное и функциональное тестирование.

    Техническим подробностям миграции баз данных с Oracle на PostgreSQL был посвящен недавний пост моего коллеги Максима Трегубова.

    Также подход организации доступа к данным через DAL сыграл положительную роль при модернизации ряда приложений нашей компании. В ходе модернизации различные журналы работы приложений (журналы аудита, взаимодействия с внешними системами и др.) были перенесены в архивное хранилище на основе Hadoop. Остальные данные приложений остались в оперативной реляционной СУБД. Так как доступ к данным журналов осуществлялся через отдельный компонент со своим API, замена средства хранения не повлияла на остальную функциональность приложения и не потребовала существенных доработок.

    Что такое код asp accesssource

    Этот текст предназначен для тех, кто никогда не имел дела с ASP и вообще смутно себе представляет возможности программирования на стороне сервера. Я ставил себе задачу создать у читателя общее представление о предмете. Отдельные неточности при этом менее важны — пожалуйста, громко не ругайтесь.

    Общие сведения

    ASP (Active Server Pages) – это мощная технология от Microsoft, позволяющая легко разрабатывать приложения для WWW. ASP работает на платформе Windows NT и IIS (Internet Information Server), начиная с версии 3, хотя вроде есть реализации на других платформах. ASP – это не язык программирования, это внутренняя технология, позволяющая подключать программы к Web-страницам. Основа успеха ASP – простой скриптовый язык (Visual Basic Script или Java Script) и возможность использования внешних COM-компонент.

    Как это все происходит?

    Вы пишете программу и складываете в файл на сервере. Браузер клиента запрашивает файл. Файл сначала интерпретируется сервером, на выходе производится HTML-код. Этот HTML посылается клиенту. Файлы с программами имеют расширение .asp. Файлы asp – это обычные текстовые файлы, содержащие исходные тексты программ. Файлы делаются с помощью любого текстового редактора. Каталог, в котором размещены файлы asp должен иметь права на выполнение, так как сервер исполняет эти файлы, когда браузер их запрашивает. Собственно программы пишутся на любом скриптовом языке, который установлен в системе. По умолчанию поддерживаются VBScript и JavaScript. Можно доустановить другие (например, Perl). Если ничего специально не указывать используется VBScript. В дальнейшем будем ссылаться только на него. Программные фрагменты заключаются в скобки . Можно ставить открывающую скобку в начале файла, закрывающую – в конце, все что между ними – программа на Visual Basic’е.

    Какие средства есть для программирования?

    Web – нормальная среда программирования, если правильно понять, что есть что. В VBScript есть все нормальные конструкции структурного программирования (if, while, case, etc). Есть переменные (описывать не обязательно, тип явно не задается). Поддерживаются объекты. Работа с ними обычная – Object.Property, Object.Method. Есть ряд встроенных объектов (Request, Response, Session, Server, Connection, Recordset). Можно доустанавливать другие компоненты (скачивать, покупать, программировать), например для работы с электронной почтой.

    Вывод

    Понятия «экран», куда можно выводить данные нет. Все, что надо показать пользователю, выбрасывается в выходной поток на языке HTML. Браузер пользователя интерпретирует этот HTML. Для упрощения вывода существует объект Response . Вывод осуществляется с помощью метода Write .

    Так производится запись во внутренний буфер объекта Response. Когда скрипт заканчивает работу, весь буфер выдается клиенту. Надо заметить, что клиент получает «чистый» HTML, таким образом программы на ASP не зависят от клиентского ПО, что очень важно. Если внутри выводимой строки нужно использовать кавычку, кавычка удваивается. Другие методы и свойства Response позволяют управлять выводом. Так Response.Buffer регулирует, получает ли клиент данные по мере из записи в Response, или все сразу по завершении исполнения страницы. Метод Response.Redirect перенаправляет браузер на другую страницу. Чтобы им пользоваться, нельзя до него на странице использовать Response.Write.

    Программа на ASP не может явно спросить пользователя о чем-то. Она получает данные из других страниц, либо через URL. Передаваемые параметры помещаются во входной поток и доступны через объект Request . Чтобы передать переменную var в программу test.asp , надо написать:

    Чтобы из программы получить значение этой переменной, надо написать:

    Несколько переменных разделяется знаком &:

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

    Так это выглядит:

    При этом пользователь увидит форму из одного поля ввода (var1), в нем будет значение по умолчанию «default». Второе поле (var2) будет невидимо и будет передавать всегда фиксированное значение «var2value». Кнопка «Submit Form» завершает заполнение формы и передает все переменные на test.asp (action). Если method=»get», переменные передаются через URL (test.asp?var1=default&var2=var2value). Если method=»post», передаются вместе с запросом так, что внешне передача переменных не заметна. В вызываемой программе безразлично, какой метод изпользовался (почти). Если у вас нет специальных аргументов за метод GET, используйте метод POST.

    Формы

    Формы HTML используются для организации диалога с пользователем. Поддерживаются стандартные элементы управления. Все многообразие задается немногими тэгами:

    • INPUT (с параметром TYPE=)
    • SELECT
    • TEXTAREA

    Описание – в документации по HTML.

    Взаимосвязь между отдельными страницами

    Обычно сервер WWW не хранит состояние приложения, т.е. все запросы взаимонезависимы, и нет стандартного способа понять, что несколько запросов пришли от одного и того же пользователя. Но это очень нужно для разработки полноценных приложений и является одной из главных проблем разработки Web-приложений.

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

    ASP, используя cookies, предоставляет программисту более простое средство — объект Session (сессия). Сессия стартует, когда новый пользователь обращается к любому asp-файлу приложения. Сессия заканчивается при отсутствии активности пользователя в течение 20 минут, либо по явной команде. Специальный объект Session хранит состояние сессии. Туда можно записывать переменные, которые доступны из любой страницы в этой сессии. Записать данные в этот объект можно просто:

    Считать потом еще проще:

    Сессия, таким образом, – это еще один метод передачи данных между страницами. Одна страница пишет данные в сессию, другая – берет потом оттуда.

    Наряду с объектом Session существует объект Application . Если сессия создается для каждого нового пользователя, до Application существует в единственном экземпляре, и может использоваться всеми страницами приложения.

    Управление приложением

    Программисту предоставляется возможность реагировать на 4 события: старт/стоп приложения и старт/стоп каждой сессии. Для реализации этих событий предназначен файл global.asa , который должен располагаться в корневом каталоге приложения. Вот его примерный скелет:

    Нужно «просто» вписать Ваш код на соответствующее место. Нужно заметить, что отлаживать код для global.asa довольно непросто, так как он выполняется при очень специфических обстоятельствах (к примеру при старте или остановке сервера).

    Использование внешних компонент

    Если на сервере установлены дополнительные компоненты, их можно использовать из ASP. Стандартные объекты (например из библиотек ADO (Connection и Recordset) и Scripting (Dictionary, FileSystemObject)) доступны всегда. Установка новой компоненты обычно состоит в копировании dll-файла в каталог на сервере и ее регистрации с помощью программы regsvr32.exe. [В COM+ используется своя процедура инсталляции объектов, это однако не влияет на использования объектов.]

    Создать экземпляр объекта можно так:

    Class.Object указываются в документации на компоненту. В переменной var запоминается ссылка на созданный экземпляр объекта. Когда объект не нужен, ссылку нужно обнулить с помощью команды:

    Пожалуйста всегда обнуляйте все ссылки на объекты, когда они больше не нужны. Теоретически это должно происходить автоматически при завершении процедуры/страницы, однако в стандартной сборке мусора есть определенные «проблемы».

    В остальном использование компоненты зависит от самой этой компоненты.

    Работа с базами данных

    Из ASP можно легко и просто работать с любыми базами данных. Это делается через две промежуточные технологии: ODBC и ADO.

    ODBC позволяет организовать доступ к любым базам данных через унифицированный интерфейс с помощью языка SQL. Специфика конкретных СУБД учитывается при помощи специальных драйверов БД. Такие драйверы существуют для всевозможных СУБД (в частности SQL Server, Oracle, Access, FoxPro). Поддержка ODBC обеспечивается на уровне операционной системы Windows (NT). Настройка – через Control Panel/ODBC. Базовым понятием является источник данных или data source. Источник данных – это совокупность сведений о базе данных, включая ее драйвер, имя компьютера и файла, параметры. Чтобы пользоваться базой надо создать источник данных для нее. Важно, чтобы источник данных был «системным», в отличии от «пользовательского». После этого надо лишь знать имя источника данных. [В настоящее время ODBC отступает перед натиском технологии OLE DB. На практике это однако практически ничего не изменяет. Вместо имени источника данных нужно использовать Connection String, в которой указывается имя ODBC-драйвера и все его параметры.]

    ADO – это совокупность объектов, доступных из ASP, позволяющих обращаться к источнику данных ODBC [или OLE DB]. Фактически нужны лишь 2 объекта – Connection , представляющий соединение с базой данных и Recordset , представляющий набор записей, полученный от источника. Сначала необходимо открыть соединение, потом к нему привязать Recordset, потом, пользуясь методами Recordset’а, обрабатывать данные. Вот пример:

    Если команда SQL не возвращает данных, recordset не нужен, надо пользоваться методом Conn. Execute (SQL_COMMAND).

    Если Вы хотите вызывать хранимые процедуры сервера БД с параметрами, нужно воспользоваться объектом Command , который в свою очеред содержит объекты Parameter .

    Методики программирования, советы


    Описание переменных

    VBScript — очень нетребовательный к программисту язык. Так он не требует описывать переменные и не содержит явных типов данных. Все переменные принадлежат одному типу Variant . Из-за отсутствия описаний могут произойти очень трудно обнаруживаемые ошибки. Одна опечатка может стоить полдня поисков.

    Однако, есть возможность явно потребовать описания переменных. Для этого первой строкой в ASP-файле нужно написать Option Explicit . После этого обращение к переменной, которая не была объявлена с помощью Dim , вызывает ошибку с указанием номера строки.

    Кстати, где расположены описания Dim в процедуре — совершенно не важно. Они могут стоять как до использования переменной, так и после, и даже в цикле. Видимо они отрабатываются препроцессором. Явно задать тип переменной с помощью Dim Var as Typ , как в Visual Basic, все равно нельзя.

    Чередование ASP/HTML

    Если нужно выдать большой кусок HTML, можно не пользоваться Response.Write. Если в asp-файле встречается кусок текста вне скобок , он трактуется просто как HTML, который надо вывести. Пример:

    Обработка ошибок

    Для отслеживания ошибок используется специальный объект Err . Он устанавливается в ненулевое значение, если предыдущая команда породила ошибку. Ее можно проверять с помощью If, и таким образом реагировать на ошибки. Чтобы из-за ошибки не прерывалось выполнение программы, в начале нужно включить команду

    Включение других файлов

    Можно выносить повторяющийся код в отдельный файл, и подключать к разным другим по мере необходимости с помощью команды include . Это очень удобно, если вы хотите вынести повторяющийся код в отдельный файл и использовать снова и снова в разных страницах:

    Важно: все includes в тексте отрабатываются до исполнения файла. Т.е. даже если include стоит внутри if, то сначала будут включены все includes во всех ветках, и только потом, во время исполнения, будет принятно решение, какую ветку выполнять. Т.е. следующий код не дает условного включения файлов:

    Обработка форм

    Если надо что-то спросить у пользователя и на основании этого что-то сделать, в простейшем случае создается два файла: один с формой, второй – с ее обработчиком. Обработчик выполняет все действия. Пример:

    Рекурсивная обработка форм

    Удобный метод состоит в том, чтобы сбор данных и обработку осуществлял один и тот же файл. Для этого пишется asp, в котором есть разные разделы. Специальная переменная отвечает за выбор раздела при запуске. Пример:

    Переменные HTTP

    Запрос от браузера, кроме запрашиваемой страницы несет еще некоторые данные. Эти данные, например, IP-адрес клиента, доступны через специальные переменные объекта Request. IP-адрес – Request(«REMOTE_ADDR»). Другие — см.документацию (ASPSamp\Samples\srvvar.asp).

    Переадресация

    Очень легко написать на ASP скрипт, который будет производить некоторые расчеты, и в зависимости от результатов переадресовывать браузер на разные URL (например, подставлять нужный баннер). Делается это так:

    Только надо следить, чтобы до выполнения команды redirect ничего не было записано в Response (даже коментарии HTML).

    Электронная почта

    Одна из часто встречающихся задач – отправить электронную почту с Web-страницы. На первый взгляд, можно просто написать

    Но это приводит к тому, что при отправке формы делается попытка на клиентской машине запустить почтовую программу и создать новое сообщение с данными формы. Если это не получается (почтовая программа не настроена, пользователь не отправил почту, и т.д.) — письмо и не будет отправлено. Гораздо надежнее работает серверное решение.

    Для этого существуют внешние компоненты, есть и бесплатные. Например, компонента Jmail от Dimac. Все, что для нее нужно – это адрес SMTP-сервера. Вот пример ее использования:

    Хостинг в Европе для новичков (от 25 руб/мес) и VIP-хостинг для профессионалов (от 1000 руб/мес)

    Скидка 25% на все тарифы хостинга по промокоду STDCITF

    Илон Маск рекомендует:  Защита почты от спама
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL