ВыходВопрос 8. Основные принципы ASP.NET
| Добавил: | DMT |
| Дата создания: | 30 декабря 2007, 19:17 |
| Дата обновления: | 30 декабря 2007, 19:17 |
| Просмотров: | 11145 последний сегодня, 10:52 |
| Комментариев: | 1 |
| Вопрос 8. Основные принципы ASP.NET | |
Комментарии для "Вопрос 8. Основные принципы ASP.NET"
|
Пользователь: doriangray_rus Сообщений: 13 Статус: Незримый Зарегистрирован: 6 января 2008, 18:12 Был:21 января 2008, 0:29  
| Дата: 9 января 2008, 0:59 Сообщение № 1 |
|
Я точно знаю это они!!!Я Петровой сам здавал!!! Среда .NET Framework содержит тщательно отобранную коллекцию функцио¬нальных - частей с поразительным общим количеством — более 7000 типов (тер¬мин .NET для классов, структур, интерфейсов и других основных составных ча¬стей программирования). Перед программированием любого типа приложения .NET необходимо базовое понимание этих частей и того, почему они организованы именно таким образом. Обширная коллекция функций, предлагаемая .NET Framework, организована таким способом, который традиционные программисты для Windows посчитают значительным улучшением. Каждый из тысяч классов в .NET Framework сгруппи¬рован в логический иерархический контейнер под названием пространство имен. Различные пространства имен предоставляют различные свойства. В совокупно¬сти пространства имен .NET предлагают функции почти для каждого аспекта рас¬пределённой разработки — от организации очередей сообщений до, безопасности. Такой обширный набор инструментов называется библиотекой классов. Интересно отметить, что способ использования классов в .NET Framework в ASP.NET ничем не отличается от способа их применения в любом другом типе при¬ложения .NET (включая автономное Windows-приложение, Windows-службу, ути¬литу командной строки и тому подобное). Иначе говоря, .NET предоставляет Web-разработчикам те же инструменты, что и разработчикам клиента. Если вы будете интенсивно программировать с помощью ASP.NET 1.x, то обна¬ружите, что такой же набор классов доступен в ASP.NET 2.0, Отличие заключается в том, что ASRNET 2.0 поддерживает еще больше классов, многие из которых до¬бавляются в совершенно новые пространства имен наподобие конфигурации, мо¬ниторинга рабочего состояния оборудования, а также персонализации. Одна из основных причин снижения производительности в ASP-сценариях связана с тем, что во всем коде Web-страницы ASP используются интерпретируе¬мые языки написания сценариев. Это означает, что при выполнении приложений хосту сценариев на серверной машине необходимо интерпретировать ваш код и построчно преобразовать его в низкоуровневый машинный код. Этот процесс пе¬чально известен своей низкой скоростью. Приложения ASP.NET всегда компилируются — фактически невозможно выпол¬нить код С# или VB.NET без его предварительной компиляции. Приложения ASP.NET в действительности проходят два этапа компиляции. На первом этапе написанный вами код С# компилируется в код промежуточного языка под названием Microsoft Intermediate Language (MSIL), или просто IL. Этот первый шаг является фундаментальной причиной взаимозависимости .NET от языков. По сути, все языки .NET (включая С#, Visual Basic и многие другие) компилируются в фактически идентичный код IL. Этот первый этап компиляции может произойти автоматически при первом запросе страницы, или же его можно выполнить зара¬нее (этот процесс известен как предварительная компиляция). Скомпилированный файл с кодом IL является сборкой. Второй этап компиляции наступает непосредственно перед фактическим вы¬полнением страницы. На этом этапе код IL компилируется в низкоуровневый соб¬ственный машинный код. Этот этап известен как оперативная компиляция "точно к нужному моменту" (Just-In-Time — JIT) и он проходит одинаково для всех прило¬жений .NET (включая, например, приложения Windows). На рис. 1 показан этот двухэтапный процесс компиляции. Компиляция .NET делится на два этапа с целью предоставления разработчикам удобных условий и мобильности. Перед созданием низкоуровневого машинного кода компилятору необходимо знать, в какой операционной системе и на каком базовом оборудовании будет функционировать приложение (например. 32- или 64-рааряднаа ОС Windows). Благодаря двум этапам компиляции, можно создать скомпилированную сборку с кодом .NET и распределить ее на более чем одну плат¬форму.  Рис. 1. Конечно, компиляция JIT не будет такой полезной, если ее выполнение будет необходимо каждый раз при запросе пользователем Web-страницы с вашего сайта. К счастью, приложения ASP.NET не нужно компилировать всякий раз при запросе Web-страницы или Web-службы. Вместо этого код IL создается один раз и повтор¬но генерируется только при изменении исходного кода. Подобным образом файлы собственного машинного кода кэшируются в системном каталоге с путем вроде c:\[WinDir]\Microsoft.NET\Framework\[Version]\Temporary ASP.NET Files, где [WinDir] является каталогом Windows, a [Version] — номером установлен¬ной в данный момент версии .NET. Хотя модель компиляции в ASP.NET 2.0 по существу остается такой же, она содержит одно важное изменение. Инструмент проектирования (Visual Studio) больше не компилирует код. Вместо этого ваши Web-страницы и службы компи¬лируются при первом запуске, что улучшает процесс отладки. Во избежание не¬производительных издержек первой компиляции при развертывании закончен¬ного приложения (и с целью предотвращения вмешательства посторонних лиц в ваш код) можно использовать новое средство предварительной компиляции. Несмотря на то, что при разработке приложений вы наверняка отдадите пред¬почтение какому-то одному языку перед другими, этот выбор не определит то, чего вы сможете достигнуть с помощью своих Web-приложений, поскольку какой бы язык вы не использовали, код компилируется в IL. IL является конечной целью каждого управляемого приложения. [Управляемым (managed) приложением называется любое приложение, написанное для .NET и выполняющееся внутри управляемой среды CLR). В известном смысле IL является языком .NET и единственным языком, распознаваемым CLR. Для понимания CLR рассмотрим следующий пример — функцию, написанную на языке С#: namespace HelloWorld { public class TestClass { private static void Main(string[] args) { Console.WriteLine("Hello World"); } } } Этот код демонстрирует наиболее базовое приложение, доступное в .NET — про¬стую утилиту командной строки, отображающую сообщение в окне консоли. Теперь рассмотрим код под другим углом. Ниже представлен код IL того же класса: .method public static void Main() cil managed { .entrypoint .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() =( 01 00 00 00 ) // Code size 14 (Oxe) .maxstack 8 IL_0000: nop lL_0001: Idstr "Hello World" IL_0006: call void [mscorlib]System.Console::WriteLine(string) IL_000b: nop lL_000c: nop IL_000d: ret ) // end of method Module :: Main Просмотреть код IL для любого скомпилированного приложения .NET очень лег¬ко. Необходимо лишь запустить программу дизассемблера (IL Disassembler), уста¬навливаемую вместе с Visual Studio и .NET SDK (Software Development Kit — на¬бор инструментальных средств разработки программного обеспечения). Найдите исполняемый файл ildasm.exe в каталоге вроде C: Program Files\Visual Studio2005\SDК\v2.0\Bin. После загрузки дизассемблера выберите в меню File (Файл) команду Open (Открыть) и затем любой DLL- или ЕХЕ-файл, созданный с помощью .NET. Если вы будете терпеливы и логичны, то сможете довольно легко разобраться с кодом IL и выяснить, что он делает. Простота дизассемблирования кода IL мо¬жет вызвать проблемы приватности и управления кодом, однако эти проблемы не являются препятствием для разработчиков ASP.NET, поскольку весь код ASP.NET хранится и выполняется на сервере. Поскольку клиент никогда не получает ском¬пилированный файл кода, у клиента нет возможности его дизассемблирования. Если это является проблемой, воспользуйтесь "затемнителем" для усложнения кода. (Например, "затемнитель" может переименовать все переменные в групповые неосмысленные имена наподобие f_а_234). Visual Studio содержит упрощенную версию популярного “затемнителя” под названием Dotfuscator. Ниже показано то же консольное приложение на Visual Basic: Namespace HelloWorld Public Class TestClass Private Shared Sub Main(Ars() As String) Console.WrlteLine("Hello World") End Sub End Class End Namespace Если скомпилировать это приложение и просмотреть код IL- то можно обнару¬жить, что каждая его строка идентична коду IL, который был сгенерирован версией С# утилиты. Хотя разные компиляторы могут иногда предлагать. свои собственные оптимизации, по общему правилу ни один язык .NET не превосходит какой-либо другой язык .NET, поскольку все эти языки обладают общей инфраструктурой. Эта инфраструктура формализована в CLS (Common Language Specification — Общая спецификация языка). Важно отметить, что IL недавно был принят как стандарт ANSI (American National Standards Institute — Национальный институт стандартизации США), Это может значительно ускорить принятие других структур общих языков. Проект Mono (http: //www. go-mono, com) является примером одного из таких проектов. Факт 4: ASP.NET функционирует внутри исполняющей среды CLR Возможно, наиболее важным аспектом ASP.NET, который следует запомнить, является его функционирование внутри исполняющей среды CLR. Вся среда .NET Framework — то есть все пространства имен, приложения и классы — называется управляемым кодом. Несмотря на то что полное описание CLR выходит за рамки этой главы, рассмотрим основные преимущества CLR: • Автоматическое управление памятью и сборка мусора. Каждый раз когда ваше приложение создает экземпляр объекта, CLR выделяет для Него про¬странство памяти в управляемой куче. Однако вам никогда не придется очи¬щать эту память вручную. Как только ссылка на объект выходит за пределы области видимости (или приложение завершается), объект становится до¬ступным для сборщика мусора. Сборщик мусора периодически запускается внутри CLR, автоматически восстанавливая неиспользованную память для недоступных объектов. Эта модель избавляет от низкоуровневых деталей ма¬нипулирования памятью C++ и от запутанности подсчета ссылок СОМ. • Безопасность типов. При компиляции приложения .NET добавляет к сборке информацию о доступных классах, их членах, типах данных и тому подоб¬ном. Это приводит к полной самостоятельности скомпилированных сборок кода. Другие разработчики могут использовать их без запроса каких-либо других файлов поддержки, и компилятор может проверять допустимость каждого обращения во время выполнения. Этот дополнительный уровень безопасности полностью избавляет от возникновений низкоуровневых оши¬бок наподобие печально известного переполнения буфера, • Расширяемые метаданные. Информация о классах и элементах является лишь одним из типов метаданных, хранимых .NET в скомпилированной сборке. Метаданные описывают ваш код и позволяют предоставлять дополни¬тельную информацию исполняющей среде или другим службам. Например, эти метаданные могут сообщить отладчику о том, как трассировать ваш вод, или же сообщить Visual Studio о том, как отображать специальный элемент управления во время проектирования, Метаданные также можно использо¬вать для активизаций других служб времени выполнения (например, Web -методов или служб СОМ+), • Структурированная обработка ошибок. Вели вы когда-либо, писали мало-мальски полезный код на Visual Basic или VBScript, то наверняка знакомы е ограниченными ресурсами, предлагаемыми этими языками для обработки ошибок. С помощью структурированной обработки исключений вы сможете логически и лаконично организовать свой код обработки ошибок. Вы сможе¬те создавать отдельные блоки для работы с различными; типами ошибок. Вы также сможете встраивать обработчики исключений на глубину в несколько уровней. • Многопоточность. CLR предоставляет пул потоков, которые могут использо¬ваться различными классами. Например, можно асинхронно вызывать мето¬ды, читать файлы либо взаимодействовать с Web-службами без необходимо¬сти явного создания новых потоков. ASP поддерживает относительно слабую объектную модель с достаточно скуд¬ным набором объектов; эти объекты в действительности представляют собой лишь тонкий уровень, скрывающий подробности HTTP и HTML. Напротив, ASP.NET яв¬ляется объектно-ориентированной средой. Ваш код не только имеет полный до¬ступ ко всем объектам в .NET Framework, вы также можете эксплуатировать все условные обозначения объектно-ориентированного программирования (ООП). Например, вы можете создавать повторно используемые классы, стандартизовать код в соответствии с интерфейсами и объединять полезные функции в распреде¬ляемом скомпилированном компоненте. Один из лучших примеров объектно-ориентированного мышления в ASP.NET можно найти в серверных элементах управления. Серверные элементы управления представляют собой инкапсуляцию в миниатюре. Разработчики могут программно манипулировать объектами управления с использованием кода для настройки их внешнего вида, предоставления данных для отображения и даже реакции на собы¬тия. Низкоуровневые подробности HTML спрятаны "за сценой". Вместо того что¬бы вынуждать разработчика писать "сырой" HTML вручную, объекты управления преобразуются в HTML по завершении визуализации страницы. Таким образом, ASP.NET предлагает серверные элементы управления в качестве способа устране¬ния низкоуровневых подробностей программирования на HTML и HTTP. Ниже приведен небольшой пример со стандартным текстовым полем HTML: <input type="text" id="myText" runat="server" /> При добавлении атрибута runat="server" эта статическая часть HTML ста¬новится полностью функциональным серверным элементом управления, которым можно манипулировать в коде. Теперь вы можете работать с генерируемыми им событиями, устанавливать атрибуты и связывать его с источником данных. Например, вы можете установить текст этого окна при первой загрузке страни¬цы с использованием следующего кода: void Page_Load(object sender, EventArgs e) { myText.Value = "Hello World!"; } Технически этот код устанавливает свойство Value объекта Html Input Text. Конечным результатом является появление строки текста в текстовом поле на HTML-странице, которая генерируется и отправляется клиенту. На момент создания ASP.NET существовало два типа мышления. Некоторые разработчики ASP.NET были заинтересованы в серверных элементах управления, в точности соответство¬вавших существующему набору элементов управления HTML, Этот подход позволяет созда¬вать интерфейсы Web-страниц ASP.NET в HTML-редакторах, и предоставляет путь быстрой миграции для существующих страниц ASP. Однако еще одна группа разработчиков ASP.NET видела нечто большее — крупные серверные элементы управления, не просто имитировав¬шие отдельные HTML-дескрипторы. Эти элементы управления могут визуализировать свой интерфейс с помощью десятков элементов HTML, в тоже время, предлагая программистам простой объектный интерфейс. С использованием этой модели разработчики могли рабо¬тать с программируемыми меню, календарями, списками данных и модулями проверки до¬стоверности. После некоторых размышлений в Microsoft решили предоставить обе модели. Вы уже ви¬дели пример серверных элементов управления HTML, отображаемых непосредственно на базовый набор НТМL-дескрипторов. К ним прилагаются элементы управления Web ASP.NET, предлагающие более высокий уровень абстракции и большую функциональность. В боль-шинстве случаев серверные элементы управления HTML используются для обратной совме-стимости и быстрой миграции, применяя элементы управления Web для новых проектов. Дескрипторы элементов управления Web в ASP.NET всегда начинаются с префикса asp:, сопровождаемого именем класса. Например, следующий фрагмент создает текстовое поле и флажок; <asp:TextBox id="myASPText" Text="Hello ASP.NET TextBox" runat="server" /:> <asp::CheekBox id="myASPCheck" Text="My CheckBox" runat="server" /> Опять-таки, вы можете взаимодействовать с этими элементами управления в своем коде следующим образом: myASPText.Text = "New text"; myASPCheck.. Text = "Cheek me!"; Обратите внимание, что свойство Value, которое вы видели в элементе управления HTML, замещено свойством Text. Свойство HtmllnputText.Value было именовано для со-ответствия базовому атрибуту значения в HTML-дескрипторе <input>. Однако элементы управления Web не придают такое же значение соотношению с синтаксисом HTML, поэтому вместо в них используется более наглядное имя свойства Text. Набор элементов управления Web в ASP.NET содержит сложные генерируемые элементы управления (подобные Calendar и Tree View), а также усовершенствованные элемент ты управления (такие как TextBox, Label и Button), отображаемые на существующие HTML-дескрипторы, В последнем случае варианты серверного элемента управления HTML и элемента управления Web ASP.NET обеспечивают похожую функциональность, однако элементы управления Web склонны к отображению более стандартизованного, улучшенно¬го интерфейса. Это упрощает изучение элементов управления Web и делает их подходя¬щими для разработчиков Windows, ориентированных на Web, поскольку большинство имен свойств похожи на имена соответствующих элементов управления Windows. Одним из самых сложных испытаний, предстоящих Web-разработчикам, явля¬ется большое количество браузеров, которые необходимо поддерживать. Различные браузеры, версии и конфигурации по-разному поддерживают HTML. Web-разра¬ботчики должны выбирать, следует ли формировать содержимое в соответствие со стандартом HTML 3.2, HTML 4.0 или же с чем-либо другим вроде XHTML 1.0 или даже WML (Wireless Markup Language — язык разметки для беспроводных систем) для мобильных устройств. Эта проблема, усугубляемая различными компаниями, выпускающими браузеры, преследовала разработчиков с тех пор, как консорци¬ум World Wide Web Consortium предложил первую версию HTML. Жизнь еще более усложнялась при использовании расширений HTML, таких как JavaScript, для соз¬дания более динамических страниц или верификации. ASP.NET решил эту проблему удивительно разумным способом. Несмотря на то что вы можете извлекать информацию о браузере клиента и его свойствах внутри страницы ASP.NET, ASP.NET фактически побуждает разработчиков игнорировать эти соображения и использовать обширный набор элементов управления Web-сервера. Эти серверные элементы управления генерируют HTML, адаптируясь к возможностям клиента. Одним из примеров являются элементы управления вери¬фикацией ASP.NET, использующие JavaScript и DHTML (динамический HTML) для совершенствования своего поведения, если оно поддерживается клиентом. Это позволяет элементам управления верификацией отображать сообщения о дина¬мических ошибках без необходимости отправки пользователем страницы серверу для продолжения обработки. Эти свойства необязательны, но они демонстрируют то, как интеллектуальные элементы управления могут составлять большую часть современных браузеров без перекрытия других клиентов. Но самое лучше заклю¬чается в том, что вам не нужны дополнительные работы по кодированию для под¬держания обоих типов клиента. Факт 7: ASP.NET легко развертывается и конфигурируется Одной из самых сложных проблем, предстающих перед разработчиками, являет¬ся развертывание готового приложения на производственном сервере. Необходимо не только переместить файлы Web-страниц, базы данных и компоненты, но также зарегистрировать компоненты и повторно создать множество параметров конфи¬гурации. В ASP.NET этот процесс существенно упрощен. Каждая инсталляция .NET Framework предоставляет одинаковые базовые клас¬сы. Поэтому развертывание приложения ASP-NET является относительна простым. В большинстве случаев просто потребуется скопировать все файлы в виртуальный каталог на производственном сервере (с использованием программы FTP или даже команды, подобной XCOPY). Установка .NET Framework на машине-хосте избавит вас от трудоемкой регистрации. Распространение компонентов, используемых вашим приложением, также является легким. Необходимо лишь скопировать сборки компонентов при раз¬вертывании Web-приложения. Поскольку вся информация о вашем компоненте хранится прямо в метаданных файла сборки, потребность в запуске программы регистрации или изменении системного реестра Windows отсутствует. Как только вы поместите эти компоненты в правильное место (подкаталог Вin каталога Web-приложения), механизм ASP.NET автоматически определит их наличие и сделает доступными вашему коду Web-страницы. Попробуйте сделать это с традиционным компонентом СОМ! Конфигурирование является еще одной задачей, связанной с развертыванием приложения, в особенности при необходимости передачи информации о безопас¬ности, такой как учетная запись и привилегии пользователя. ASP.NET упрощает процесс развертывания, сводя к минимуму зависимость от настроек IIS (Internet information Services — информационные службы Internet). Вместо этого большин¬ство установок ASP.NET хранится в специальном файле web.config. Файл web.config помещается в тот же каталог, что и Web-страницы. Он содер¬жит иерархически сгруппированные настройки приложения, хранимые в удобочитаемом формате XML, который можно редактировать с использованием простого текстового редактора подобного Notepad. При изменении настройки приложения ASP.NET замечает это изменение и перезапускает приложение в новом домене: при¬ложения (поддерживая существующий домен приложения вплоть для завершения обработки каких-то невыполненных запросов). Файл web. config никогда не бло¬кируется, поэтому его можно обновлять в любое время. |