Asp разработка масштабируемых веб приложений


Содержание

Создание масштабируемого веб-приложения ASP.NET MVC

В настоящее время я занимаюсь созданием веб-приложения ASP.NET MVC в С#.

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

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

Мой вопрос в том, каким будет лучший способ обработки обновления с точки зрения клиента\браузера.

Я подумываю о том, чтобы отправить данные обратно на сервер и добавить их в очередь и немедленно отправить ответ клиенту, а затем опросить на какой-то частоте, чтобы получить обновленные данные. Любые лучшие практики или шаблоны в этом случае будут оценены.

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

Обновление Думал, что я опубликую обновление об этом, поскольку это было какое-то время. Мы фактически закончили использование Windows Azure, но решение применимо к другим платформам.

То, что мы закончили, — это использование очереди Windows Azure для отправки сообщений\команд. Это очень быстрый процесс и немедленно возвращается. Затем у нас есть рабочая роль, которая обрабатывает эти сообщения в другом потоке. Это позволяет нам свести к минимуму любые db-записи\обновления на веб-роли в теории, позволяющие нам масштабироваться более легко.

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

Разработка Web-приложения с применением технологии ASP.NET

Рубрика: Информационные технологии

Дата публикации: 03.02.2014 2014-02-03

Статья просмотрена: 983 раза

Библиографическое описание:

Допира Р. И., Попова Н. В., Базикова К. М. Разработка Web-приложения с применением технологии ASP.NET // Молодой ученый. — 2014. — №2. — С. 84-87. — URL https://moluch.ru/archive/61/9185/ (дата обращения: 12.11.2020).

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

В Республике Казахстан активно развивается сфера информационных услуг, предоставляемых через Internet. Web-приложения — это специальный вид приложений, разработанных для глобальной сети. При запуске Web-приложения происходит генерирование HTML-кода, загрузка изображений, клиентских сценариев, таблиц стилей и других ресурсов. По запросу пользователя может быть загружен сохраненный на сервере статический документ HTML или генерация кода HTML происходит в процессе обработки запроса от клиента. Динамический контент позволяет разработать Web-приложение интерактивным. Разработка Web-приложений существенно отличается от разработки типичного приложения. Во-первых, Web-приложения исполняются на сервере, а во-вторых, не сохраняют состояния после обработки запросов пользователей. Поэтому при построении Web-приложения разработчик должен определить способы хранения информации о пользователе, организовать сеансы работы пользователя, способы переходов от страницы к странице. Перечисленные задачи считаются стандартными и одинаково решаются для большинства Web-приложений. Реализация этих задач вынесена в отдельные технологии, которые называются технологиями для разработки Web-приложений. В Казахстане чаще всего используются следующие технологии: Flash, Microsoft ASP.NET, Java Server Pages, Personal Home Page. При использовании любой из перечисленных технологий, остается основное преимущество Web-приложений над традиционными, которое заключается в процессе развертывания. Для реализации проекта Web-приложение нужно разместить на сервере и дать ссылку на него всем пользователям, а в случае изменения программного кода потребуется обновить код только на сервере. Для загрузки Web-приложения на компьютеры пользователей требуется больше времени, но встроенные механизмы оптимизации кода позволяют получить более эффективный исполняемый код, а процесс компиляции придает гибкость и универсальность приложениям.NET.

Для организации динамически обновляемой информации на Web-страницах необходимо использование и ведения баз данных, а именно обязательное применение языка SQL. В зависимости от выбранной платформы проекта в настоящее время чаще всего используются MySQL, Oracle, Microsoft SQL Server. SQL Server в сочетании с.NET Framework уменьшает время разработки и внедрения современных приложений, ускоряет процесс поиска данных, упрощает управление сайтом, позволяет использовать создаваемые классы в других приложениях, предоставляет широкие возможности для создания Web-приложений. Для доступа к данным.NET Framework использует технологию ADO.NET, которая позволяет работать с данными, как с логически информационными сущностями. В среде Misrosoft Visual Studio 2010 можно осуществить проектирование классов, на основе реляционных данных, определить структуру таблиц базы данных и их отношений.

Для создания приложения «Вакансии» была выбрана технология ASP.NET, которая содержит высокоуровневые концепции, необходимые для разработки высокопроизводительных Web-приложений. Любая технологическая платформа предлагает разработчику определенные стиль и подходы к разработке приложений. Основной задачей было создать приложение, в котором содержатся основные требования, предъявляемые к соискателям вакантных мест. Зачастую к одной и той же должности руководители предприятий и организаций предъявляют различные требования. Приложение содержит не только данные требований, но и позволяет осуществить поиск по названию должности, с учетом предъявляемых к данной должности требований. Пользователь на основании своей квалификации, знаний и умений, может подобрать вакантные места на предприятиях Карагандинской области.

Созданное Web-приложение содержит горизонтальное меню навигации, состоящее из пунктов: «Главная», «Сотрудники», «О разработчике». На главной странице находятся сведения об организациях и предприятиях Карагандинской области, зарегистрированных на сайте (рисунок 1). По каждому из столбцов данных предусмотрена сортировка. При выборе организации можно просмотреть предлагаемый список вакансий. В информации о вакансии содержится перечень требований, предъявляемых к претенденту на данном предприятии.

Рис. 1. Главная страница Web-приложения «Вакансии»

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

На главной странице находятся ссылки «Вход» и «Регистрация». При нажатии ссылки «Вход» открывается окно, с помощью которого можно зарегистрироваться в системе, как предприятиям, так и соискателям вакантных мест.

Для клиентской и серверной проверки ввода данных пользователя в технологии ASP.NET используют шесть элементов управления user input validation [1]. Элементы управления проверкой достоверности объявляют в Web-форме и привязывают к элементу управления вводом данных пользователя. Свойства элементов управления user input validation определяет разработчик, это упрощают процесс проверки достоверности, и избавляет программиста от необходимости писать длинный код.

Если пользователь Web-приложения не имеет аккаунта в системе, ему предлагается зарегистрироваться. Пользователь последовательно заполняет форму с проверкой корректности данных (рисунок 2). Если данные будут не корректными, то пользователь в систему не будет добавлен. При сохранении данных пользователя происходит проверка на наличие в базе данных аналогичного аккаунта, если произойдет совпадение, то пользователю будет предложено изменить свои данные. После создания аккаунта пользователь выбирает раздел «Сотрудники» или «Организации» в котором он может оставить соответствующую информацию о себе.

Рис. 2. Регистрация в системе

Разработка Web-приложения «Вакансии» была выполнена в среде Misrosoft Visual Studio 2010 [2]. На рисунке 3 представлена часть кода приложения. Проект содержит страницы в формате.aspx, две базы данных, плагины jquery (для визуальных эффектов), таблицу стилей [3]. Две базы данных необходимы для организации разделения уровня доступа.

Рис. 3. Окно разработки Web-приложения «Вакансии»

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

В настоящее время в Казахстане использование технологии ASP.NET находиться на начальном этапе. Основные проекты `Web-разработки выполнены на PHP и Java. Таким образом, возможности технологии ASP.NET позволили свободно использовать стандартные библиотеки и классы.NET, объектно-ориентированное программирование, создавая свои собственные функциональные элементы, безопасность типов. Разработанное Web-приложение «Вакансии» является стартовым проектом, позволяющим оперативно найти информацию о вакансиях и помочь в трудоустройстве.

Проект содержит информацию о предприятиях и организациях только по Карагандинской области. Планируется разместить информацию о приложении в поисковых системах и включить данные о предприятиях и организациях других регионов Казахстана. Мы надеемся, что созданное Web-приложение «Вакансии» вместе с программами, которые разрабатывает и поддерживает государство, внесет свой вклад в решение проблемы устройства на работу граждан Республики Казахстан, в соответствии с их призванием и личными потребностями, с учетом их способностей, образования и профессиональной подготовки.

1. Мэтью Мак-Дональд, Адам Фримен, Марио Шпушта. Microsoft ASP.NET 4 с примерами на C# 2010 для профессионалов. Издательство: Вильямс, 2011.

2. Алекс Макки. Введение в.NET 4.0 и Visual Studio 2010 для профессионалов. Издательство: Вильямс, 2010.

3. Шилдг Герберт. Полный справочник по С# 4.0. Пер. с англ. — Издательство: Вильямс, 2011.

ASP.NET и разработка Web-приложений

Многие разработчики полагают, что технология ASP.NET является чем-то вроде продолжения ASP, т. е. что это, если так можно выразиться, перенесенная на платформу .NET версия ASP 3.0, несколько усовершенствованная и дополненная поддержкой новых языков. Подобное представление в корне неверно. ASP.NET является концептуально новой современной платформой, предназначенной для создания Web-приложений. Специалистами Microsoft в ASP.NET заложено все для того, чтобы сделать цикл разработки Web-приложения более быстрым, а поддержку — более простой.

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

Компилирование программного кода. Теперь написанный исходный код при первом обращении компилируется и впоследствии выполняется его скомпилированная версия. Это заметно ускоряет разработку приложений. Web-сервер сам выполняет компиляцию, и если исходный код заменить, то сервер автоматически при первом обращении к странице проведет перекомпиляцию. Тем, кто разрабатывал сервлеты и запускал их на таких Java-серверах, как tomcat, наверняка знакома сложная процедура перезапуска сервера после перекомпиляции. Приходится сначала самому компилировать сервлет, а затем прописывать его в конфигурационный файл, и при каждом изменении вновь перезагружать сервер. С ASP.NET быть разработчиком Web-приложений намного приятнее. Код выполняется быстрее, занимает меньше ресурсов, и при этом процесс разработки не усложнился. Скорее наоборот, так как в случае какого-либо сбоя можно получить полный листинг компилятора, с подробным описанием ошибки.

Библиотеки. Теперь при написании приложений можно задействовать набор компонентов, поставляемых с .NET, а он достаточно велик. Использование библиотеки классов Common Language Runtime (CLR) уменьшает количество кода, ускоряет процесс разработки, установки и переноса приложения.

ADO.NET. В приложениях ASP.NET, как и в любом другом программном коде под .NET, можно использовать ADO.NET. Я упоминаю ADO.NET особо, чтобы подчеркнуть, насколько часто эта библиотека применяется при создании приложений на ASP.NET. Среди функций ADO.NET, используемых в ASP.NET, можно назвать, например, возможность сохранения набора данных в XML и загрузки его из XML, что упрощает разработку распределенных приложений на основе ASP.NET, а также полезно при передаче данных между Web-службами ASP.NET.

Поддержка средств разработки. Visual Studio.NET предоставляет возможность создания и редактирования приложений в режиме WYSWYG, включает в себя средства, упрощающие разработку и перенос приложений, а также отладку сценариев. Но, несомненно, никто не отнимает права написания кода в любимом редакторе, будь то CodeWright, EditPlus или NotePad.

Языковая независимость. ASP.NET работает в рамках Common Language Runtime, что позволяет писать код на любом языке, для которого существует компилятор, поддерживающий эту технологию. Сейчас имеется поддержка для JScript, VB, Perl и C#.

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

Обработка ошибок. В связи с новыми концепциями (в частности, с компиляцией программных текстов) в ASP.NET добавлены более широкие возможности обработки ошибок. На стадии разработки можно получить полную информацию об ошибке и листинг нужного куска кода. Для обработки ошибок, которые могут случиться во время выполнения приложения, можно использовать новую директиву ErrorPage.

Объектно-ориентированная разработка. Использование C# позволяет в полной мере задействовать концепции, методы и шаблоны объектно-ориентированной разработки.

Повторное применение. Помимо возможностей объектно-ориентированного программирования, ASP.NET представляет новые технологии, такие, как пользовательские элементы управления (user controls), новую концепцию установки (bin) и другие возможности.

Набор серверных компонентов ASP.NET. В комплект ASP.NET входят различные серверные компоненты: от самых простых (кнопка, список) до нестандартных и более функционально богатых (календарь).

Структура

Теперь немного поговорим о внутренней организации ASP.NET. Если продолжить сравнение с ASP, надо отметить, что в связи с описанными нововведениями внутренняя организация не могла остаться прежней. Если ASP представляла собой ISAPI DLL, с набором компонентов и несколькими системными файлами, то ASP.NET — часть глобальной платформы .NET. Создание этой платформы — важнейшее направление новой стратегии Microsoft; она соответствует всем современным стандартам разработки как для распределенных систем, так и для настольных приложений. На Рисунке 1 приведена схема, на которой показано взаимодействие различных частей .NET. Взаимодействие строится следующим образом: библиотека .NET Framework предоставляет интерфейс приложениям, а сама при этом взаимодействует непосредственно с операционной системой. Выше лежит интерфейс приложений ASP.NET, на котором, в свою очередь, базируются Web-формы (страницы ASP.NET) и Web-службы. Интерфейс .NET Framework позволяет стандартизировать обращение к системным вызовам и предоставляет среду для более быстрой и удобной разработки.

Рисунок 1. Схема работы .NET.

Intermediate Language — общий промежуточный язык, в который компилируется любой код под .NET, независимо от того, был ли он написан на C#, VB.NET или другом языке, — позволяет создавать системы на любом языке. И независимо от того, используется ли C#, VB.NET, JScript.NET или Perl.NET, на выходе получается готовый к выполнению код. На Рисунке 2 показана схема процесса компиляции и выполнения приложения ASP.NET. При запросе страницы проверяется, есть ли на диске ее скомпилированная версия и не обновлялась ли страница с момента компиляции. Если есть актуальная версия, она подгружается с диска и выполняется средой .NET. Результат выполнения страницы отсылается клиенту. Если же такая версия не была найдена, страница сначала компилируется. Для этого используются соответствующие компиляторы, которым на вход подается исходный код самой страницы, ее code-behind (т. е. непосредственно исполняемый код, стоящий за Web-формой, который написан отдельно — он может отсутствовать) и код элементов управления. Полученный в результате код сохраняется на диске. В некоторых случаях, а именно, когда в кэше имеется сохраненный результат обработки страницы, MSIL-код даже не приходится выполнять.

Рисунок 2. Схема работы ASP.NET.

На практике

Данный процесс кажется сложным, но разработчики всей этой сложности не замечают — процедура создания страниц ASP.NET достаточно проста. В подтверждение своих слов я хочу создать простейшую ASP.NET-форму. Для написания формы нужно сначала установить, собственно, ASP.NET. Установка начинается с получения комплекта .NET Framework SDK. Размер дистрибутива достигает 90 Мбайт, однако имеется возможность загрузки SDK в виде набора маленьких файлов. После загрузки требуется запустить файл setup.exe и следовать его инструкциям. ASP.NET распространяется как составная часть .NET SDK — сборника всех технологий, необходимых для создания, сборки и тестирования приложений, основанных на .NET Framework. Перед установкой ASP.NET следует инсталлировать Internet Explorer 6. NET SDK можно взять и с компакт-диска Windows Component Update из Visual Studio.NET. Если VS.NET на сервере установлен, то для того, чтобы запускать приложения ASP.NET, уже все есть.

Первую форму мы создадим с привлечением минимальных средств — нам падобится .NET Framework, Internet Information Services 5 и текстовый редактор. Создание формы начнем с написания приложения на Web-сервере. Создадим папку, в которой будет находиться приложение. Предположим, C:SampleApplication. Затем запустим Internet Services Manager. Создадим на сервере новый виртуальный каталог. Для этого нужно вызвать контекстное меню Web-сервера и выбрать пункт NewVirtual Director. На экране появится мастер Virtual Directory Creation Wizard. С его помощью нужно указать имя нового приложения, пусть это будет CustomApp. Далее следует указать каталог, в котором будут находиться файлы приложения. В нашем случае это C:SampleApplication. Следующий шаг — назначить права доступа к приложению (их можно оставить заданными по умолчанию). Далее в полученной папке создадим файл Default.aspx (см. Листинг 1).

Листинг 1. Default.aspx.

Опишу вкратце код этого листинга.

В первой строчке стоит директива @ Page, которая задает параметры страницы. Здесь, в частности, указано, что мы пишем на C#, что на странице у нас будет проводиться дополнительная программная обработка, определенная в файле Default.aspx.cs (мы его еще напишем), а наследоваться страница будет от класса Default (который будет описан в файле Default.aspx.cs).

Далее следует форма. Все серверные элементы управления должны быть включены в серверную форму (

Архитектура веб-приложений ASP.NET. Разработка веб-приложений на платформе .NET

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

ASP . NET внешне во многом напоминает более старую технологию ASP , но в то же время внутреннее устройство ASP . NET существенно отличается от ASP . Компания Майкрософт ASP . NET построила на базе CLR (Common Language Runtime), который является основой всех приложений . NET . Разработчики могут создавать код для ASP . NET , используя языки программирования, входящие в . NET Framework: C #, Visual Basic . NET , JScript. NET и другие.

Рассмотрим более подробно, чем отличается ASP . NET от ASP .

Классический ASP имеет следующие недостатки :

  • Используются только языки сценариев, которые дают большой проигрыш в производительности (из-за их интерпретируемости) и не поддерживают многие возможности объектно-ориентированного программирования.
  • Логика представления (в виде кода HTML) не отделена от бизнес-логики (исполняемого кода), что приводит перемешиванию в одном файле кода HTML с кодом сценария.
  • Невозможно повторно использовать готовые решения в других проектах (возможно только копирование кода сценариев).

В файлах ASP . NET включается код на таких языках программирования как C #, JScript. NET , VisualBasic. NET , что позволяет применять непосредственно в веб-приложениях возможности объектно-ориентированного программирования. Также существенно сокращается объем кода, написанного вручную за счет применения серверных объектов , автоматически генерирующих код элементов управления HTML . Возможно использование стандартной среды разработки Visual Studio. NET , т.е. ASP . NET имеет преимущество в скорости по сравнению со сценарными технологиями, так как при первом обращении код компилируется и помещается в специальный кеш , а впоследствии только исполняется, не требуя затрат времени на парсинг , оптимизацию, и т. д.

Несмотря на возможность совместной работы ASP и ASP. NET на одном веб-сервере, они не могут использовать общий сеанс . Файлы ASP . NET обрабатываются библиотекой aspnet_isapi.dll (а не asp.dll ), которая, в свою очередь , использует для выполнения кода технологию . NET .

Библиотека базовых классов . NET содержит пространства имен 3 основных групп:

  • элементы web-приложений (протоколы, безопасность и др.);
  • элементы графического интерфейса ( WebForms ) ;
  • web -службы.

Как уже указывалось ранее, ASP . NET использует возможности стандартной среды разработки Visual Studio.Net, и в частности классы библиотеки FCL (Framework Class Library ).

Разработчику веб-приложений на ASP . NET доступны классы, входящие в следующие пространства имен:

Пространство имен Содержание
System.Web Организация взаимодействия web-клиента (браузера) с web-сервером (запрос-ответ, cookie и и др.)
System.Web.Caching Поддержка кэширования при работе web-приложений
System.Web.Configuration Настройка web-приложения в соответствии с файлами конфигурации проекта
System.Web.Security Реализация системы безопасности web-приложений
System.Web.Services Организация работы web-сервисов
System.Web.Services.Description
System.Web.Services.Discovery
System.Web.Services.Protocols
System.Web.UI Построение графического интерфейса пользователей web-приложений
System.Web.UI.WebControls
System.Web.HtmlControls

В свою очередь пространство имен System.Web включает в себя пространства имен, названия которых знакомы разработчикам веб-приложений на ASP :

Пространство имен Содержание
HttpApplication Данный класс определяет общие для всех web-приложений члены
HttpApplicationState В данном классе содержится общая информация web-приложения для множества запросов, сеансов и каналов передачи данных
HttpBrowserCapabilities Этот класс используется для получения информации о возможностях клиентского браузера, обращающегося к web-серверу
HttpCookie Поддержка механизма безопасной работы с объектами HTTP cookie
HttpRequest Предоставляет доступ к информации, переданной web-клиентом
HttpResponse Используется для формирования HTTP-ответа сервера

В основу разработки веб-приложений на ASP . NET положена модель разделения кода представления и кода реализации, рекомендуемая Майкрософт при создании динамических документов с помощью программных кодов. Это делается путем размещения программного кода либо в отдельный файл , либо внутри специального тэга для сценариев. Файл такого рода обычно имеет расширение *.aspx.cs ( *.aspx.vb ) и имеет имя, совпадающее с именем основного ASPX файла. В принципе такой подход позволяет веб-дизайнеру сконцентрироваться работе с кодом разметки документа с минимальными изменениями программного кода, в обычном ASP внедряемого непосредственно в код разметки.

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

  • При запросе страницы ASPX инициируется событие Page_Init , производящее начальную инициализацию страницы и ее объекта.
  • Далее инициируется событие Page_Load , которое может быть использовано, например для установки начальных значений для элементов управления. При этом также можно определить была ли загружена страница впервые или обращение к ней осуществляется повторно в рамках обратной отсылки в ответ на события, связанные с элементами управления, размещенными на странице; т.е. проверить свойство Page.IsPostBack .
  • Далее выполняется проверка валидности элементов страницы с точки зрения корректности введенных пользователем данных.
  • И, наконец, следует обработка всех событий, связанных с действиями пользователя с момента последней обратной отсылки.

Для сохранения данных веб-страницы в промежутках между обращениями к ней в ASP . NET используются состояния отображения ( view state ).

Если данные, введенные в веб-форму, необходимо сделать доступными другим веб-формам того же приложения, эти данные необходимо сохранить в объектах Application и Session . Объекты Application доступны всем пользователям приложения и могут рассматриваться как глобальные переменные , обращение к которым возможно из любых сеансов. Объекты Session доступны только в рамках одного сеанса, и поэтому они оказываются доступными только одному пользователю.

Серверные элементы управления ASP.NET

Важной особенностью ASP . NET является использование серверных элементов управления на веб-странице (элементы WebForm ), которые являются фактически тэгами, понятными веб-серверу. Эти элементы определены в пространстве имен System.Web.UI.WebControls .

Принято выделять три типа серверных элементов управления:

  • Серверные элементы управления HTML – обычные HTML тэги.
  • Элементы управления веб-сервера – новые тэги ASP.NET.
  • Серверные элементы управления для проверки данных (валидации) – применяются для валидации входных данных от клиентского приложения (обычно веб-браузера).

Преимущества от использования таких элементов при разработке веб-приложений:

По умолчанию серверные элементы управления HTML в ASP . NET файлах рассматриваются как текст. Для их программирования требуется добавление атрибута runat=»server» в соответствующий HTML элемент. Кроме того, все серверные элементы управления HTML должны быть размещены внутри области действия тэга

Asp разработка масштабируемых веб приложений

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

Илон Маск рекомендует:  Что такое код url

Для начала имеет смысл определиться с тем, о чем мы вообще будем говорить. В данном контексте перед веб-приложением ставятся три основные цели:

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

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

Масштабируемость принято разделять на два направления:

Вертикальная масштабируемость Увеличение производительности каждого компонента системы c целью повышения общей производительности. Горизонтальная масштабируемость Разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим машинам (или их группам) и/или увеличение количества серверов параллельно выполняющих одну и ту же функцию.

Так или иначе, при разработке стратегии роста системы приходится искать компромис между ценой, временем разработки, итоговой производительность, стабильностью и еще массой других критериев. С финансовой точки зрения вертикальная масштабируемость является далеко не самым привлекательным решением, ведь цены на сервера с большим количеством процессоров всегда растут практически экспоненциально относительно количества процессоров. Именно по-этому наиболее интересен горизонтальный подход, так как именно он используется в большинстве случаев. Но и вертикальная масштабируемость порой имеет право на существование, особенно в ситуациях, когда основную роль играет время и скорость решения задачи, а не финансовый вопрос: ведь купить БОЛЬШОЙ сервер существенно быстрее, чем практически заново разрабатывать приложения, адаптируя его к работе на большом количестве параллельно работающих серверов.

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

Серверы приложений

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

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

Балансировка нагрузки

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

Оборудование Сетевое оборудование, позволяющее распределять нагрузку между несколькими серверами, обычно стоит достаточно внушительные суммы, но среди прочих вариантов обычно именно этот подход предлагает наивысшую производительность и стабильность (в основном благодаря качеству, плюс такое оборудование иногда поставляется парами, работающими по принципу HeartBeat). В этой индустрии достаточно много серьезных брендов, предлагающих свои решения — есть из чего выбрать: Cisco, Foundry, NetScalar и многие другие. Программное обеспечение В этой области еще большее разнообразие возможных вариантов. Получить программно производительность сопоставимую с аппаратными решениями не так-то просто, да и HeartBeat придется обеспечивать программно, но зато оборудование для функционирования такого решения представляет собой обычный сервер (возможно не один). Таких программных продуктов достаточно много, обычно они представляют собой просто HTTP-серверы, перенаправляющие запросы своим коллегам на других серверах вместо отправки напрямую на обработку интерпретатору языка программирования. Для примера можно упомянуть, скажем, nginx с mod_proxy . Помимо этого имеют место более экзотические варианты, основанные на DNS, то есть в процессе определения клиентом IP-адреса сервера с необходимым ему интернет-ресурсов адрес выдается с учетом нагрузки на доступные сервера, а также некоторых географических соображений.

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

Ресурсоемкие вычисления

Во многих приложениях используются какие-либо сложные механизмы, это может быть конвертирование видео, изображений, звука, или просто выполнение каких-либо ресурсоемких вычислений. Такие задачи требует отдельного внимания если мы говорим о Сети, так как пользователь интернет-ресурса врядли будет счастлив наблюдать за загружающейся несколько минут страницей в ожидании лишь для того, чтобы увидеть сообщение вроде: «Операция завершена успешно!».

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

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

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

Сессии

Практически все веб-приложения каким-либо образом взаимодействуют со своими посетителями и в подавляющем большинстве случаев в них присутствует необходимость отслеживать перемещения пользователей по страницам сайта. Для решения этой задачи обычно используется механизм сессий, который заключается в присвоении каждому посетителю уникального идентификационного номера, который ему передается для хранения в cookies или, в случае их отсутствия, для постоянного «таскания» за собой через GET. Получив от пользователя некий ID вместе с очередным HTTP-запросом сервер может посмотреть в список уже выданных номеров и однозначно определить кто его отправил. С каждым ID может ассоциироваться некий набор данных, который веб-приложение может использовать по своему усмотрению, эти данные обычно по-умолчанию хранятся в файле во временной директории на сервере.

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

Наиболее распространенными решениями является централизация или децентрализация сессионных данных. Несколько абсурдная фраза, но, надеюсь, пара примеров сможет прояснить ситуацию:

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

В качестве альтернативы сессиям иногда используют похожие по предназначению механизмы, построенные на cookies, то есть все необходимые приложению данные о пользователе хранятся на клиентской стороне (вероятно в зашифрованном виде) и запрашиваются по мере необходимости. Но помимо очевидных преимуществ, связанных с отсутствием необходимости хранить лишние данные на сервере, возникает ряд проблем с безопасностью. Данные, хранимые на стороне клиента даже в зашифрованном виде, представляют собой потенциальную угрозу для функционирования многих приложений, так как любой желающий может попытаться модифицировать их в своих интересах или с целью навредить приложению. Такой подход хорош только если есть уверенность, что абсолютно любые манипуляции с хранимые у пользователей данными безопасны. Но можно ли быть уверенными на 100%?

Статический контент

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

Если статический контент играет одну из основных ролей в работе приложения, то стоит задуматься о применении распределенной файловой системы для его хранения. Это, пожалуй, один из немногих способов горизонтально масштабировать объем дискового пространства путем добавления дополнительных серверов без каких-либо кардинальных изменений в работе самого приложения. На какой именно кластерной файловой системе остановить свой выбор ничего сейчас советовать не хочу, я уже опубликовал далеко не один обзор конкретных реализаций — попробуйте прочитать их все и сравнить, если этого мало — вся остальная Сеть в Вашем распоряжении.

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

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

Кэширование

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

СУБД Практически все современные СУБД предоставляют встроенные механизмы для кэширования результатов определенных запросов. Этот метод достаточно эффективен, если Ваша система регулярно делает одни и те же выборки данных, но также имеет ряд недостатков, основными из которых является инвалидация кэша всей таблицы при малейшем ее изменении, а также локальное расположение кэша, что неэффективно при наличии нескольких серверов в системе хранения данных. Приложение На уровне приложений обычно производится кэширование объектов любого языка программирования. Этот метод позволяет вовсе избежать существенной части запросов к СУБД, сильно снижая нагрузку на нее. Как и сами приложения такой кэш должен быть независим от конкретного запроса и сервера, на котором он выполняется, то есть быть доступным всем серверам приложений одновременно, а еще лучше — быть распределенным по нескольким машинам для более эффективной утилизации оперативной памяти. Лидером в этом аспекте кэширования по праву можно назвать memcached, о котором я в свое время уже успел подробно рассказать. HTTP-сервер Многие веб-серверы имеют модули для кэширования как статического контента, так и результатов работы скриптов. Если страница редко обновляется, то использование этого метода позволяет без каких-либо видимых для пользователя изменений избегать генерации страницы в ответ на достаточно большую часть запросов. Reverse proxy Поставив между пользователем и веб-сервером прозрачный прокси-сервер, можно выдавать пользователю данные из кэша прокси (который может быть как в оперативной памяти, так и дисковым), не доводя запросы даже до HTTP-серверов. В большинстве случаев этот подход актуален только для статического контента, в основном разных форм медиа-данных: изображений, видео и тому подобного. Это позволяет веб-серверам сосредоточиться только на работе с самими страницами.

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

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

Базы данных

На закуску я оставил самое интересное, ведь этот неотъемлемый компонент любого веб-приложения вызывает больше проблем при росте нагрузок, чем все остальные вместе взятые. Порой даже может показаться, что стоит вообще отказаться от горизонтального масштабирования системы хранения данных в пользу вертикального — просто купить тот самый БОЛЬШОЙ сервер за шести- или семизначную сумму не-рублей и не забивать себе голову лишними проблемами.

Но для многих проектов такое кардинальное решение (и то, по большому счету, временное) не подходит, а значит перед ними осталась лишь одна дорога — горизонтальное масштабирование. О ней и поговорим.

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

Следующим шагом обычно бывает master-slave с асинхронной репликацией данных, как работает эта схема уже неоднократно упоминалось в блоге, но, пожалуй, повторюсь: при таком подходе все операции записи выполняются лишь на одном сервере (master), а остальные сервера (slave) получают данные напрямую от «мастера», обрабатывая при этом лишь запросы на чтение данных. Как известно, операции чтения и записи любого веб-проекта всегда растут пропорционально росту нагрузки, при этом сохраняется почти фиксированным соотношение между обоими типами запросов: на каждый запрос на обновление данных обычно приходится в среднем около десятка запросов на чтение. Со временем нагрузка растет, а значит растет и количество операций записи в единицу времени, а сервер-то обрабатывает их всего один, а затем он же еще и обеспечивает создание некоторого количества копий на других серверах. Рано или поздно издержки операций репликации данных станут быть настолько высоки, что этот процесс станет занимать очень большую часть процессорного времени каждого сервера, а каждый slave сможет обрабатывать лишь сравнительно небольшое количество операций чтения, и, как следствие, каждый дополнительный slave-сервер начнет увеличивать суммарную производительность лишь незначительно, тоже занимаясь по большей части лишь поддержанием своих данных в соответствии с «мастером».

Временным решением этой проблемы, возможно, может стать замена master-сервера на более производительный, но так или иначе не выйдет бесконечно откладывать переход на следующий «уровень» развития системы хранения данных: «sharding», которому я совсем недавно посвятил отдельный пост «Сегментирование баз данных». Так что позволю себе остановиться на нем лишь вкратце: идея заключается в том, чтобы разделить все данные на части по какому-либо признаку и хранить каждую часть на отдельном сервере или кластере, такую часть данных в совокупности с системой хранения данных, в которой она находится, и называют сегментом или shard’ом. Такой подход позволяет избежать издержек, связанных с реплицированием данных (или сократить их во много раз), а значит и существенно увеличить общую производительность системы хранения данных. Но, к сожалению, переход к этой схеме организации данных требует массу издержек другого рода. Так как готового решения для ее реализации не существует, приходится модифицировать логику приложения или добавлять дополнительную «прослойку» между приложением и СУБД, причем все это чаще всего реализуется силами разработчиков проекта. Готовые продукты способны лишь облегчить их работу, предоставив некий каркас для построения основной архитектуры системы хранения данных и ее взаимодействия с остальными компонентами приложения.

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

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

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

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

Map Основной целью данного этапа является представление произвольных входных данных в виде промежуточных пар ключ-значение, имеющих определенный смысл и формально оформленных. Результаты подвергаются сортировке и группированию по ключу, а после чего передаются на следующий этап. Reduce Полученные после map значения используются для финального вычисления требуемых итоговых данных.

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

Примером готового каркаса для реализации работы с данными по такому принципу служит opensource проект Apache Foundation под названием Hadoop, о котором я уже неоднократно рассказывал ранее, да и статейку в Википедию написал в свое время.

Вместо заключения

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

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

Разработка web-приложений с использованием технологии ASP.Net MVC

Web-приложения разработанные по технологии ASP.Net MVC в отличии от Web Forms приложений, состоят не из набора классов производных от класса Раде (web-форм), которые включают серверные элементы управления, а из классов трех типов:

  • контроллеры (Controller) – классы, включающие методы (действия), которые могут быть вызваны с помощью запроса пользователя к приложению;
  • представления (View) – задаются в виде шаблона, на основе которого генерируются специальные классы описывающего формирование HTML-ответы пользователю;
  • модели классы разных типов, содержащие данные, которые передаются от контроллеров в представления для формирования ответов.

Особенность технологии MVC состоит в том, что пользователь указывает в URL-адресе не путь к физическому ресурсу (например, *.html или *.aspx), а запрос на выполнение некоторого действия – открытого (public) метода класса-контроллера. Например: myprog.ru/Home/lndex/5 (такому URL никакой ресурс не соответствует). Порядок обработки таких запросов классами MVC-приложения показан на рис. 4.23.

Рис. 4.23. Порядок обработки запроса к MVC-приложению

Общая логика работы ASP.Net MVC приложения показана на рис. 4.24.

Рис. 4.24. Логика работы ASP.Net МVС приложений


Если сравнить данную схему с логикой работы ASP.Nel Web Forms приложений (рис. 4.1), то видно, что они во многом сходны (это два фреймворка технологии ASP.Net). У приложений, созданных с использованием фреймверков ASP.Net Web Forms и MVC, имеются общие возможности: конфигурирование; обеспечение безопасности (классы по работе с учетными записями и ролями); поддержка состояния сеанса и приложения; кэширование. В принципе, в одной приложении можно использовать возможности обоих фреймверков.

Отличие ASP.Net Web Forms и MVC между заключается только в использовании другого МТТР-обработчика. Данный обработчик создает требуемый контроллер и вызывает указанный метод.

В ASP.NET MVC разработчик имеет почти те же самые функциональные возможности по созданию web-приложений, какие есть и в Web Forms, но они реализуются с помощью другого набора инструментов. Фреймвер ASP.NET MVC использует другой шаблон, который не основывается на web-формах (Раде) и полагается на много более тонкий слой абстракции. В результате у разработчика нет сложных, встроенных компонент для быстрого создания пользовательского интерфейса, в котором элементы могут поддерживаться.

В ASP.NET MVC разработчик пишет код, который концептуально и физически ближе к базовым Интернет технологиям; поэтому он требует большего объема программирования, но в тоже время дает ему больше контроля над формируемым FITML-кодом и реальным поведением среды выполнения приложения. Однако, разработчик не должен все писать с нуля. Он имеет в своем распоряжении

  • • HTML-помощьники (helpers) для автоматического создания (достаточно) простых, но функциональных средств визуализации и редактирования для любых простых и сложных типов;
  • • атрибуты классов (дополнительные метаданные) для аннотирования данных, для декларативного задания требуемого содержания полей и способов их представления;
  • • средства связывания для автоматического преобразования передаваемых в запросе данных с параметрами методов-действий контроллеров;
  • • средства (тоже на основе атрибутов) для проверки вводимых пользователями данных, как на стороне клиента, так и на стороне сервера.
Илон Маск рекомендует:  Что такое код cpdf_page_init

Архитектура технологии разработки веб-приложений Asp. Net Core MVC Текст научной статьи по специальности « Автоматика. Вычислительная техника»

Аннотация научной статьи по автоматике и вычислительной технике, автор научной работы — Шарапов Николай Романович

Технология разработки веб-приложений ASP.NET Core MVC является актуальной. Соответственно имеется необходимость в анализе архитектуры данной технологии.

Похожие темы научных работ по автоматике и вычислительной технике , автор научной работы — Шарапов Николай Романович,

Текст научной работы на тему «Архитектура технологии разработки веб-приложений Asp. Net Core MVC»

- Возможность введения зависимостей;

— Расширяемость, основывающаяся на возможности добавления в проект дополнительных компонентов.

Таким образом, сравнивая ASP.NET с другими широко используемыми средствами веб-разработки, такими как PHP, Node.js или Ruby on Rails, можно выделить одно ключевое достоинство. Перечисленные платформы являются интерпретируемыми, в то время как C# — компилируемый язык. Это дает системе .NET серьезное преимущество в скорости работы. Все компоненты, не требуя интерпретатора, работают с фреймворком, который, в свою очередь, также скомпилирован и вызывает напрямую функции операционной системы, а большинство ошибок отлавливаются разработчиком в момент компиляции. Также наличие паттерна MVC позволяет разграничить написание кода на 3 основные части, что в свою очередь значительно добавляет удобство пользования.

1. ASP.NET Core. [Электронный ресурс], 2020. Режим доступа: https://www.asp.net/core/overview/aspnet-vnext/ (дата обращения: 02.07.2020).

2. ASP.NET Core. [Электронный ресурс], 2020. Режим доступа: https://metanit.com/sharp/aspnet5/ (дата обращения: 04.07.2020).

АРХИТЕКТУРА ТЕХНОЛОГИИ РАЗРАБОТКИ ВЕБ-ПРИЛОЖЕНИЙ ASP.NET CORE MVC Шарапов Н.Р.

Шарапов Николай Романович — бакалавр, направление: информационные системы и технологии, кафедра геоинформационных систем, факультет информатики и робототехники, Уфимский государственный авиационный технический университет, г. Уфа

Аннотация: технология разработки веб-приложений ASP.NET Core MVC является актуальной. Соответственно имеется необходимость в анализе архитектуры данной технологии.

Ключевые слова: ASP.NET Core MVC, архитектура, веб-приложение.

ASP.NET Core MVC

ASP.NET Core является кроссплатформенной, высокопроизводительной средой с открытым исходным кодом для создания современных облачных приложений, подключенных к Интернету. Приложения ASP.Net Core, разработанные с помощью паттерна MVC, имеют соответствующий архитектурный шаблон: модель -представление — контроллер [1].

Модель — описывает используемые в приложении данные, а также логику, которая связана непосредственно с данными. Как правило, объекты моделей хранятся в базе данных.

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

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

ASP.NET Core MVC предоставляет функции, которые позволяют эффективно создавать веб-интерфейсы API и веб-приложения:

— Шаблон Model-View-Controller (MVC) помогает сделать веб-API и веб-приложения тестируемыми.

— Страницы Razor — это основанная на страницах модель программирования, которая упрощает создание пользовательского веб-интерфейса и повышает его эффективность.

— Разметка Razor предоставляет эффективный синтаксис для страниц Razor и представлений MVC.

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

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

— Привязка модели автоматически сопоставляет данные из HTTP-запросов с параметрами методов действия.

— Проверка модели автоматически выполняется на стороне сервера и клиента.

Архитектура ASP.NET Core MVC показана на рисунке 1.

Рис. 1. Архитектура ASP.NET Core MVC

Ниже приведена последовательность шагов взаимодействия пользователя с вебсайтом, разработанным с помощью технологии ASP.NET Core MVC:

1. Пользователь вводит URL-адрес в браузере и осуществляет запрос.

2. Запрос доходит до веб-сервера и перенаправляется на механизм маршрутизации.

3. На основе URL, механизм маршрутизации выбирает соответствующий контроллер.

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

5. Контроллер вызывает механизм просмотра и возвращает представление страниц.

6. Контроллер возвращает полученное представление.

7. Запрошенный ресурс отправляется обратно в браузер.

Asp разработка масштабируемых веб приложений

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

Для начала имеет смысл определиться с тем, о чем мы вообще будем говорить. В данном контексте перед веб-приложением ставятся три основные цели:

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

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

Масштабируемость принято разделять на два направления:

Вертикальная масштабируемость Увеличение производительности каждого компонента системы c целью повышения общей производительности. Горизонтальная масштабируемость Разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим машинам (или их группам) и/или увеличение количества серверов параллельно выполняющих одну и ту же функцию.

Так или иначе, при разработке стратегии роста системы приходится искать компромис между ценой, временем разработки, итоговой производительность, стабильностью и еще массой других критериев. С финансовой точки зрения вертикальная масштабируемость является далеко не самым привлекательным решением, ведь цены на сервера с большим количеством процессоров всегда растут практически экспоненциально относительно количества процессоров. Именно по-этому наиболее интересен горизонтальный подход, так как именно он используется в большинстве случаев. Но и вертикальная масштабируемость порой имеет право на существование, особенно в ситуациях, когда основную роль играет время и скорость решения задачи, а не финансовый вопрос: ведь купить БОЛЬШОЙ сервер существенно быстрее, чем практически заново разрабатывать приложения, адаптируя его к работе на большом количестве параллельно работающих серверов.

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

Серверы приложений

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

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

Балансировка нагрузки

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

Оборудование Сетевое оборудование, позволяющее распределять нагрузку между несколькими серверами, обычно стоит достаточно внушительные суммы, но среди прочих вариантов обычно именно этот подход предлагает наивысшую производительность и стабильность (в основном благодаря качеству, плюс такое оборудование иногда поставляется парами, работающими по принципу HeartBeat). В этой индустрии достаточно много серьезных брендов, предлагающих свои решения — есть из чего выбрать: Cisco, Foundry, NetScalar и многие другие. Программное обеспечение В этой области еще большее разнообразие возможных вариантов. Получить программно производительность сопоставимую с аппаратными решениями не так-то просто, да и HeartBeat придется обеспечивать программно, но зато оборудование для функционирования такого решения представляет собой обычный сервер (возможно не один). Таких программных продуктов достаточно много, обычно они представляют собой просто HTTP-серверы, перенаправляющие запросы своим коллегам на других серверах вместо отправки напрямую на обработку интерпретатору языка программирования. Для примера можно упомянуть, скажем, nginx с mod_proxy . Помимо этого имеют место более экзотические варианты, основанные на DNS, то есть в процессе определения клиентом IP-адреса сервера с необходимым ему интернет-ресурсов адрес выдается с учетом нагрузки на доступные сервера, а также некоторых географических соображений.

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

Ресурсоемкие вычисления

Во многих приложениях используются какие-либо сложные механизмы, это может быть конвертирование видео, изображений, звука, или просто выполнение каких-либо ресурсоемких вычислений. Такие задачи требует отдельного внимания если мы говорим о Сети, так как пользователь интернет-ресурса врядли будет счастлив наблюдать за загружающейся несколько минут страницей в ожидании лишь для того, чтобы увидеть сообщение вроде: «Операция завершена успешно!».

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

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

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

Сессии

Практически все веб-приложения каким-либо образом взаимодействуют со своими посетителями и в подавляющем большинстве случаев в них присутствует необходимость отслеживать перемещения пользователей по страницам сайта. Для решения этой задачи обычно используется механизм сессий, который заключается в присвоении каждому посетителю уникального идентификационного номера, который ему передается для хранения в cookies или, в случае их отсутствия, для постоянного «таскания» за собой через GET. Получив от пользователя некий ID вместе с очередным HTTP-запросом сервер может посмотреть в список уже выданных номеров и однозначно определить кто его отправил. С каждым ID может ассоциироваться некий набор данных, который веб-приложение может использовать по своему усмотрению, эти данные обычно по-умолчанию хранятся в файле во временной директории на сервере.

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

Наиболее распространенными решениями является централизация или децентрализация сессионных данных. Несколько абсурдная фраза, но, надеюсь, пара примеров сможет прояснить ситуацию:

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

В качестве альтернативы сессиям иногда используют похожие по предназначению механизмы, построенные на cookies, то есть все необходимые приложению данные о пользователе хранятся на клиентской стороне (вероятно в зашифрованном виде) и запрашиваются по мере необходимости. Но помимо очевидных преимуществ, связанных с отсутствием необходимости хранить лишние данные на сервере, возникает ряд проблем с безопасностью. Данные, хранимые на стороне клиента даже в зашифрованном виде, представляют собой потенциальную угрозу для функционирования многих приложений, так как любой желающий может попытаться модифицировать их в своих интересах или с целью навредить приложению. Такой подход хорош только если есть уверенность, что абсолютно любые манипуляции с хранимые у пользователей данными безопасны. Но можно ли быть уверенными на 100%?

Статический контент

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

Если статический контент играет одну из основных ролей в работе приложения, то стоит задуматься о применении распределенной файловой системы для его хранения. Это, пожалуй, один из немногих способов горизонтально масштабировать объем дискового пространства путем добавления дополнительных серверов без каких-либо кардинальных изменений в работе самого приложения. На какой именно кластерной файловой системе остановить свой выбор ничего сейчас советовать не хочу, я уже опубликовал далеко не один обзор конкретных реализаций — попробуйте прочитать их все и сравнить, если этого мало — вся остальная Сеть в Вашем распоряжении.

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

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

Кэширование

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

СУБД Практически все современные СУБД предоставляют встроенные механизмы для кэширования результатов определенных запросов. Этот метод достаточно эффективен, если Ваша система регулярно делает одни и те же выборки данных, но также имеет ряд недостатков, основными из которых является инвалидация кэша всей таблицы при малейшем ее изменении, а также локальное расположение кэша, что неэффективно при наличии нескольких серверов в системе хранения данных. Приложение На уровне приложений обычно производится кэширование объектов любого языка программирования. Этот метод позволяет вовсе избежать существенной части запросов к СУБД, сильно снижая нагрузку на нее. Как и сами приложения такой кэш должен быть независим от конкретного запроса и сервера, на котором он выполняется, то есть быть доступным всем серверам приложений одновременно, а еще лучше — быть распределенным по нескольким машинам для более эффективной утилизации оперативной памяти. Лидером в этом аспекте кэширования по праву можно назвать memcached, о котором я в свое время уже успел подробно рассказать. HTTP-сервер Многие веб-серверы имеют модули для кэширования как статического контента, так и результатов работы скриптов. Если страница редко обновляется, то использование этого метода позволяет без каких-либо видимых для пользователя изменений избегать генерации страницы в ответ на достаточно большую часть запросов. Reverse proxy Поставив между пользователем и веб-сервером прозрачный прокси-сервер, можно выдавать пользователю данные из кэша прокси (который может быть как в оперативной памяти, так и дисковым), не доводя запросы даже до HTTP-серверов. В большинстве случаев этот подход актуален только для статического контента, в основном разных форм медиа-данных: изображений, видео и тому подобного. Это позволяет веб-серверам сосредоточиться только на работе с самими страницами.

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

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

Базы данных

На закуску я оставил самое интересное, ведь этот неотъемлемый компонент любого веб-приложения вызывает больше проблем при росте нагрузок, чем все остальные вместе взятые. Порой даже может показаться, что стоит вообще отказаться от горизонтального масштабирования системы хранения данных в пользу вертикального — просто купить тот самый БОЛЬШОЙ сервер за шести- или семизначную сумму не-рублей и не забивать себе голову лишними проблемами.

Но для многих проектов такое кардинальное решение (и то, по большому счету, временное) не подходит, а значит перед ними осталась лишь одна дорога — горизонтальное масштабирование. О ней и поговорим.

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

Следующим шагом обычно бывает master-slave с асинхронной репликацией данных, как работает эта схема уже неоднократно упоминалось в блоге, но, пожалуй, повторюсь: при таком подходе все операции записи выполняются лишь на одном сервере (master), а остальные сервера (slave) получают данные напрямую от «мастера», обрабатывая при этом лишь запросы на чтение данных. Как известно, операции чтения и записи любого веб-проекта всегда растут пропорционально росту нагрузки, при этом сохраняется почти фиксированным соотношение между обоими типами запросов: на каждый запрос на обновление данных обычно приходится в среднем около десятка запросов на чтение. Со временем нагрузка растет, а значит растет и количество операций записи в единицу времени, а сервер-то обрабатывает их всего один, а затем он же еще и обеспечивает создание некоторого количества копий на других серверах. Рано или поздно издержки операций репликации данных станут быть настолько высоки, что этот процесс станет занимать очень большую часть процессорного времени каждого сервера, а каждый slave сможет обрабатывать лишь сравнительно небольшое количество операций чтения, и, как следствие, каждый дополнительный slave-сервер начнет увеличивать суммарную производительность лишь незначительно, тоже занимаясь по большей части лишь поддержанием своих данных в соответствии с «мастером».

Временным решением этой проблемы, возможно, может стать замена master-сервера на более производительный, но так или иначе не выйдет бесконечно откладывать переход на следующий «уровень» развития системы хранения данных: «sharding», которому я совсем недавно посвятил отдельный пост «Сегментирование баз данных». Так что позволю себе остановиться на нем лишь вкратце: идея заключается в том, чтобы разделить все данные на части по какому-либо признаку и хранить каждую часть на отдельном сервере или кластере, такую часть данных в совокупности с системой хранения данных, в которой она находится, и называют сегментом или shard’ом. Такой подход позволяет избежать издержек, связанных с реплицированием данных (или сократить их во много раз), а значит и существенно увеличить общую производительность системы хранения данных. Но, к сожалению, переход к этой схеме организации данных требует массу издержек другого рода. Так как готового решения для ее реализации не существует, приходится модифицировать логику приложения или добавлять дополнительную «прослойку» между приложением и СУБД, причем все это чаще всего реализуется силами разработчиков проекта. Готовые продукты способны лишь облегчить их работу, предоставив некий каркас для построения основной архитектуры системы хранения данных и ее взаимодействия с остальными компонентами приложения.

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

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

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

Илон Маск рекомендует:  Глава 11 автоматизированная разработка программ с помощью утитлиты make

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

Map Основной целью данного этапа является представление произвольных входных данных в виде промежуточных пар ключ-значение, имеющих определенный смысл и формально оформленных. Результаты подвергаются сортировке и группированию по ключу, а после чего передаются на следующий этап. Reduce Полученные после map значения используются для финального вычисления требуемых итоговых данных.

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

Примером готового каркаса для реализации работы с данными по такому принципу служит opensource проект Apache Foundation под названием Hadoop, о котором я уже неоднократно рассказывал ранее, да и статейку в Википедию написал в свое время.

Вместо заключения

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

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

Asp разработка масштабируемых веб приложений

Теперь рассмотрим на практике работу Web API. Создадим новое приложение MVC 5 по типу Web API. Назовем его, его например, BookingApp:

И вначале определим класс модели, с объеками которой будет работать приложение. Этот класс по традиции будет описывать книгу. Итак, добавим в папку Models новый класс Book:

Если проект по умолчанию не содержит библиотек EF, установим через NuGet пакет Entity Framework в проект и добавим в папку Models класс контекста данных BookContext:

В файле web.config установим подключение к базе данных, которая будет хранить все объекты:

Теперь для начальной работы инициализируем базу данных некоторыми начальными данными. Мы можем либо создать базу данных вручную и добавить в нее данные, либо можно использовать инициализатор баз данных. Воспользуемся вторым способом. Добавим в папку Models следующий класс:

И подключим инициализатор в файле Global.asax:

Теперь перейдем к созданному по умолчанию контроллеру ValuesController и изменим его следующим образом:

Таким образом, получится контроллер, реализующий CRUD-модель, то есть добавление, получение, обновление и удаление данных.

Но то же самое мы могли бы сделать автоматически, использовав шаблоны формирования при создании контроллера. Для этого просто при создании нового API-контроллера укажем модель и класс контекста данных, которые будут использоваться (перед использованием модели приложение необходимо скомпилировать):

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

Итак, теперь мы можем перейти к построению клиентской части, но перед этим протестируем приложение. Для тестирования воспользуемся браузером, например, Internet Explorer, который может дать нам полную информацию о запросе с помощью средств разработчика:

По умолчанию при запуске проекта идет обращение к другому стандартному контроллеру HomeController и его методу Index, которое возвращает представление. Нам пока это представление не интересует. Обратимся к контроллеру Web API. Для этого отправим запрос api/values/ (в моем случае полный запрос выглядит следующим образом:http://localhost:1479/api/values/). Поскольку этот запрос представляет запрос GET, то данный запрос будет обрабатываться методом public IEnumerable GetBooks() , возвращающим все объекты из БД.

После этого браузер предложит нам сохранить файл json со всеми объектами, которые были получены из базы данных:

При использовании других браузеров (Firefox, Google Chrome) мы получим те же данные, только в формате xml.

Таким образом, мы убедились, что приложение работает. И теперь перейдем к построению клиентской части приложения.

ASP .NET — технология разработки Web-приложений от Microsoft

Технология Active Server Pages .NET (ASP .NET) — один из важнейших компонентов всей архитектуры Microsoft .NET. Обоснование этого утверждения вполне очевидно — ведь стратегической целью .NET объявлено создание инфраструктуры для разработки и функционирования распределенных приложений на базе Интернет-стандартов.

Говоря об Интернет-приложениях, мы традиционно подразумеваем в первую очередь Web-приложения, т. е. такие серверные программы, доступ к которым пользователи получают через Web-браузер. Именно для создания подобных Web-приложений предназначена технология ASP .NET. Однако полезно напомнить, что под определение «распределенные» (в классическом его понимании) гораздо больше подходят системы, реализованные на основе иных механизмов удаленного взаимодействия программных компонентов. Применительно к .NET — это технологии XML Web Services (на базе открытых стандартов) и .NET Remoting (внутренние протоколы Microsoft)*.

*О технологиях Web Services и .NET Remoting см. соответственно статьи в «BYTE/Россия» № 9’2001 и «Remoting.NET, или Удаленное взаимодействие объектов есть», «BYTE/Россия» № 4’2002.

Однако, прежде чем перейти к теме ASP .NET, хотелось затронуть один принципиально важный момент. В современном мире нельзя рассматривать технологию в отрыве от проблем маркетинга, т. е. бизнес-модели компании — поставщика этой технологии. Об этом, к сожалению, очень часто забывают в своих дискуссиях даже ИТ-профессионалы. Надо помнить, что для компании-вендора создание программного продукта — лишь средство решения ее коммерческой задачи. (Выбор бизнес-модели под будущие свои продукты могут себе позволить лишь «стартующие» фирмы.)

В кулуарных разговорах мы довольно часто снисходительно говорим о казалось бы откровенных «ляпах» в тех или иных продуктах. Но что скрывается за этими «прорехами» — недальновидность поставщика, его неспособность к решению технических задач или тонкий стратегический расчет? Впрочем, какое дело нам, пользователям, до бизнес-проблем поставщика — мы ведь лишь выбираем наиболее подходящую технологию. Но все обстоит не так просто, хотя бы потому, что эту технологию приходится увязывать со многими другими вещами. И судьба поставщика нам не безразлична — если он обанкротится, то что мы будем делать с его прекрасной технологией?

Именно в контексте этого соображения мне хотелось бы еще раз обратить внимание на вопрос, который я в той или иной степени затрагиваю во всех своих публикациях по этой тематике: что же такое Microsoft .NET?

От ASP к ASP .NET

В конце 1997 г. Microsoft предложила технологию Active Server Pages (ASP) как средство динамического формирования HTLM-страниц. ASP изначально представляет собой часть сервера Microsoft Internet Information Server. ASP .NET (сначала она называлась ASP+) — это новая версия ASP.

Между ASP .NET и ASP довольно много различий. Конечно же, появилось много новых функций и возможностей. Но самое главное заключается в том, что программный код, который в ASP был включен непосредственно в состав HTML-страницы, теперь выделен в отдельный исполняемый модуль, откомпилированный для среды .NET. А код можно создавать с помощью любого языка программирования .NET.

Впрочем, механизм разделения HTML и программного кода был реализован и в старой версии ASP. Многие Web-разработчики заблуждаются, думая, что ASP связана исключительно с применением VBScript или JavaScript. На самом деле IIS задействует технологию Active Scripting, открытые интерфейсы которой позволяют разрабатывать и подключать произвольные языки сценариев. Именно эта возможность используется в Web-компоненте фирмы «1С», предусматривающем создание ASP-приложений с применением встроенного языка «1С:Предприятие 7.7» (см. «Разработка Web-приложений для «1С:Предприятие», «BYTE/Россия» № 4’2001, с. 48).

Более того, вариант создания Web-приложений, реализованный в Visual Basic 6.0 (см. статью «Visual Basic 6.0 упрощает разработку для Web» по адресу http://www.microsoft.com/rus/msdn/library/kolesov), предполагал как раз отделение программного кода от пользовательского интерфейса (HTML-кода) и оформление его в виде ActiveX DLL. Другое дело, что визуальные средства разработки Web-приложений в VB 6.0, хотя и знаменовали прогресс по сравнению с VB 5.0, но были откровенно слабее того, что предлагается для создания обычных Windows-приложений. Да и сама логика Web-разработки была отнюдь не простой.

Здесь мы подходим к формулировке второй задачи, которая стояла перед создателями Visual Studio .NET: сделать так, чтобы разработка Web-приложений была не сложнее программирования традиционных Windows-приложений и чтобы можно было максимально перенести опыт Windows-разработки в сферу Интернета.

Отметим сразу — обе эти задачи (отделение HTML от исполняемого кода и объединение логики разработки для Web и для Windows) в целом Microsoft решила. Но при этом подчеркнем: вся технология ASP .NET функционирует только в среде .NET.

Простейшее Web-приложение

Давайте посмотрим, как выглядит общая логика разработки простейшего приложения ASP .NET. Запустим Visual Studio .NET и создадим новый проект типа ASP .NET с использованием языка Visual Basic (рис. 1). Откроем окно с панелью инструментов Toolbox, выберем на ней вкладку Web Forms и с ее помощью разместим на форме проекта три элемента управления — Label1, TextBox1 и Button1.

Рис. 1. Выбор проекта Web Application в Visual Studio .NET.

Мы хотим, чтобы при нажатии командной кнопки Button1содержимое текстового поля TextBox1 заносилось в метку Label1. Для этого дважды щелкнем по изображению кнопки и в раскрывшемся окне кода введем программу обработки для события Button1_Click:

Запустим созданный проект на выполнение и убедимся, что он работает, как и было задумано (рис. 2). Как мы видим, разработка Web-приложения практически ничем (по крайнем мере, пока) не отличается от создания традиционной Windows-программы.

Рис. 2. Разработка проекта ASP .NET: на заднем плане — окно со средой разработки VS.NET, на переднем — окно Internet Explorer с созданным нами Web-приложением.

А теперь разберемся, из чего состоит наше простейшее приложение. В правом верхнем углу панели Solution Explorer (рис. 2) мы видим несколько компонентов, но сейчас нас интересует только модуль WebForm1.Aspx, который и является файлом ASP .NET, загружаемым в браузер. Просмотрим его содержимое, открыв вкладку HTML:

Обратите внимание, что модуль WebForm.aspx.vb (кстати, использование «точки» в составном имени файла представляется крайне неудачной идеей — возникает постоянная путаница с самим названием и типом файла) в явном виде никак не отображен в окне Solution Explorer, так как он должен быть однозначно привязан к основному ASPX-файлу.

Итак, мы создали приложение, затратив минимум усилий, однако отметим одно настораживающее обстоятельство: если мы с помощью функции Search попробуем найти созданный файл проекта WebSollution1, то обнаружим около двух десятков (!) каталогов и файлов с различными расширениями. Конечно, можно сослаться на то, что все они были сформированы автоматически. Но подобное обилие созданных модулей и папок, существующих вне нашего контроля (и вне понимания, зачем они нужны), несет в себе скрытую угрозу надежности работы приложения, не говоря уже о проблеме очистки мусора в файловой системе, если нам это приложение больше не понадобится.

Теперь поставим еще один небольшой эксперимент. Добавим в проект одну командную кнопку, но только не из вкладки Web Forms, а из HTML. В ASPX-файле она будет описана таким тегом:

Формирование обрабатывающего кода для кнопки выполняется аналогичным образом (но только сначала нужно правой кнопкой мыши вызвать контекстное меню для этого элемента и указать для него режим Run as Server Control). Однако между двумя вариантами кнопок есть одно принципиальное различие — в обычном HTML-редакторе, например, FrontPage, будут видны только стандартные элементы управления HTML (в нашем случае — одна командная кнопка).

Этот момент представляется очень важным, так как технология разработки Web-приложений, реализованная в VS.NET, принципиально отличается от схемы работы традиционных HTML-редакторов, которые сегодня (пока) не поддерживают работу с отдельными файлами программного кода. Перед искушенными Web-дизайнерами неминуемо возникнет дилемма: воспользоваться мощными средствами программирования VS.NET или богатыми средствами Web-дизайна профессиональных HTML-редакторов?

Какой из этих двух вариантов получит наибольшее распространение, мы увидим в недалеком будущем, но мой прогноз таков: учитывая упорство Microsoft в достижении своих целей, можно практически гарантировать, что независимым разработчикам HTML-редакторов неминуемо придется позаботиться об интеграции с технологией ASP .NET вообще и с Visual Studio .NET в частности.

Специальный инструмент разработки приложений ASP .NET

В июле 2002 г. Microsoft выпустила предварительную «технологическую» версию (Technology Preview) специализированного визуального инструмента для разработки ASP .NET — ASP .NET Web Matrix. Ее можно бесплатно загрузить с сайта http://www.asp.net (дистрибутив 1,2 Мбайт). Авторские права на продукт принадлежат Microsoft, но он был разработан не сотрудниками корпорации, а группой независимых специалистов, которая выполняет заказы ASP-подразделения Microsoft в свободное от основной работы время (среди авторов программы встречаются и русские имена).

Первая строка кода проекта была написана ровно за год до выпуска его «технологического» релиза, сейчас в нем около 150 тыс. строк. ASP .NET Web Matrix написан на C# и .NET Framework, пользовательский интерфейс реализован с помощью Windows Forms, доступ к данным — на базе ADO.NET. Некоторая часть ресурсов и служб пакета (в частности, справочная система) размещена на сервере http://www.asp.net, обращение к ним выполняется через механизм XML Web Services.

Конструктор страниц Web Matrix предоставляет интегрированные средства для создания и редактирования баз данных SQL и MSDE. Код ADO.NET для выполнения SQL-запросов и хранимых процедур генерируется автоматически; связывание данных страниц не требует написания кода. С помощью Web Matrix пользователь может встраивать в свои приложения поддержку XML Web Services, разрабатывать мобильные Web-приложения для таких устройств, как сотовые телефоны, пейджеры и PDA. Для разработки и тестирования приложений ASP .NET не требуется сервер IIS — Web Matrix включает облегченный варианта персонального Web-сервера, в котором многие функции (например, поддержка страниц ASP .NET иXML Web Services) реализованы в локальном режиме.

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

Будучи удобным специализированным инструментом, Web Matrix все же вряд ли сможет заменить Visual Studio .NET при создании профессиональных приложений. Прежде всего Web Matrix (по крайней мере в предварительном «технологическом» варианте) не поддерживает основную для ASP .NET идею разделения кодов. У него существенно слабее средства отладки, нет редактора с интеллектуальной подсказкой, не говоря уже о применении средств категории Enterprise. Продукт не будет поддерживаться службой Microsoft Product Support Services — вся поддержка будет выполняться онлайновым сообществом независимых разработчиков (http://www.asp.net).

Чтобы познакомиться с Web Matrix, создадим с его помощью простое приложение, аналогичное тому, что мы сделали в VS.NET.

Откройте Microsoft ASP .NET Web Matrix — появится диалоговое окно New File, в котором мы видим несколько различных начальных шаблонов проекта (рис. 3). Обратите внимание, что для каждой категории шаблонов, представленных в левом окне (Data Pages, Mobile Pages и пр.), имеется своя группа типов проектов. Выберите шаблон проекта General и ASP .NET Page, а в списке Language укажите Visual Basic, после чего нажмите OK.

Рис. 3. Web Matrix предлагает разные шаблоны для создания Web-приложений.

Со вкладки Web Controls панели инструментов Toolbox перетащите на создаваемую страницу элементы управления Label, TextBox и Button. Двойным щелчком на изображении кнопки перейдите к редактированию ее процедуры Button1_Click. Введите следующий код:

Запустите приложение на выполнение и убедитесь в его работоспособности. Теперь рассмотрим содержание созданного приложения. В среде разработки Web Matrix отсутствует панель Solution Explorer, из чего можно сделать предположение (совершенно справедливое), что весь проект состоит из одного ASPX-файла — в нем нет многочисленных дополнительных компонентов, которые мы видели в VS.NET. Нет здесь и отдельного VB-модуля с программным кодом.

Чтобы убедиться в этом, откроем вкладку All основного окна проекта и посмотрим полное содержание файла NewFile.aspx:

Иными словами, ASPX-файл состоит из двух частей — исполняемого (в данном случае VB) кода и HTML-кода (нет двух отдельных файлов, как это сделано в VS.NET). Для удобства работы с ними мы можем использовать вкладки HTML и Code окна проекта. Что интересно — мы можем загрузить в Web Matrix проект, созданный ранее в VS.NET, и запускать его на выполнение. Но редактирование VB-модуля при этом недоступно.

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

ASP .NET — что нас ждет впереди

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

Для более детального изучения этих вопросов можно рекомендовать англоязычные ресурсы на серверах http://msdn.microsoft.com и http://www.asp.net, в частности, статьи Cache and Carry with ASP .NET (вопросы кэширования для повышения производительности) и Migrating to ASP .NET. Key Considirations (переход от ASP к ASP .NET).

А закончить статью хочу таким размышлением. Многие профессиональные Web-разработчики пока весьма прохладно относятся к технологии ASP, считая ее излишне упрощенной и не очень эффективной (однако обратите внимание — для тиражируемых решений ее применяют довольно часто!). ASP .NET выглядит гораздо более привлекательно благодаря улучшенной функциональности и упрощению самой процедуры разработки. Но самое главное даже не в этом. Обратите внимание, что развитие технологии идет в типичном для Microsoft стиле: корпорация не пытается догонять конкурентов в вопросах, где позиции последних уже очень сильны (например, в Web-дизайне). Microsoft делает акцент на новшества, связанные с ее традиционными преимуществами. Причем реализуется это в виде в целом привлекательных решений, которые при этом не очень соответствуют общепринятым стандартам.

О разделении исполняемого кода и HTML уже говорилось выше. (код можно писать на многих языках программирования, например, Perl, но при условии, что они адаптированы для .NET). Другим принципиальным новшеством технологии ASP .NET стал новый тип компонентов — управляющие элементы Web. Очень важно, что их могут создавать независимые разработчики (причем даже не очень квалифицированные). Тут можно вспомнить, что одной из главных причин успеха VB в начале 90-х годов было создание огромного рынка дополнительных элементов VBX/OCX, которые существенно расширяли возможности самого VB.

Похоже, Microsoft не собирается изменять своим надежным, проверенным методам борьбы за рынок. Кстати, создаваемые с помощью VS.NET новые Web-элементы будут работать только в среде .NET Framework.

Что же такое Microsoft .NET?

Однозначного ответа на этот вопрос просто нет: очень многое зависит от того, для чего и кому мы его задаем. Ответы представителей Microsoft, Sun, «1С» или ИТ-подразделения ЦБ РФ будут мало похожи один на другой. Тут правомерна аналогия с понятием «разработка приложений»: программист, менеджер проекта и руководитель компании, говоря об этом, будут иметь в виду различный круг решаемых задач.

За последний год в связи с темой .NET мне пришлось посетить много презентаций, услышать кулуарных бесед, прочитать немало статей и целый ряд книг. И мне было очень приятно, когда я наконец-то нашел своего полного единомышленника в том, что касается восприятия стратегии Microsoft. Это известный американский разработчик и публицист Дан Эпплман, чья книга «Переход на VB.NET: стратегии, концепции, код» в начале года вышла в переводе на русский в издательстве «Питер».

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

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

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

«В один прекрасный день выяснилось, что Microsoft начинает отставать от Netscape, Sun и других компаний, занимающихся Интернет-технологиями. Немедленно под фанфары появилась новая технология ActiveX. Что такое ActiveX? Это OLE2 с новым названием».

Поясню: на протяжении более 10 лет деятельность Дана Эпплмана связана с применением технологий Microsoft, он является признанным авторитетом в американском сообществе разработчиков. При этом он подчеркивает: «Противники Microsoft клеймят меня как «продажного наймита», а ее сторонники — осуждают за «злобные нападки». А вот высказывание Эпплмана как раз по поводу обозначенного выше вопроса о сути .NET: «.NET захлестнул тот же поток маркетинговых статей, недостоверных и обрывочных сведений, вольных интерпретаций и неразберихи, от которой пострадали многие инициативы Microsoft. Не думаю, что вы получите сколько-нибудь вразумительный ответ от сотрудников Microsoft — их ответы слишком сильно зависят от должности и от того, какую презентацию PowerPoint им показали последней».

Это было написано год назад. Сейчас, спустя полгода после официального выпуска .NET Framework и Visual Studio .NET, ажиотаж по этому поводу явно пошел на убыль. Это естественно: наступило время проверкой делом маркетинговых заявлений «предстартовой» поры. Но неразбериха в ответе на вопрос «Что такое .NET?» сохраняется и даже усиливается.

Сбывается прогноз двухлетней давности — все новые продукты и технологии Microsoft автоматически получают суффикс .NET независимо от сути используемых в них архитектурных решений. Более того, на одной из презентаций прошедшей весной я видел замечательный слайд, на котором к семейству .NET Server были приписаны задним числом все версии Windows 2000.

Возвращаясь к вопросу, вынесенному в заголовок этого раздела, я даю на него ранее уже озвученный ответ: Microsoft .NET с точки зрения программиста — это новая среда исполнения программного кода, (виртуальная машина) под названием .NET Framework. И, говоря о создании Web-приложений, нужно отметить самое главное новшество: в .NET достигнут значительный прогресс в том, чтобы стереть различия между традиционным программированием под Windows и Интернет-разработкой. Но при этом Microsoft, как обычно, идет своим путем.

Другие статьи из раздела

  • Программная платформа IBM для повышения эффективности бизнеса
  • ИБП для защиты серверов
  • Интегрированное решение для защиты центров обработки данных
  • На пути к построению единой платформы защиты данных
  • Виртуализация без ограничений

Поместить в блог

Комментарии к статье

Рекламные ссылки

Chloride
Демонстрация Chloride Trinergy
Впервые в России компания Chloride Rus провела демонстрацию системы бесперебойного электропитания Chloride Trinergy®, а также ИБП Chloride 80-NET™, NXC и NX для своих партнеров и заказчиков.

NEC Нева Коммуникационные Системы
Завершена реорганизация двух дочерних предприятий NEC Corporation в России
С 1 декабря 2010 года Генеральным директором ЗАО «NEC Нева Коммуникационные Системы» назначен Раймонд Армес, занимавший ранее пост Президента Shyam …

компания «Гротек»
С 17 по 19 ноября 2010 в Москве, в КВЦ «Сокольники», состоялась VII Международная выставка InfoSecurity Russia. StorageExpo. Documation’2010.
Новейшие решения защиты информации, хранения данных и документооборота и защиты персональных данных представили 104 организации. 4 019 руководителей …

МФУ Panasonic DP-MB545RU с возможностью печати в формате А3
Хотите повысить эффективность работы в офисе? Вам поможет новое МФУ #Panasonic DP-MB545RU. Устройство осуществляет

Adaptec by PMC
RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэша
Опытные сетевые администраторы знают, что задействование в работе кэш-памяти RAID-контроллера дает серьезные преимущества в производительности …

Chloride
Трехфазный ИБП Chloride от 200 до 1200 кВт: Trinergy
Trinergy — новое решение на рынке ИБП, впервые с динамическим режимом работы, масштабируемостью до 9.6 МВт и КПД до 99%. Уникальное сочетание …

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