Asp структура объектов


Какая структура объекта для дерева иерархии в asp.net mvc-приложении

Я просто не могу решить, какой подход выбрать, чтобы иметь возможность иметь иерархическое дерево с частично разными типами объектов. Это приложение Asp.Net MVC, и я сначала использую код инфраструктуры сущности. Мое иерархическое дерево — это структура информационного контента. Каждый узел в дереве может быть одного из трех реализованных типов.

На данный момент Table-per-type (TPT), по-моему, является моим лучшим выбором дизайна, но что вы думаете? Любые недостатки с моим выбором дизайна? Например, если базовый класс имеет поле дискриминатора?

Чтобы проиллюстрировать, ниже псевдо пример моего текущего проекта.

С уважением, Клас Эриксон

Например, если базовый класс имеет поле дискриминатора?

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

На данный момент Table-per-type (TPT), по-моему, является моим лучшим выбором дизайна, но что вы думаете?

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

TPH предоставит вам максимальную производительность, потому что все данные выбираются одним запросом без каких-либо JOINS, но для свойств в подклассах требуются свойства Nullable в базе данных. Также TPH нарушает третью нормальную форму (цена за производительность)

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

Asp структура объектов

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

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

С уважением,
команда разработчиков eManual.ru

Азы ADO и ASP

FileArea.co.il Азы ADO и ASP
Азы ADO и ASP Майкл Оути
Листинг 1. Применение объекта ADO Соединение
Листинг 2. Использование объекта ADO Набор записей
Листинг 3. Применение объекта ADO Набор записей для вставки строк
Листинг 4. Обработка ошибок ASP и ADO Основы интерактивного WEB-дизайна

Программный продукт ASP, название которого в переводе означает Активные страницы сервера (Active Server Pages), обеспечивает написание сценариев серверной части для информационных WEB-серверов компании Microsoft, IIS (Internet Information Server). Впервые корпорация Microsoft ввела ASP в версии IIS 3.0, и продолжила дальнейшую разработку этого продукта в IIS 4.0. ASP представляет собой гибкое динамичное средство создания WEB-страниц и позволяет применять любой язык написания сценариев, удовлетворяющий стандарту ActiveX. Как правило, ASP использует комбинацию из HTML и встроенного VBScript. IIS включает в себя сервер автоматизации OLE, который исполняет VBScript и посылает результаты реализации сценария в формате HTML клиенту, который может иметь только браузер. Так как сценарии ASP выполняются на сервере, то ASP способен работать с любым WEB-браузером, поскольку браузер получает лишь поток страниц HTML. Понимание того, каким образом объекты ADO работают с ASP, и в особенности того, как лучше применять объекты ADO для поиска и модификации данных, может превратить создание динамических WEB-страниц в легкое и приятное занятие.

Как работает ASP

Рисунок 1. Обзор взаимодействия ASP и HTML
1- WEB-сервер
2- Клиент WEB
3- Активный сценарий
4- пример .ASP

На рисунке 1 изображено, как ASP комбинирует сценарий ActiveX и команды HTML для того, чтобы получить динамическую страницу HTML. Как следует из рисунка, сценарии ASP отличаются от сценариев, базирующихся на браузерах. В традиционных сценариях, основывающихся на браузерах, WEB-сервер посылает страницу HTML, содержащую сценарий ActiveX в браузер клиента, который и отвечает за выполнение сценария. Подход, при котором основной акцент делается на клиентской части приложения, возлагает на нее дополнительный груз обязанностей, что может привести к возникновению проблем, если клиентский браузер не будет в состоянии выполнить сценарий. Напротив, страницы ASP исполняются на WEB-сервере IIS. В ходе исполнения страницы сервер напрямую посылает клиенту команды HTML и все клиентские сценарии, содержащиеся на странице ASP. Но как только сервер доходит до команды серверного сценария ASP, то он исполняет этот сценарий и передает клиенту в форме HTML только полученные в качестве результата выходные данные. Клиент, действия которого сводятся к использованию браузера, не видит разницы между потоком страниц HTML, порождаемым сценарием ASP, и потоком HTML, посылаемым статичными WEB-страницами. Таким образом, написание сценариев для серверной стороны с помощью ASP создает WEB-страницы, которые выступают в качестве исполнителей сценариев. Тот факт, что ASP генерирует только поток страниц HTML, обеспечивает независимость от типа браузера клиента. В силу того, что сервер IIS интерпретирует страницы ASP «на лету», ASP служит идеальным средством для встраивания результатов обработки интерактивных запросов к базе данных в WEB-страницы. Эти возможности обеспечиваются доступом к базе данных SQL Server через ADO непосредственно со страниц ASP.

Будь то доступ из Internet или из местной сети Intranet, клиенты применяют протоколы HTTP и TCP/IP для связи с WEB- сервером IIS. Когда WEB-клиент запрашивает страницу ASP, WEB-сервер IIS сценарии, находящиеся на этой странице. Для того чтобы получить доступ к базе данных SQL Server, сценарий ASP открывает соединение с SQL Server с помощью одного из объектов Соединение, Команда или Набор записей. Затем использует этот объект для передачи в сервер запроса на доступ к данным. SQL Server может размещаться на том же компьютере, что и WEB-сервер IIS. Однако в силу того, что часто SQL Server используется одновременно сразу несколькими различными приложениями, удобнее разместить его на отдельном компьютере, и обеспечить связь с ним через локальную сеть. После того как ядро SQL Server закончит обработку запроса, оно возвращает результаты объекту ADO из сценария ASP. Затем IIS продолжает исполнять сценарий ASP и отсылает поток страниц HTML обратно клиенту. Поэтому обязательно должно существовать сетевое соединение между WEB-сервером IIS и сервером баз данных SQL Server. Кроме того, на WEB-сервере необходимо установить поставщик OLE DB и библиотеки DLL на период прогона ADO.

Использование объектов ADO на страницах ASP

При использовании ADO приложение первым делом пытается применить объекты Соединение, Команда или Набор записей для установления соединения с SQL Server. Объект Соединение следует употреблять для того, чтобы открыть соединение ADO явным образом. Объекты Команда и Набор записей позволяют сделать то же самое динамически. После установления соединения приложение ASP может выполнять команды ADO такого же типа, что и стандартное приложение, написанное на Visual Basic (VB). Эти команды включают исполнение хранимых процедур, открытие и просмотр набора записей, вставку, обновление и удаление данных.

Для подключения страницы ASP к серверу баз данных SQL Server ADO может применять поставщик OLE DB как для ODBC, так и для SQL Server. Поставщик OLE DB для ODBC позволяет использовать структуру объекта ADO с большинством существующих драйверов ODBC. Но поставщик OLE DB для SQL Server дает возможность подключиться только к SQL Server. Однако с объектами ADO Соединение, Команда и Набор записей возможно применять любой из упомянутых поставщиков. Листинг 1 (написанный на языке VBScript) показывает, как применить поставщик OLE DB для ODBC в целях установления соединения с SQL Server.

Первое действие, проводимое в листинге 1, это объявление трех переменных, которые будут содержать имя компьютера, на котором размещен SQL Server, и информации для аутентификации SQL Server. Затем сценарий декларирует переменную cn, которую он в последствии будет использовать для объекта ADO Соединение. После объявления в сценарии рабочих переменных метод Формировать (Form) объекта ASP Запрос (Request) присваивает значения всем этим переменным.

Следующим шагом метод Создать объект (CreateObject) объекта ASP Сервер (Server) создает новый объект ADO Соединение (Connection), который затем присваивается введенной ранее переменной cn. Метод Создать объект (CreateObject) способен порождать экземпляры объектов СОМ. Данный пример иллюстрирует создание экземпляра объекта Соединение ADODB (ADODB.Connection), но его можно аналогичным образом применять и для других структур объектов СОМ, например, для SQL-DMO или Active Directory. (Более подробную информацию об объектах ASP можно найти во врезке «Модель объектов ASP»).


После этого сценарий присваивает значение строки соединения OLE DB свойству Строка соединения (ConnectionString) объекта Соединение, хранящегося в переменной cn. Это позволяет установить соединение без указания имени источника данных, DSN (Data Source Name). В силу того, что спецификация поставщика OLE DB проводилась без ключевого слова PROVIDER, по умолчанию берется поставщик OLE DB для ODBC. Ключевое слово DRIVER идентифицирует тот драйвер, который предполагается применять в дальнейшем. За ключевым словом SERVER указывается имя компьютера, содержащего SQL Server, с которым намереваются установить соединение. За ключевыми словами UID и PWD содержится информация, необходимая для входа в систему. Ключевое слово DATABASE определяет, что в роли базы данных, используемой по умолчанию, будет выступать база данных pubs. После того как будет присвоено значение строки соединения свойству Строка соединения (ConnectionString) объекта Соединение (Connection), его метод Открыть (Open) установит соединение с SQL Server, удовлетворяющее всем значением параметров, заданных в сценарии.

Поиск данных с помощью объекта ADO Набор записей ()

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

Листинг 2 демонстрирует применение объекта ADO Набор записей (Recordset) на странице ASP. Первая часть сценария во многом напоминает простой пример установления соединения, приведенный в листинге 1. В сценарии сначала декларируются рабочие переменные, а затем им присваиваются значения. После этого по сценарию создается объект Соединение (Connection), и вслед за ним объект ADO Набор записей (Recordset). На следующем шаге сценария строка соединения присваивается объекту ADO Соединение (Connection), и затем для установления связи с SQL Server вызывается метод Открыть (Open). В соответствии со сценарием свойству Активное соединение (ActiveConnection) объекта Набор записей (Recordset), хранящегося в переменной rs, передается значение объекта активного соединения, cn, и выполняется метод Открыть (Open) объекта Набор записей (Recordset). Первый параметр метода Открыть (Open) содержит простой оператор SQL, который выбирает все столбцы и строки из таблицы stores базы данных Pubs.

После того как сценарий возвращает результаты обработки запроса, страница ASP создает таблицу HTML, содержащую шесть столбцов. После этого по сценарию столбцы получают заголовки. Сценарий использует стандарт HTML для построения всех заголовков столбцов. Внутри тела таблицы HTML в соответствии с меткой А листинга 2 программный код VBScript организует цикл Do Until. Этот цикл обрабатывает содержимое объекта Набор записей (Recordset), находящегося в переменной rs. Когда сценарий доходит до конца объекта Набор записей (Recordset), свойство rs.EOF получает значение Истина, и цикл завершается.

Встроенный в страницу ASP сценарий присваивает значения всем столбцам исходя из имени столбца объекта ADO Набор записей (Recordset). В рассматриваемом примере имя столбца, происходящее из таблицы Stores базы данных Pubs идентифицирует каждый пункт коллекции Поля (Fields). Расположенная вслед за этим часть кода VBScript реализует метод MoveNext для перехода к следующей строке в объекте Набор записей (Recordset). Затем оператор Цикл (Loop) возвращает управление в начало цикла Do Until. Когда этот цикл прочитает последнюю строку набора записей, цикл заканчивается и объекты Набор записей (Recordset) и Соединение (Connection), хранившиеся соответственно в переменных rs и cn, закрываются. Результаты работы этой страницы ASP можно видеть на экране 1.

Экран 1. Просмотр простого объекта ADO Набор записей
Изменение данных средствами ADO

ASP и ADO можно применять не только для динамической выдачи WEB-страниц, но и в целях создания WEB-страниц для ввода данных. Такая возможность позволяет создавать основанные на WEB приложения с использованием баз данных, обладающие таким же набором функций работы с базами данных, что и стандартные приложения, разработанные в соответствии с архитектурой клиент-сервер. Объекты ADO Набор записей (Recordset), которые становятся доступными на страницах ASP, предоставляют тот же перечень услуг, что и приложения, написанные на Visual Basic. Как показывает следующий пример, их можно применять для ввода данных. Кроме того, их можно использовать для изменения или удаления данных. Все остальные возможности ADO, такие как способность запускать подготовленные заранее операторы SQL или хранимые процедуры, также имеют место.

В целях внесения изменений в данные возможности, предоставляемые ASP и ADO, можно комбинировать различными способами. К примеру, можно было бы создать страницы ASP, которые будут поддерживать изменяемые объекты ADO Набор записей (Recordset). Они, в свою очередь, смогут применять методы Добавить новый (AddNew), Обновить (Update) и Удалить (Delete) для модификации данных в базах SQL Server. Помимо этого, возможно применять ADO для выполнения как динамических,, так и подготовленных заранее с помощью языка SQL операций модификации данных. Код приведенный на листинге 3, иллюстрирует, каким образом можно было бы добавлять строки в объект Набор записей (Recordset), который создается с использованием курсора Keyset.

Листинг 3 представляет дополнительные технические приемы построения WEB-приложений с помощью ASP. Первая строка является оператором VBScript Option Explicit, который указывает, что все переменные в коде VBScript перед их применением будут явным образом продекларированы. Как и в стандартном Visual Basic, в VBScript предусмотрено автоматическое использование новых переменных, без их предварительного объявления. На первый взгляд это свойство может показаться очень удобным, но в реальности оно служит довольно эффективным способом ввести в разрабатываемое приложение ASP множество трудно находимых коварных ошибок.

Следующим шагом оператором #include вводится файл adovbs.inc. Оператор #include представляет очень удобный путь копирования обычно употребляемых констант на страницы ASP. В данном случае файл adovbs.inc включает все константы, которые обычно содержит структура объекта ADO. Подключение этого файла дает возможность записывать константы в виде adChar и adKeyset, а не в виде значений, представляемых этими константами. Применение констант делает код удобно читаемым и легким в сопровождении. Хотя включение файла является хорошим приемом для средств разработки вообще, но в случае, когда для создания ASP- приложений используется такой инструмент, как Visual InterDev (VID), можно просто добавить в среду разработки VID ссылку на объектную библиотеку ADO. Подобное добавление устраняет необходимость включения файла в ASP- приложения. Чтобы добавить ссылку на ADO в проект VID следует выбрать в меню Проект (Project) и Ссылки проекта (Project References), а затем выбрать в списке доступных ссылок библиотеку Microsoft ActiveX Data Library 2.0.

В соответствии со сценарием VBScript, приведенным на листинге 3, сначала уничтожается, а затем воссоздается заново таблица в базе данных pubs, после чего в эту таблицу вставляются 50 строк и полученное содержимое показывается на WEB-странице. Но прежде чем выполнить все это, в том месте сценария, которое отмечено в листинге 3 буквой А, инициируется обработчик ошибок VBScript. В этом примере оператор On Error применен для того, чтобы обойти любые ошибки, которые могут произойти, к примеру, при попытке удалить несуществующую таблицу из указанной базы данных. В следующем разделе будет более подробно рассмотрено использование обработчика ошибок.

На следующем шаге сценарий ставит в соответствие переменной cn объект ADO Соединение (Connection). Затем метод Исполнить (Execute) объекта Соединение (Connection) выполняет два динамических оператора SQL. Первый уничтожает таблицу Department, а второй создает таблицу Department заново. После создания таблицы Department сценарий устанавливает в свойстве Активное соединение (ActiveConnection) объекта Набор записей (Recordset), указанного в переменной rs, ссылку на этот объект Соединение (Connection). Затем метод Открыть (Open) объекта Набор записей (Recordset) создает обновляемый набор записей. Константа adOpenKeyset определяет, что этот объект будет относиться к обновляемому типу Keyset, а константа adLockOptimistic предписывает использование оптимистического типа блокировки записей.

Цикл For Next вставляет 50 строк в таблицу Department. В этом цикле метод Добавить новый элемент (AddNew) создает буфер для хранения новой строки, после чего цикл присваивает значения объектам ADO Поле (Field). Каждый объект коллекции Поле (Field) идентифицируется по названию столбца. Значение счетчика цикла присваивается столбцу Dep_Id, содержащему идентификатор отдела, а в столбец Dep_Name с названием отдела помещается литерал Department и представленный в виде символьной строки номер отдела, равный значению счетчика цикла. Цикл вставляет новую строку в базовую таблицу в ходе исполнения метода Обновить (Update) объекта Набор записей (Recordset).

После того как сценарий вставит 50 строк в таблицу Department, метод Перейти к первой () перемещает курсор в начало объекта Набор записей (Recordset). Затем содержимое объекта Набор записей (Recordset) представляется в виде таблицы HTML, применяя ту же технику, что и в описанном ранее примере с запросом. На экране 2 показана WEB- страница, которая создается при запуске данной страницы ASP.

Экран 2. Просмотр записей, введенных на страницу ASP
Обработка ошибок ASP и ADO

Очень важно перехватывать ошибки, возникающие во время работы приложения: если вдруг в результате некорректного функционирования WEB-приложения системой будет сгенерировано сообщение об ошибке, то работа WEB- приложения будет немедленно прекращена. Для того чтобы предусмотреть на странице ASP специальную часть сценария VBScript, отвечающую за обработку возникающих ошибок, применяется оператор On Error. К сожалению, оператор On Error не обладает всей полнотой возможностей обработчика ошибок VB, который позволяет перейти в отдельную секцию кода для обработки информации об ошибке. Оператор On Error, входящий в VBScript, предоставляет только следующую альтернативу: либо перейти к следующей операции (Resume Next), либо вообще отключить обработку ошибок. Этот оператор не дает возможности перейти к другим секциям кода. Оператор On Error использует структуру объекта ADO для того, чтобы поместить ошибки, возникающие во время выполнения WEB-приложения на базе страниц ASP, в коллекцию объекта ADO Ошибка (Error). Коллекцию ошибок ADO можно обрабатывать с целью сбора дополнительной информации о том, какие ошибки встречаются при эксплуатации вашего приложения. Фрагмент кода, приведенный на листинге 4, показывает, как использовать обработчик ошибок VBScript и каким образом извлекать информацию из объекта ADO Ошибка (Error).

Обработку ошибок в листинге 4 обеспечивает оператор On Error. Затем для создания локального объекта ADO Соединение (Connection) по сценарию используется объект Соединение (Connection), который хранился в объекте ASP Сессия (Session). После этого в сценарии используется метод Выполнить (Execute) объекта ADO Команда (Command) применительно к заведомо неправильному имени таблицы. Поскольку обработка ошибок разрешена, программа переходит к следующему оператору.

Проверка свойства Счетчик (Count) коллекции объектов Ошибка (Error) позволяет найти ошибки ADO. Если значение счетчика больше нуля, значит, объект ADO столкнулся с какой- либо ошибкой во время исполнения. Извлечь информацию об ошибках ADO можно путем итеративного просмотра коллекции объектов Ошибка (Error). Пример на листинге 4 использует цикл For Each для обработки элементов коллекции ошибок объекта ADO Соединение (Connection). Свойства Номер(), Источник () и Описание () становятся доступными в форме текстов HTML. Экран 3 представляет страницу с результатами обработки ошибок. (Обратите внимание на то, что рассмотренный пример является не более чем демонстрацией подхода. В реальном приложении необходимо обрабатывать условия возникновения ошибок в коде приложения. При этом следует избегать вывода ошибок на браузер конечного пользователя).

Экран 3. Обработка ошибок ASP с помощью ADO

В том случае, когда на WEB-страницу должны выводиться только статичные данные, целесообразно применять Мастер WEB-приложений (), входящий в состав SQL Server. Он поможет легко и быстро преобразовать информацию базы данных SQL Server к виду WEB-страницы формата HTML. Если же необходимо создать по-настоящему интерактивное приложение, способное динамически представлять и обновлять данные, лучше всего применять комбинацию ASP и ADO, что позволит подключить вашу базу данных SQL Server к сети WEB. Использование ADO и ASP дает возможность создавать WEB-приложения, обладающие теми же функциями, что и их предшественники, выполненные в соответствии с традиционной архитектурой клиент-сервер.

В основу этой статьи лег адаптированный материал из книги Майкла Оути и Поля Конте «Руководство по разработке для SQL Server 7.0».

Майк Оути (mikeo@teca.com) работает старшим техническим редактором в журналах SQL Server Magazine и Windows NT и является президентом компании ТЕСА. Эта компания занимается разработкой программного обеспечения и консалтингом; находится в Портленде, штат Орегон.

Модель объектов ASP

Информационный сервер Интернет, IIS (Internet Information Server), разработанный корпорацией Microsoft, вводит Активные серверные страницы, ASP (Active Server Pages), в качестве автоматического сервера OLE, обладающего иерархической структурой объекта. На рисунке А представлена модель объекта ASP. Первичным объектом в программной модели ASP является объект Контекст сценария (ScriptingContext), который обеспечивает взаимодействие с браузером клиента. Поскольку объект Контекст сценария (ScriptingContext) всегда доступен приложениям ASP, то нет необходимости в явном виде делать на него ссылку. Объект Контекст сценария (ScriptingContext) содержит шесть основных объектов ASP: пять встроенных объектов и объект Контекст объекта (ObjectContext). К пяти встроенным объектам относятся: объект Приложение (Application), объект Запрос (Request), объект Сервер (Server), объект Сессия (Session) и объект Отклик (Response).

Все активные WEB-сессии применяют объект Приложение (Application) для того, чтобы все пользователи могли одновременно обращаться к информации приложения ASP. Объект Приложение (Application) включает две коллекции: Содержание (Context) и Статические объекты (StaticObjects). Каждый объект Содержание (Context) соответствует какому- либо пункту, для включения которого в WEB-приложение были использованы команды ActiveX. Коллекция Статические объекты (StaticObjects) содержит все объекты, для включения которых в WEB-приложение применялись ярлыки HTML . Кроме того, объект Приложение (Application) может также содержать определяемые пользователем объекты, которые были созданы этим WEB-приложением и предназначены для коллективного применения.

Объект Запрос (Request) получает запросы от клиентов сети WEB. Объект Запрос (Request) может вместить всю информацию содержащуюся в форме, плюс сведения о текущем пользователе. Этот объект включает несколько коллекций, каждая из которых представляет различные информационные наборы, которые могут возвращаться клиентам WEB в ответ на их запросы. Каждый объект Сертификат клиента (ClientCertificate) в одноименной коллекции представляет поле сертификата, которое возвращает клиент сети WEB и которое в дальнейшем служит его идентификатором. Коллекция (Cookies) состоит из элементов, каждый из которых содержит немного информации о пользователе WEB. Коллекция Формы (Forms) включает набор объектов, каждый из которых представляет какую-нибудь форму HTML. Коллекция Строка запроса (QueryString) содержит набор добавляемых аргументов URL, а коллекция Переменные сервера (ServerVariables) представляет собой набор переменных, описывающих серверное окружение.


Объект Сервер (Server) применяется для создания объектов OLE, которые было бы желательно иметь в WEB-приложении. Например, метод Создать объект (CreateObject) объекта Сервер (Server) генерирует объекты Соединение (Connection) и Набор записей (Recordset), обеспечивающих доступ к базам данных SQL Server.

Объект Сессия (Session) поддерживает информацию, относящуюся к текущей сессии в сети WEB. Объект Сессия (Session) во многом похож на объект Приложение (Application), но имеет отличие от него. В то время как объект Приложение (Application) принадлежит всем пользователям сети WEB, объект Сессия (Session) относится только к текущей сессии. Коллекция объектов Содержание (Context) объекта Сессия (Session) включает все пункты, которые добавлялись в WEB-сессию с помощью команд сценария. Объект Контекст объекта (ObjectContext) обеспечивает доступ к контексту текущего объекта. Как правило, он порождает экземпляры объектов MTS или контролирует транзакции базы данных.

Объект Отклик (Response) записывает информацию в виде потока страниц HTML и отсылает ее в браузер клиента. Объект Отклик (Response) также поддерживает коллекцию, состоящую из объектов, содержащих сведения, которые могут быть записаны в систему клиента. Они в последствии могут быть прочитаны объектом Запрос (Request).

Рисунок А. Модель объектов ASP
1 — Контекст сценария
2 — Приложение
3 — Содержание
4 — Статические объекты
5 — Определяемые пользователем объекты
6 — Контекст объекта
7 — Запрос
8 — Формы
9 — Строка запроса
11 — Сервер
12 — Сессия
13 — Отклик

Структура проекта ASP.NET MVC

Пытаюсь понять, как правильно писать приложения на ASP.NET MVC. Во всех примерах, что я видела, всегда создается одно представление для одной страницы. А представлению соответствует одна модель. А если у меня на странице должно быть несколько элементов, у которого своя модель и свое (единообразное) представление. Например, несколько форм с одной кнопкой, которая обрабатывается одинаково. Т.е, такой массив связок модель-представление? Можно ли (правильно ли) размещать их на 1 странице? И какой при этом синтаксис?

2 ответа 2

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

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

Думаю примеры излишни, все и так предельно просто. Что касается того, правильно/неправильно, приведите пример кода представления, можно будет предметно прокомментировать.

Принципы работы и структура Web-приложений на основе ASP.NET

Краткое описание архитектуры ASP.NET и .NET Framework

ASP . NET — это платформа для создания Web-приложений и Web-сервисов, работающих под управлением IIS . Сегодня существуют другие технологии, позволяющие создавать Web-приложения. К ним относятся прежде всего, очень популярные сегодня языки PHP и PERL, более старая и менее популярная технология CGI и т. д. Однако ASP . NET отличается от них высокой степенью интеграции с серверными продуктами, а также с инструментами Microsoft для разработки доступа к данным и обеспечения безопасности. Кроме того, ASP . NET позволяет разрабатывать Web- и Windows -приложения, используя очень похожие технологические цепочки, одинаковые языки программирования, технологии доступа к данным и т. д. Более того, базовые языки программирования, с помощью которых сегодня возможна разработка Web-приложений, являются полностью объектно-ориентированными, что делает разработку исполнимой части, а также ее модификацию, обслуживание, отладку и повторное использование гораздо более простым занятием, чем в других технологиях. Существует достаточно большой перечень сильных сторон использования ASP . NET для создания сложных Web-приложений. Целью данного курса не является описание всех сильных и слабых сторон этой платформы. Более подробно об этом можно узнать на сайте http://www.microsoft.com, а также в [ 1 ] .

Заметим лишь, что ASP . NET функционирует исключительно на серверах Windows , так как требует наличия IIS . Для создания Web-приложений, не требующих IIS , а использующих, например, Web- сервер Apache и работающих на серверах под управлением операционных систем, отличных от Windows , применяются другие технологии.

Важным моментом в понимании архитектуры ASP . NET является тот факт, что она является частью инфраструктуры . NET Framework. Более подробно об архитектуре и принципах работы . NET Framework можно узнать в [ 2 ] . Так как эта тема является слишком объемной и выходит за рамки данного курса, ограничимся лишь кратким описанием инфраструктуры . NET Framework.

Архитектура .NET Framework

Как утверждает корпорация Microsoft, до 80% средств, направленных на исследования и разработки, тратится на платформу .NET и связанные с ней технологии. Результаты такой политики на сегодняшний день выглядят впечатляюще. Так, область охвата платформы .NET просто огромна. Платформа состоит из четырех групп программных продуктов:

набор языков, куда входят С# и Visual Basic .NET; набор инструментальных средств разработки, в том числе Visual Studio .NET; обширная библиотека классов для построения Web-служб и приложений, работающих в Windows и в Интернете; а также среда выполнения программ CLR ( Common Language Runtime — общеязыковая среда выполнения), в которой выполняются объекты, построенные на этой платформе;

набор серверов .NET Enterprise Servers, ранее известных под именами SQL Server 2000, Exchange 2000, BizTalk 2000 и др., которые предоставляют специализированные функциональные возможности для обращения к реляционным базам данных, использования электронной почты, оказания коммерческих услуг «бизнес-бизнес» (В2В) и т. д.;

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

новые некомпьютерные устройства, поддерживающие средства .NET, — от сотовых телефонов до игровых приставок.

Microsoft .NET поддерживает не только языковую независимость, но и языковую интеграцию. Это означает, что разработчик может наследовать от классов, обрабатывать исключения и использовать преимущества полиморфизма при одновременной работе с несколькими языками. Платформа .NET Framework предоставляет такую возможность с помощью спецификации CTS ( Common Type System — общая система типов), которая полностью описывает все типы данных, поддерживаемые средой выполнения, определяет, как одни типы данных могут взаимодействовать с другими и как они будут представлены в формате метаданных .NET. Например, в .NET любая сущность является объектом какого-нибудь класса, производного от корневого класса System.Object. Спецификация CTS поддерживает такие общие понятия, как классы, делегаты (с поддержкой обратных вызовов), ссылочные и размерные типы.

Важно понимать, что не во всех языках программирования .NET обязательно должны поддерживаться все типы данных, которые определены в CTS. Спецификация CLS (Common Language Specification — общая языковая спецификация ) устанавливает основные правила, определяющие законы, которым должны следовать все языки: ключевые слова, типы, примитивные типы, перегрузки методов и т. п. Спецификация CLS определяет минимальные требования, предъявляемые к языку платформы .NET. Компиляторы, удовлетворяющие этой спецификации, создают объекты, способные взаимодействовать друг с другом. Любой язык, соответствующий требованиям CLS, может использовать все возможности библиотеки FCL (Framework Class Library — библиотека классов платформы). CLS позволяет и разработчикам, и поставщикам, и производителям программного обеспечения не выходить за пределы общего набора правил для языков, компиляторов и типов данных.

Платформа .NET Framework является надстройкой над операционной системой, в качестве которой может выступать любая версия Windows 1 Благодаря архитектуре среды CLR в качестве операционной системы может выступать любая версия Unix и вообще любая ОС. . На сегодняшний день платформа .NET Framework включает в себя:

  • четыре официальных языка: С#, VB.NET, Managed C++ (управляемый C++) и JScript .NET;

  • объектно-ориентированную среду CLR ( Common Language Runtime ), совместно используемую этими языками для создания приложений под Windows и для Internet;
  • ряд связанных между собой библиотек классов под общим именем FCL (Framework >

Отношения архитектурных компонентов платформы .NET Framework с концептуальной точки зрения представлены на рис. 1.2.

Самым важным компонентом платформы .NET Framework является CLR ( Common Language Runtime ), предоставляющая среду, в которой выполняются программы. Главная ее роль заключается в том, чтобы обнаруживать и загружать типы .NET и производить управление ими в соответствии с полученными командами. CLR включает в себя виртуальную машину, во многих отношениях аналогичную виртуальной машине Java. На верхнем уровне среда активизирует объекты, производит проверку безопасности, размещает объекты в памяти, выполняет их, а также запускает сборщик мусора.

Под сборкой мусора понимается освобождение памяти, занятой объектами, которые стали бесполезными и не используются в дальнейшей работе приложения. В ряде языков программирования (например, C/C++) память освобождает сам программист, в явной форме отдавая команды как на создание, так и на удаление объекта. В этом есть своя логика — «я тебя породил, я тебя и убью». Однако в CLR задача сборки мусора (и другие вопросы, связанные с использованием памяти) решается в нужное время и в нужном месте исполнительной средой, ответственной за выполнение вычислений.

На рис. 1.2 над уровнем CLR находится набор базовых классов платформы, над ним расположены слой классов данных и XML, а также слой классов для создания Web-служб (Web Services), Web- и Windows-приложений (Web Forms и Windows Forms). Собранные воедино, эти классы известны под общим именем FCL (Framework Class Library). Это одна из самых больших библиотек классов в истории программирования. Она открывает доступ к системным функциям, включая и те, что прежде были доступны только через API Windows, а также к прикладным функциям для Web-разработки (ASP.NET), доступа к данным (ADO.NET), обеспечения безопасности и удаленного управления. Имея в своем составе более 4000 классов, библиотека FCL способствует быстрой разработке настольных, клиент-серверных и других приложений и Web-служб.

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

Над этим уровнем находится уровень классов, которые расширяют базовые классы с целью обеспечения управления данными и XML. Классы данных позволяют реализовать управление информацией, хранящейся в серверных базах данных. В число этих классов входят классы SQL (Structured Query Language, язык структурированных запросов), дающие программисту возможность обращаться к долговременным хранилищам данных через стандартный интерфейс SQL. Кроме того, набор классов, называемый ADO.NET, позволяет оперировать постоянными данными. Платформа .NET Framework поддерживает также целый ряд классов, позволяющих манипулировать XML-данными и выполнять поиск и преобразования XML.

Базовые классы, классы данных и XML расширяются классами, предназначенными для построения приложений на основе трех различных технологий: Web Services (Web-службы), Web Forms (Web-формы) и Windows Forms (Windows-формы). Web-службы включают в себя ряд классов, поддерживающих разработку облегченных распределяемых компонентов, которые могут работать даже с брандмауэрами и программами трансляции сетевых адресов (NAT). Поскольку Web-службы применяют в качестве базовых протоколов связи стандартные протоколы HTTP и SOAP, эти компоненты поддерживают в киберпространстве подход «Plug & Play».

Инструментальные средства Web Forms и Windows Forms позволяют применять технику RAD ( Rapid Application Development — быстрая разработка приложений) для построения Web- и Windows-приложений. Эта техника сводится к перетаскиванию элементов управления с панели инструментов на форму, двойному щелчку по элементу и написанию кода, который обрабатывает события, связанные с этим элементом.

Обмен данными сложной структуры с использованием ASP.NET Web API

Предпосылкой для написания этой статьи стал комментарий к статье «Использование AJAX в ASP.NET MVC», который был оставлен 26 февраля 2020 года одним из гостей сайта.

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

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

Введение

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

Дело в том, что при помощи HTTP запросов можно передавать не только отдельно взятые параметры (как это делалось в статье по ссылке), но также их массивы и сложные объекты.

В чистом виде ASP.NET MVC и Web Forms не способны эффективно обрабатывать подобные HTTP запросы. Поэтому для решения подобных задач следует воспользоваться платформой ASP.NET Web API .

Эта платформа, разрабатываемая Microsoft, позволяет легко построить web сервис на основе HTTP, который будет осуществлять обмен такими данными и может работать совместно с любым клиентским приложением, которое поддерживает HTTP, включая те же web приложения с использованием AJAX.

Первый проект ASP.NET Web API

Создадим проект ASP.NET Web API с помощью стандартного диалогового окна Visual Studio.

Обратите внимание, что в шаблоне проекта по умолчанию уже подключены как Web API, так и ASP.NET MVC. Это на самом деле не случайно.

Дело в том, что в основе платформы Web API л ежит паттерн MV C. Поэтому реализация даже шаблонного проекта опирается на соответствующую платформу.

Ниже приведён скриншот со структурой стандартного шаблона WebAPI проекта. На первый взгляд, это самый обычный ASP.NET MVC проект, но отличия заключаются не в структуре (хотя она и включает по умолчанию, так называемую, страницу помощи (папка Areas\HelpPage ), которую можно спокойно удалить), а во внутреннем содержании.

Одно из основных отличий состоит в том, что API запросы обрабатываются контроллерами, которые являются наследниками базового класса ApiController. Этот класс позволяет контроллеру обрабатывать не только GET и POST, но и другие типы HTTP запросов. Что позволяет разрабатывать Web API приложения в стиле RESTful.

Предлагаемый Visual Studio, шаблон контроллера по умолчанию уже содержит набор методов для поддержки GET, POST, PUT и DELETE запросов и ниже показан пример такого контроллера.


Создание «классической» ASP-страницы

Создание «классической» ASP-страницы

«Классическая» ASP-страница является комбинацией HTML и программного кода сценария сервера. Если вы никогда не работали с ASP, вам будет полезно знать, что целью использования ASP является динамическое построение HTML-кода с помощью сценария сервера и небольшого набора классических COM-объектов. Например, вы можете иметь серверный блок VBScript (или JavaScript), который читает таблицу из некоторого источника данных, используя классическую технологию ADO, и возвращает строки в виде HTML-таблицы общего вида.

В нашем примере ASP-страница использует внутренний COM-объект Request, чтобы прочитать введенные в форму данные (присоединенные к строке запроса) и возвратить их обратно вызывающей стороне в виде эхо (не слишком впечатляет, но поставленная задача будет выполнена). Для сценария сервера мы используем VBScript (что обозначено директивой language).

С этой целью создайте новый HTML-файл и сохраните его с именем ClassicAspPage.asp в той папке, куда проецируется ваш виртуальный каталог (например, в папке C:CodeTestsCarsWebSite). Реализуйте эту страницу так, как предлагается ниже.

‹%@ language=»VBScript» %›

‹h1 align=»center»›Вот что вы нам прислали:‹/h1›

‹P align=»center»›‹b›Имя пользователя: ‹/b›

‹%= Request.QueryString(«txtUserName») %›‹br›

‹%= Request.QueryString(«txtPassword») %›‹br›

Здесь COM-объекта Request ASP используется для вызова метода QueryString() с целью анализа значений, содержащихся в HTML-элементах и переданных с помощью method = «GET». Обозначение ‹%=… %› является сокращением для требования «вставить указанное непосредственно в исходящий HTTP-ответ». Чтобы достичь большей гибкости, вы могли бы взаимодействовать с COM-объектом Response в рамках всего блока сценария (обозначаемого знаками ‹% %›). В этом здесь необходимости нет, однако вот простой пример.

pwd = Request.QueryString(«txtPassword»)

Response.Write(pwd)

Очевидно, что объекты Request и Response классической схемы ASP предлагают целый ряд дополнительных членов, кроме показанных ниже. К тому же, в рамках классического подхода ASP определяется небольшой набор дополнительных COM-объектов (Session, Server, Application и т.д.), которые вы тоже можете использовать при построении Web-приложения.

структура объекта POCO + рекомендуемые шаблоны

Нам очень нравится EntityFramework (CTP5) и мы используем его вместе с ASP.NET MVC3.

Что мне не нравится, так это вещи смешаны вместе.

Я могу поместить DisplayAttribute , RequiredAttribute , RangeAttribute , CompareAttribute вместе в одном классе, что означает, что я смешан в проверке базы данных , некоторой бизнес-логике и пользовательском интерфейсе в целом. Я даже могу разместить атрибут ScriptIgnore, чтобы настроить его как объект Json DTO . Поэтому я могу использовать один и тот же класс POCO для Persistance, Presentation, DTO и Business Object, а также для моей модели Domian.

Какие шаблоны проектирования вы используете вместе с набором инструментов EF POCO + MVC3. Какие слои у вас есть? Какие обязанности вы добавляете к своим классам (Является ли ваш класс POCO вашей моделью предметной области)

2 ответа

Я использую View Models для решения этой проблемы. Атрибуты валидации и представления пользовательского интерфейса переходят к модели представления. В этом шаблоне контроллер использует хранилище для извлечения модели EF, сопоставляет эту модель EF с моделью представления (для этого я использую AutoMapper ) и передает модель представления в представление. Поскольку модель представления содержит все атрибуты представления пользовательского интерфейса, представление ведет себя как ожидалось. Каждое представление должно иметь свою собственную модель представления. Это означает, что вы можете иметь несколько моделей представлений, связанных с одной и той же моделью EF, но содержать другое подмножество свойств и отображать атрибуты форматирования в зависимости от конкретных требований представления.

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

Мои классы POCO почти всегда являются моделями предметной области и почти никогда не смотрят модели, поэтому у меня нет этих проблем.

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

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

Если вы хотите следовать строгому DDD, где POCO-классы являются объектами домена = предлагает методы, выполняющие доменную логику для экземпляра объекта, вам следует пойти еще дальше, потому что в этом случае ваша деловая сторона не должна предоставлять объекты домена контроллеру. В этом случае вы получите объекты для передачи данных, которые отображаются на бизнес-фасаде и используются контроллером. Я не пурист, поэтому в этом сценарии я склонен к непосредственному использованию аннотаций данных в DTO, но это зависит от других требований.


Как связать данные в ретрансляторе asp, используя структуру объекта?

Первоначально я был в состоянии заполнить данные в коде позади репитера asp как это:

Теперь я хотел изменить приведенный выше код на использование структуры сущностей. Пока я уже сделал это:

Я уже изменил raw sql на использование linq to entity и добавил новое условие. Но я не знаю, как связать данные из структуры сущностей с ретранслятором asp. Я хочу знать, как связать данные в ретрансляторе ASP, используя сущность Framework.

Я попытался связать его, как предложено ниже, но он дает мне исключительную ошибку, что он не содержит свойства с именем name, указывающим на эту строку кода: . Как видите, имя внутри eval действительно является частью бренда таблицы (пожалуйста, обратитесь к дополнительной информации ниже для понимания двух таблиц в моей базе данных). У меня не было проблем с этим ранее со старым подходом связывания данных с использованием набора данных, но когда я изменил его на использование структуры сущностей, он больше не распознает имя. Это может быть просто запрос?

Вот полный код файла aspx:

Таблица stringInstrumentItem (Столбец brandId является внешним ключом и ссылается на первичный ключ таблицы brand, который также называется brandId):

itemId brandId модель
1 1 XYZ
2 1 abc
3 2 HJK

Таблица brand (у которой есть первичный ключ brandId, на который ссылается таблица strinInstrumentItem):

Как правильнос построить N-Tier/N-Layer архитектуру для ASP.NET проекта?

Здравствуйте. Вот уже долгое время не могу найти кошерный способ построение N-Tier/N-Layer архитектуры.
Из того, что я нашел, необходимо создать Solution в среде Visual Studio, в котором создать не менее 2 проектов типа ClassLibrary (слои DAL и BLL) и один проект ASP.NET (слой Web).

При более подробном изучении узнал, что необходим еще один слой — Domain Transfer Object (DTO).
Итого получилось такая структура:

0) Слой DTO, в котором находятся классы объектов. В них будет происходить маппинг свойств из объектов Entity Framework на слое DAL.
1) Слой DAL. Здесь вся работа с базой. Собственно модель из EntityFramework, и класс репозитория, который служит в качестве обертки над каждой таблицей (Обладает набором свойств для оперирования с таблицами. По одному классу репозитория на каждую из таблиц).
2) Слой BLL. Здесь все бизнес процессы и классы, которые я называю сервисы. К примеру, ProductService, который внутри инициализирует поле типа ProductRepository и вызывает его методы, а результаты метода возвращает выше, в слой Web.
3) Слой Web. Здесь контроллеры, представления и прочее.

Так как хочется сделать слои слабосвязными, пытаюсь применять механизм Dependency Injection. Для этого приходится создавать интерфейсы для классов репозиториев и классов сервисов (IProductRepository и IProductService). На данный момент эти интерфейсы определяю в слое DTO, там же где и объекты-контейнеры.

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

Ну или дайте пожалуйста ссылочку, где можно прочитать. Спасибо большое за помощь

Внутреннее устройство ASP.NET: архитектура запроса

Written on 14 Ноября 2013 . Posted in ASP.NET

Далее подробно объяснена архитектура запроса ASP.NET.

Введение

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

Данная статья изучает, как ASP.NET (и IIS) обрабатывает запросы. Подробно рассмотрено, что происходит внутри архитектуры ASP.NET с момента ухода запроса из браузера до того, как он пройдет сквозь среду выполнения ASP.NET.

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

Браузер выдает запрос

Процесс начинается, как только пользователь запросит ресурс ASP.NET посредством браузера. Например, пользователь запросил следующий URL: http://www.myserver.com/myapplication/mypage.aspx. Запрос достигнет “myserver”, где установлены Windows Server 2003 и IIS 6.0.

Драйвер http.sys режима ядра перехватывает запрос

Как только запрос достигает IIS, запрос обнаруживается драйвером режима ядра http.sys. Дальше рассказано, что такое драйвер режима ядра http.sys и что он делает.


В общем, Windows предоставляет два режима: режим пользователя и режим ядра. Пользовательские приложения работают в режиме пользователя, а код операционной системы работает в режиме ядра. Если пользовательскому приложению надо работать непосредственно с оборудованием, эту конкретную операцию выполняет процесс режима ядра. Очевидное назначение этих режимов – защитить компоненты операционной системы от повреждения пользовательскими приложениями. Теперь, когда ясно, что такое режим пользователя и режим ядра, в чем заключается роль драйвера режима ядра http.sys?

При создании нового веб-сайта IIS IIS регистрирует сайт в http.sys, который далее получает все запросы HTTP для любого веб-приложения внутри сайта. http.sys работает как ретранслятор, направляя запросы HTTP процессу режима пользователя, выполняющего веб-приложение. В данном случае процесс режима пользователя является рабочим процессом, выполняющим пул приложений, в котором работает веб-приложение. http.sys реализует механизм ведения очередей, создавая столько очередей, сколько пулов приложений имеется в IIS.

Продолжая пример, как только запрос достигает “myserver”, http.sys перехватывает запрос. Допустим, “myapplication” настроено на работу в пуле приложений “myapplicationpool”; в таком случае http.sys проверяет очередь запросов “myapplicationpool” и пересылает запрос рабочему процессу, в котором работает “myapplicationpool”.

Запрос пересылается пулу приложений

Запрос пересылается пулу приложений, как сказано выше. Каждым пулом приложений управляет экземпляр рабочего процесса “w3wp.exe”. По умолчанию “w3wp.exe” выполняется под учетной записью “NetworkService”. Это можно изменить следующим образом: щелкнуть правой кнопкой мыши по пулу приложений, вмещающему приложение—Свойства—вкладка Идентичность. Вспомните, что пулом приложений управляет рабочий процесс “w3wp.exe”. Сейчас рабочий процесс берет управление на себя.

Рабочий процесс загружает ASP.NET ISAPI

Рабочий процесс “w3wp.exe” ищет URL запроса, чтобы загрузить нужное расширение ISAPI. Запрошенный ресурс в URL — “mypage.aspx”. Что происходит дальше? Полный разбор расширений ISAPI (и фильтров) не входит в статью, но вкратце, расширения ISAPI являются способом, посредством которого IIS обрабатывает запросы на разные ресурсы. После установки ASP.NET он устанавливает свое собственное расширение ISAPI (aspnet_isapi.dll) и добавляет привязку в IIS. IIS увязывает разные расширения с их расширениями ISAPI. Привязки в IIS можно посмотреть так: щелкнуть правой кнопкой мыши по веб-сайту-Свойства-вкладка Домашний каталог-кнопка Конфигурация-вкладка Привязки. Рисунок ниже показывает привязки:

Как видно, расширение “.aspx” увязано с расширением aspnet_isapi.dll. Рабочий процесс передает запрос расширению aspnet_isapi. Расширение aspnet_isapi, в свою очередь, загружает среду выполнения HTTP, и начинается обработка запроса.

Перед изучением того, что происходит внутри среды выполнения HTTP, рассмотрены детали того, как рабочий процесс загружает веб-приложение. Рабочий процесс загружает сборку веб-приложения, выделяя один домен приложения для приложения. Когда рабочий процесс запускает веб-приложение (в его домене приложения), веб-приложение наследует идентичность процесса (NetworkService по умолчанию), если перевоплощение запрещено. Но если перевоплощение разрешено, каждое веб-приложение работает под учетной записью, аутентифицированной IIS, или под учетной записью пользователя, настроенной в web.config.


o Если IIS разрешает только анонимный доступ, переданной веб-приложению идентичностью будет [machine]\IUSR_[machine].
o Если только встроенная аутентификация Windows разрешена в IIS, переданной веб-приложению идентичностью будет аутентифицированный пользователь Windows.
o Если разрешены встроенная аутентификация Windows и анонимный доступ, переданная веб-приложению идентичность будет зависеть от той, которая была аутентифицирована IIS. IIS сначала пытается использовать анонимный доступ, чтобы предоставить пользователю доступ к ресурсу веб-приложения. Если эта попытка проваливается, то он пытается использовать аутентификацию Windows

o Позволяет веб-приложению работать под конкретной идентичностью.

Замечание: IIS 6.0 и IIS 5.0 по-разному обрабатывают запросы. Режим ядра http.sys реализован только в IIS 6.0. Такого свойства у IIS 5.0 нет. В IIS 5.0 запрос перехватывается непосредственно модулем aspnet_asapi, передающим запрос рабочему процессу. Рабочий процесс и модуль ISAPI взаимодействуют посредством конвейеров, приводя к издержкам вызова. Более того, один экземпляр рабочего процесса обслуживает все веб-приложения; нет пулов приложений. Модель IIS 6.0 намного лучше модули IIS 5.0. Рабочим процессом в IIS 5.0 является “aspnet_wp.exe”, в отличие от “w3wp.exe” в IIS 6.0. Рабочий процесс “aspnet_wp.exe” работает под стандартной учетной записью “ASPNET”, в отличие от “NetworkService” в IIS 6.0. Можно изменить эту учетную запись, найдя элемент

в файле “machine.config”.

Замечание: IIS 7.0 предоставляет два способа обработки запросов ASP.NET. Первый – классический способ, работающий так же, как в IIS 6.0; полезен для совместимости. Второй – новый комплексный способ, в котором ASP.NET и IIS входят в один и тот же конвейер обработки запроса. Во втором способе модули и обработчики .NET подключаются непосредственно к общему конвейеру обработки запроса, что эффективней способа IIS 6.0.

В среду выполнения HTTP

Обобщено, что пока произошло: запрос был передан от браузера к http.sys, передавшему запрос пулу приложений. Рабочий процесс, управляющий пулом приложений, изучает URL запроса и использует привязку расширения приложения IIS для загрузки ASP.NET ISAPI “aspnet_isapi.dll”. ASP.NET ISAPI загружает среду выполнения HTTP, также называемую средой выполнения ASP.NET.

Начинается изучение того, что происходит внутри HTTP. Точка входа среды выполнения — класс HttpRuntime. Метод HttpRuntime.ProcessRequest сообщает о начале обработки. В следующих подразделах рассмотрено, что происходит внутри среды выполнения после вызова метода ProcessRequest:

Создается новый экземпляр HttpContext запроса

HttpContext существует в течение времени жизни запроса и доступен через статическое свойство HttpContext.Current. Объект HttpContext представляет контекст активного сейчас запроса, так как он содержит ссылки на объекты, к которым можно обратиться в течение времени жизни запроса, а именно Request,Response, Application, Server и Cache. В любой момент при обработке запроса HttpContext.Current дает доступ ко всем перечисленным объектам. Более того, объект HttpContext содержит коллекцию Items, которую можно использовать для хранения специфичной информации запроса.

HttpRuntime советует классу HttpApplicationFactory загрузить объект HttpApplication

Класс HttpApplicationFactory создает пул объектов HttpApplication для приложения ASP.NET и связывает каждый запрос с объектом HttpApplication из того пула. Если в момент запроса в пуле нет объектов, то HttpApplicationFactory создает объект и передает его запросу. В результате запрос направляется приложению, работающему в пространстве AppDomain, и объект HttpApplication назначается для запроса. Теперь, когда ясно, что происходит, возникает вопрос, зачем нужен объект HttpApplication. HttpApplication – внешний контейнер для конкретного веб-приложения, увязанный с классом, определенным в Global.asax. При изучении файла Global.asax выясняется, что он унаследован от класса System.Web.HttpApplication. Есть набор предопределенных событий, возбуждающихся в течение времени жизни запроса; эти события представлены в файле Global.asax. HttpApplication служит контроллером этих событий. К тому же, HttpApplication хранит список сконфигурированных HttpModules, загружаемых динамически в ходе обработки запроса. Где выполняются эти события и HttpModules и чем именно являются HttpModules и HttpHandlers? Ответы на эти вопросы находятся внутри конвейера HTTP:

Внутри конвейера HTTP

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

Запрос проходит через модули HTTP

HttpModules конфигурируются на уровне машины (machine.config) и на уровне приложения (web.config). В ASP.NET есть много встроенных HttpModules, осуществляющих доступ к запросу и выполняющих разные функции. Этими HttpModules являются аутентификация, управление состоянием и модули кеширования. ASP.NET 2.0 добавляет дополнительные модули, а именно членство, управление ролями и персонализация. Рисунок ниже взят из файла “machine.config” и показывает, как определены встроенные модули:

Разработчики могут написать свои собственные модули и подключить их в “machine.config”, чтобы применить модули ко всем приложениям, или в “web.config” конкретного приложения, чтобы применить модули только к нему. Запросы внутри конвейера HTTP проходят через все модули, определенные в “machine.config” и “web.config”. Как сказано в предыдущем разделе, эти модули хранятся внутри HttpApplication и динамически загружаются при выполнении.

Запрос попадает в обработчик HTTP

Обработчики HTTP являются конечными точками в конвейере HTTP. Задача обработчика HTTP – сгенерировать вывод для запрошенного ресурса. Для страниц ASPX это означает перевод страниц в HTML и возврат этого HTML. Обработчики HTTP конфигурируются на уровне машины (machine.config) и на уровне приложения (web.config). Рисунок ниже взят из “machine.config” и показывает, как устанавливаются обработчики HTTP.

Как видно на рисунке выше, разные ресурсы настраиваются на использование разных обработчиков. Страницы ASP.NET ASPX настроены на использование “PageHandlerFactory”. Задача “PageHandlerFactory” – предоставить экземпляр HTTP, способный обработать запрос. “PageHandleFactory” пытается найти скомпилированный класс, представляющий запрошенную страницу “mypage.aspx”. В случае успеха он передает данный скомпилированный класс в качестве обработчика HTTP. Если нет скомпилированного класса, представляющего запрошенную страницу, потому что запрос первый или потому что страницу изменили с момента последнего запроса, то “PageHandlerFactory” компилирует запрошенную страницу “mypage.aspx” и возвращает скомпилированный класс. Все последующие запросы будут обслуживаться тем же самым скомпилированным классом, пока страницу не изменят.

Возникает вопрос, почему “PageHandlerFactory” возвращает экземпляр скомпилированного класса, выступающий обработчиком запроса. Является ли скомпилированным класс фактическим обработчиком HTTP? Ответ очевиден из изучения отделенного кода страницы, “mypage.aspx.cs”. Страница унаследована от класса “System.Web.UI.Page”; этот класс реализует интерфейс “IHttpHandler”, что делает его пригодным в качестве обработчика HTTP.

Замечание: Компиляция страницы не входит в эту статью, но будет описана в следующей статье, рассматривающей модель страницы ASP.NET.

Начинается выполнение страницы

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