Извините, ничего не найдено.

Не расстраивайся! Лучше выпей чайку!
Регистрация
Справка
Календарь

Вернуться   forum.boolean.name > Веб-программирование > Общее

Общее Веб-разработка в целом, идеи, проекты...

Ответ
 
Опции темы
Старый 24.02.2010, 22:57   #1
pax
Unity/C# кодер
 
Аватар для pax
 
Регистрация: 03.10.2005
Адрес: Россия, Рязань
Сообщений: 7,568
Написано 3,006 полезных сообщений
(для 5,323 пользователей)
Семь важных фактов об ASP.NET

Из книжки отсканил когда-то, вдруг кому интересно почитать ))


Первый факт: ASP.NET интегрируется с .NET Framework


Среда .NET Framework состоит из очень тщательно отобранных функциональных частей, общее количество которых насчитывает более 10 ООО типов (типами в .NET называются классы, структуры, интерфейсы и другие ключевые элементы программирования).
Способ, которым упорядочена предлагаемая.NET Framework обширная коллекция функциональных возможностей, программистам традиционных Windows-приложений, несомненно, понравится. Каждый из тысяч доступных в .NET Framework классов размещается в логическом иерархическом контейнере, который называется пространством имен (namespace). Разные пространства имен предоставляют разные функциональные возможности, а все вместе они предоставляют функциональные возможности для практически каждой области распределенной разработки, начиная от организации очередей сообщений и заканчивая обеспечением безопасности. Весь целиком этот обширный набор инструментов называется библиотекой классов (class library).
Интересно то, что способ, которым классы .NET Framework используются в ASP.NET, ничем не отличается от способа, которым они применяются в любых других приложениях .NET (вроде автономных Windows-приложений, Windows-служб, утилит командной строки и т.д.). Другими словами, .NET предоставляет разработчикам Web-приложений те же самые инструменты, что и разработчикам многофункциональных клиентских приложений.



Второй факт: код ASP.NET компилируется, а не интерпретируется


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

Приложения ASP.NET всегда компилируются: на самом деле выполнить код С# или Visual Basic, предварительно не скомпилировав его, просто не возможно.
Приложения ASP.NET в действительности проходят два этапа компиляции. На первом этапе написанный вами код С# компилируется в код на промежуточном языке под названием Microsoft Intermediate Language (MSIL), или просто IL. Этот первый шаг является фундаментальной причиной взаимозависимости .NET от языков. По сути, все языки .NET (включая С#, Visual Basic и многие другие) компилируются в фактически идентичный код IL. Этот первый этап компиляции может произойти автоматически при первом запросе страницы, или же его можно выполнить заранее (этот процесс известен как предварительная компиляция). Скомпилированный файл с кодом IL является сборкой.
Второй этап компиляции наступает непосредственно перед фактическим выполнением страницы. На этом этапе код IL компилируется в низкоуровневый собственный машинный код. Этот этап известен как оперативная компиляция "точно к нужному моменту" (Just-In-Time — JIT) и он проходит одинаково для всех приложений .NET (включая, например, приложения Windows). На рис. 1.1 показан этот двухэтапный процесс компиляции.
Компиляция .NET делится на два этапа с целью предоставления разработчикам удобных условий и мобильности. Перед созданием низкоуровневого машинного кода компилятору необходимо знать, в какой операционной системе и на каком базовом оборудовании будет функционировать приложение (например, 32- или 64-разрядная ОС Windows). Благодаря двум этапам компиляции, можно создать скомпилированную сборку с кодом .NET и распределить ее на более чем одну платформу.
Разумеется, GIT-компиляция не была бы такой полезной, если бы ее нужно было выполнять при каждом запросе пользователем какой-нибудь страницы с Web-сайта. К счастью, приложения ASP.NET не требуют, чтобы компиляция выполнялась при каждом запросе Web-страницы. Вместо этого код IL в них создается один раз и генерируется заново только в случае изменения исходного кода, а файлы собственного машинного кода каптируются в системном каталоге, путь к которому выглядит примерно так:
с:WindowsMicrosoft.NETFrameworkv2.0.50727Temporary ASP.NET Files
На заметку! Читателям наверняка интересно узнать, почему это временные файлы ASP.NET размещаются в каталоге с номером версии 2.0, а не 3.5? А все дело в том, что с технической точки зрения ASP.NET 3.5 использует механизм ASP.NET 2.0 (с несколькими добавившимися новыми функциональными возможностями).

В состав ASP.NET также входят инструменты предварительной компиляции, с помощью которых можно делать так, чтобы приложение компилировалось сразу же в машинный код прямо после его развертывания на производственном Web-сервере, что позволяет избегать накладных расходов, связанных с первым этапом компиляции, при развертывании законченного приложения (и исключает вероятность подделывания или изменения кода другими людьми).
На заметку! Несмотря на частую противоречивость тестов производительности, на странице http://msdn2.microsoft.com/en-us/vstudio/aa700836.aspx можно найти несколько интересных сравнений Java и ASP.NET. Следует иметь в виду, что настоящие проблемы, влияющие на производительность, обычно связаны с конкретными критическими параметрами наподобие параметров доступа к диску, параметров использования ЦП, параметров пропускной способности сети и т.д. Во многих тестах производительности ASP.NET превосходит другие решения по показателям производительности только благодаря поддержке платформенных механизмов улучшения производительности, вроде механизма кэширования, а не благодаря повышенной скорости работы из-за использования скомпилированного кода.



Третий факт: ASP.NET поддерживает несколько языков


Выбор для разработки приложения того или иного языка никак не влияет на то, что с ним можно будет делать. А все потому, что какой бы язык не использовался, код все равно компилируется в IL.
IL является "трамплином" для любого управляемого приложения. (Управляемым (managed) приложением называется любое приложение, написанное для .NET и выполняющееся внутри управляемой среды CLR.) В некотором смысле IL даже можно назвать языком .NET, потому что это единственный язык, который распознает среда CLR...


Четвертый факт: ASP.NET обслуживается CLR


Пожалуй, наиболее важным аспектом механизма ASP.NET является то, что он функционирует внутри исполняющей среды CLR. Вся среда .NET Framework — т.е. все пространства имен, приложения и классы — называется управляемым кодом. Несмотря на то что полное описание CLR выходит за рамки этой главы, рассмотрим основные преимущества CLR.
• Автоматическое управление памятью и сборка мусора. Каждый раз, когда приложение создает экземпляр объекта ссылочного типа (reference-type object), CLR выделяет для него пространство памяти в управляемой куче. Однако вам никогда не придется очищать эту память вручную. Как только ссылка на объект выходит за пределы области видимости (или приложение завершается), объект становится доступным для сборщика мусора. Сборщик мусора периодически запускается внутри CLR, автоматически восстанавливая неиспользованную память для недоступных объектов. Эта модель избавляет от низкоуровневых деталей манипулирования памятью С++ и от запутанности подсчета ссылок СОМ.
• Безопасность типов. При компиляции приложения .NET добавляет в сборку сведения о доступных классах, их членах, типах данных и т.д. Это позволяет другим приложениям использовать их, не требуя дополнительных вспомогательных файлов, а компилятору — удостоверяться в правильности запроса прямо во время выполнения. Такой дополнительный уровень безопасности полностью исключает вероятность возникновения всех видов низкоуровневых ошибок.
• Расширяемые метаданные. Информация о классах и членах является только одним из типов метаданных, которые .NET может хранить в скомпилированной сборке. Метаданные описывают код и позволяют предоставлять дополнительную информацию исполняющей среде и другим службам. Например, эти метаданные могут указывать отладчику, как следует выполнять трассировку кода, или же сообщать Visual Studio о том, как во время проектирования должен отображаться какой-нибудь специальный элемент управления. Они также могут использоваться и для активизации еще каких-нибудь служб во время выполнения, например, для активизации транзакций или пула объектов.
• Структурированная обработка ошибок. Языки .NET поддерживают структурированную обработку исключений, что позволяет организовывать код обработки ошибок логичным и последовательным образом, т.е. создавать для разных типов ошибок отдельные блоки, а также размещать обработчики исключений на глубине в целых несколько уровней.
• Многопоточностъ. CLR предоставляет пул потоков, которые могут использоваться различными классами. Например, можно асинхронно вызывать методы, читать файлы либо взаимодействовать с Web-службами без необходимости явного создания новых потоков.



Пятый факт: ASP.NET является объектно-ориентированной технологией


В ASP объектная модель выглядит довольно слабо, поскольку предлагает очень небольшой набор объектов, которые ну уж очень тонким слоем скрывают детали HTTP и HTML. ASP.NET, напротив, является самой настоящей объектно-ориентированной технологией. Она не только предоставляет полный доступ ко всем объектам в .NET Framework, но и позволяет использовать все концепции объектно-ориентированного программирования (ООП). Например, она позволяет создавать повторно используемые классы, стандартизовать код с помощью интерфейсов, расширять существующие классы посредством наследования и объединять полезные функциональные возможности в пригодный для распространения скомпилированной компонент.
Одним из наилучших примеров поддержки объектно-ориентированного поведения в ASP.NET являются серверные элементы управления. Эти элементы управления представляют собой инкапсуляцию в миниатюре. Разработчики могут манипулировать их объектами программно, используя код для настройки их внешнего вида, предоставления подлежащих отображению данных и даже реагирования на события. Вся низкоуровневая HTML-разметка, которую визуализируют эти элементы управления, скрывается "за кулисами". Вместо того чтобы вынуждать разработчика писать низкоуровневый код HTML-разметки вручную, объекты этих элементов управления сами преобразовываются в соответствующие HTML-элементы по завершении визуализации страницы. Таким образом, ASP.NET позволяет с помощью серверных элементов абстрагироваться от низкоуровневых деталей HMTL- и HTTP-программирования.

Элементы управления HTML и Web
На момент создания ASP.NET существовало два типа мышления. Некоторые разработчики ASP.NET были заинтересованы в серверных элементах управления, в точности соответствовавших существующему набору элементов управления HTML. Этот подход позволяет создавать интерфейсы Web-страниц ASP.NET в HTML-редакторах, и предоставляет путь быстрой миграции для существующих страниц ASP. Однако еще одна группа разработчиков ASP.NET видела нечто большее — крупные серверные элементы управления, не просто имитировавшие отдельные HTML-дескрипторы. Эти элементы управления могут визуализировать свой интерфейс с помощью десятков элементов HTML, в то же время предлагая программистам простой объектный интерфейс. Используя эту модель, разработчики могли работать с программируемыми меню, календарями, списками данных, средствами проверки данных и т.д.
После некоторых размышлений в Microsoft решили предоставить обе модели. Вы уже видели пример серверных элементов управления HTML, отображаемых непосредственно на базовый набор HTML-дескрипторов. К ним прилагаются элементы управления Web ASP.NET, предлагающие более высокий уровень абстракции и большую функциональность. В большинстве случаев серверные элементы управления HTML используются для обратной совместимости и быстрой миграции, применяя элементы управления Web для новых проектов.

Набор элементов управления Web в ASP.NET содержит сложные генерируемые элементы управления (подобные Calendar и TreeView), а также усовершенствованные элементы управления (такие как TextBox, Label и Button), отображаемые на существующие HTML-дескрипторы. В последнем случае варианты серверного элемента управления HTML и элемента управления Web ASP.NET обеспечивают похожую функциональность, однако элементы управления Web склонны к отображению более стандартизованного, улучшенного интерфейса. Это упрощает изучение элементов управления Web и делает их подходящими для Windows-разработчиков, ориентированных на Web, поскольку большинство имен свойств похожи на имена соответствующих элементов управления Windows.

При добавлении атрибута runat="server" эта статическая часть HTML становится полностью функциональным серверным элементом управления, которым можно манипулировать в коде. Теперь вы можете работать с генерируемыми им событиями, устанавливать атрибуты и связывать его с источником данных.



Шестой факт: ASP.NET поддерживает множество устройств и браузеров


Одним из самых сложных испытаний, предстоящих Web-разработчикам, является большое количество браузеров, которые необходимо поддерживать. Различные браузеры, версии и конфигурации по-разному поддерживают HTML. Web-разработчики должны выбирать, следует ли формировать содержимое в соответствие со стандартом HTML 3.2, HTML 4.0 или же с чем-либо другим вроде XHTML 1.0 или даже WML (Wireless Markup Language — язык разметки для беспроводных систем) для мобильных устройств. Эта проблема, усугубляемая различными компаниями, выпускающими браузеры, преследовала разработчиков с тех пор, как консорциум World Wide Web Consortium (W3C) предложил первую версию HTML. Жизнь еще более усложнялась при использовании расширений HTML, таких как JavaScript, для создания более динамичных страниц или верификации.
ASP.NET решил эту проблему удивительно разумным способом. Несмотря на то что вы можете извлекать информацию о браузере клиента и его свойствах внутри страницы ASP.NET, ASP.NET фактически побуждает разработчиков игнорировать эти соображения и использовать обширный набор элементов управления Web-сервера. Эти серверные элементы управления генерируют HTML, адаптируясь к возможностям клиента. Одним из примеров являются элементы управления верификацией ASP.NET, использующие JavaScript и DHTML (динамический HTML) для совершенствования своего поведения, если оно поддерживается клиентом. Это позволяет элементам управления верификацией отображать сообщения о динамических ошибках без необходимости отправки пользователем страницы серверу для продолжения обработки. Эти свойства необязательны, но они демонстрируют то, как интеллектуальные элементы управления могут составлять большую часть современных браузеров, не требуя других клиентов. Но самое лучше заключается в том, что вам не нужны дополнительные работы по кодированию для поддержания обоих типов клиента.



Седьмой факт: ASP.NET легко развертывается и конфигурируется


Одним из самых сложных вопросов, с которыми разработчику доводиться сталкиваться во время процесса разработки, является развертывание готового приложения на производственном сервере, требующее не только перемещения файлов Web-страниц, баз данных и компонентов, но и выполнения регистрации этих компонентов, а также воссоздания ряда конфигурационных параметров. ASP.NET значительно упрощает весь этот процесс.
Каждая установка .NET Framework предоставляет одни и те же базовые классы. Поэтому процедура развертывания приложения ASP.NET выглядит относительно просто и, в общем, подразумевает всего лишь копирование всех файлов в виртуальный каталог на производственном сервере (с помощью программы FTP или даже утилиты командной строки вроде XCOPY). Если на машине-хосте установлен компонент .NET Framework, выполнять какие-либо трудоемкие шаги по регистрации не потребуется. Более подробно о процессе развертывания будет рассказываться в главе 18.
Процедура распространения компонентов, используемых приложением, выглядит столь же просто и предполагает всего лишь копирование сборок компонентов вместе с файлами Web-сайта на этапе развертывания Web-приложения. Поскольку вся информация о компоненте хранится прямо в метаданных файла сборки, запускать программу регистрации или вносить изменения с системный реестр Windows не требуется. При условии размещения компонентов в "правильном месте" (каковым является подкаталог Bin внутри основного каталога Web-приложения), механизм ASP.NET автоматически обнаруживает их и делает доступными для кода Web-страницы. Попробуйте-ка сделать подобное с традиционным компонентом СОМ!
Конфигурирование является еще одной задачей, связанной с развертыванием приложения, в особенности при необходимости передачи информации о безопасности, такой как учетная запись и привилегии пользователя. ASP.NET упрощает процесс развертывания, сводя к минимуму зависимость от настроек IIS (Internet Information Services — информационные службы Internet). Вместо этого большинство установок ASP.NET хранится в специальном файле web. conf ig. Файл web. conf ig помещается в тот же каталог, что и Web-страницы. Он содержит иерархически сгруппированные настройки приложения, хранимые в удобочитаемом формате XML, который можно редактировать с использованием простого текстового редактора, подобного Notepad. При изменении настройки приложения ASP. NET" замечает это изменение и перезапускает приложение в новом домене приложения (поддерживая существующий домен приложения вплоть для завершения обработки каких-то невыполненных запросов). Файл web. conf ig никогда не блокируется, поэтому его можно обновлять в любое время.
__________________
Blitz3d to Unity Wiki
(Offline)
 
Ответить с цитированием
Сообщение было полезно следующим пользователям:
Жека (25.02.2010)
Ответ


Опции темы

Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


Часовой пояс GMT +4, время: 13:00.


vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot
Style crйe par Allan - vBulletin-Ressources.com