www.softo-art.narod.ru

Softo-Art.narod

.RU 

Написать Webmaster`y

 

                                           Сегодня :                                                      Добавить в Избранное

Разделы Сайта

Статья

---------------------------

Главное Меню

---------------------------

·    Главная

·    Файловый Архив

·    Новости Железа

·    IT-Новости

·    Архив Статей

·    Вебссылки

·    Фильмы

·    Музыка

·    Юмор

·    Клипы

·    Поиск по сайту

---------------------------

Связь

---------------------------

·    Forum

·    Гостевая Книга

·    Email

---------------------------

Реклама

---------------------------

Qwerti.ru

Введение в Delphi 8

Источник: superq.ru

 

Система программирования Borland ® Delphi™ For Microsoft ® .NET Framework - сложный программный продукт, дающий программисту все необходимые средства для создания программ любой сложности и назначения. Характерной особенностью системы является органичная поддержка новой технологии .NET. В этой главе приводится краткий обзор Delphi и технологии .NET.
Знакомство с технологией .NET

 

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

В основе технологии .NET лежит идея использования некоторого промежуточного машинно-независимого языка. В обычном программировании (с использованием любых существующих вне технологии .NET языков - от Ассемблера до ранних версий Delphi) программа, написанная в понятной для программиста нотации, компилировалась в последовательность машинных инструкций, "понятных" процессору. В новой технологии программа компилируется в термины машинно-независимого языка CIL (Common Intermediate Language - общий промежуточный язык) и сопровождается метаданными - подробными инструкциями как о самой программы, так и о всем необходимом для ее успешного выполнения. В момент, когда коды промежуточной программы (они называются управляемыми кодами) ставятся на исполнение, в дело вступает среда CLR (Common Language Runtime - общеязыковая среда исполнения), которая с помощью встроенного JIT-компилятора (JIT - just-in-time - вовремя, по мере надобности)1 переводит управляемые коды в набор исполняемых машинных инструкций и обеспечивает разнообразные вспомогательные действия для исполняемой программы.

Идея использования машинно-независимого промежуточного языка не нова. Впервые она была высказана еще в 1958 г. американским программистом Мелвином Е. Конвеем (Conway) в журнальной статье "Proposal For An UNCOL" ("Предложение по универсальному компьютерно-ориентированному языку"). Двухфазное кодирование имеет два существенных преимущества. Во-первых, предельно упрощается распространение программ. Переведенная в СIL программа может выполняться на любом компьютере, имеющем соответствующую среду исполнения. Причем в управляемый код включается вся системная информация, необходимая для нормального функционирования программы, так что отпадает необходимость в регистрации отдельных частей программы (объектов, модулей, динамических библиотек) в системном реестре.

Замечание:
В настоящее время технология .NET реализована для ОС семейства Windows. Существуют проекты переноса технологии в ОС FreeBSD, Mac OC X 10.2 и Linux. Однако распространение .NET на другие платформы затруднено, в основном, проблемами воспроизведения пользовательского интерфейса: экраны настольного компьютера, наладонного компьютера или мобильного телефона совершенно отличны.

Во-вторых, повышается защищенность программ и файлов: в управляемых кодах нет информации о файловой системе компьютера, на котором исполняется программа, или способах запуска программ, а среда исполнения сконструирована так, чтобы всемерно уберечь программно-аппаратные средства компьютера от атак вирусов, других злонамеренных программ, а также от программных ошибок.
Общеязыковая инфраструктура
Общеязыковая инфраструктура CLI (Common Language Infrastructure) - это набор перечисленных ниже спецификаций, определяющих различные аспекты технологии .NET.
Common Type System (CTS) - общая система типов. Определяет возможность взаимодействия программ и их частей, написанных на разных языках программирования. Каждый компилятор, вырабатывающий инструкции CLI, должен частично или полностью использовать CTS и никакие другие типы данных, кроме указанных в CTS. Набор перечисленных в CTS типов значительно превышает количество типов в реально существующих языках программирования.
Common Intermediate Language (CLI) - общий промежуточный язык программирования 2. Это - язык инструкций абстрактного процессора. В этом отношении CLI - аналог байткода Java.
Extensible Metadata - расширяемые метаданные. В технологии подразумевается, что инструкции CLI помещаются в единицу распространения - сборку (assembly) - и сопровождаются метаданными, которые делают сборку полностью самоописываемым объектом. В метаданные помещаются имя и версия сборки, сведения о локализации, данные о типах, включенных в сборку, список внешних файлов (сборок), от которых зависит данная сборка и т. п.
Framework Class Library (сокращенно .NET Framework) - это библиотека классов, которые должна использовать любая программа в рамках технологии. Библиотека VCL Delphi в чем-то подобна .NET Framework. Разница между ними, прежде всего, состоит в том, что библиотеку .NET Framework можно использовать при создании программ на любом, поддерживающем технологию .NET, языке программирования. Более того, в Delphi (или в C#, J# и т. д.) вы можете расширять эту библиотеку новыми классами, которые затем могут использоваться в программах на других языках программирования.
Platform Invocation Service (сокращенно P/Invoke) - служба согласования платформ. Программы, исполняемые в .NET, предельно изолированы друг от друга и от средств операционной системы. Однако вне этих средств .NET Framework не может реально работать. P/Invoke реализует взаимодействие .NET Framework и операционной системы.
Extended Portable Executable (PE) File Format - стандартный формат исполняемых файлов в Win32, используемый для хранения объектов технологии. Он загружается обычным загрузчиком точно так же, как и любой другой исполняемый файл. Однако в его заголовке имеется бит, указывающий на то, что файл относится к технологии .NET. Обнаружив бит, загрузчик вызывает CLR, которая и производит обработку файла.


Библиотека классов и пространства имен


Замечательной особенностью новой технологии является ее объектная ориентация. Вместе с CLR в рамках программного продукта .NET Framework (этот продукт свободно доступен на сайте www.microsoft.com) поставляется обширная библиотека классов, которую должна использовать новая операционная система с рабочим названием Longhorn (выпуск намечен на 2005-2006 гг.) и все работающие под ее управлением программы.

Классы в .NET Framework организованы в ветвящиеся иерархические структуры, которые называются пространствами имен. До технологии .NET практически все промышленные операционные системы (ОС) строились из крошечных "кирпичиков", которые назывались функциями API (Application Program Interface - интерфейс прикладных программ). Эти функции выполняли небольшие локальные задачи как для нужд самой ОС, так и для любой работающей под ее управлением программы. В системах с .NET Framework роль функций API играют объекты (экземпляры классов).
Общеязыковая среда исполнения


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

Управляемый код в общем случае порождает объекты с управляемым временем жизни. Такие объекты автоматически уничтожаются, когда надобность в них исчезает (например, завершает работу создавшая их программа). Таким образом, одной их замечательных способностей CLR является встроенная в нее борьба с утечкой памяти3.

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

CLR облегчает разработку компонентов и программ, объекты которых взаимодействуют с помощью языка. Объекты, написанные на разных языках, могут взаимодействовать друг с другом, и их поведение может быть тесно связанным. Например, вы можете определить класс и его потомка на разных языках или вызвать метод класса, написанного на другом языке. Межъязыковое взаимодействие возможно потому, что языковые компиляторы и инструменты целевой машины используют общую систему типов, определенную в CLI, и они следуют общим правилам для определения новых типов, а также их создания, использования, снабжения данными и связывания типов.
Компилирование в промежуточный язык CIL


При создании управляемого кода компилятор языка программирования, поддерживающего .NET (Visual Basic .NET, C#, J#. а с появлением Delphi 8 еще и Delphi4 ) транслирует исходный код в набор машинно-независимых инструкций языка CIL.

Замечание:
Синтаксис того или иного языка никак не влияет на CLR. Однако некоторые языки (C#, Delphi), не имеют существенных синтаксических ограничений и позволяют использовать практически все возможности CLR.

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

Одновременно с инструкциями CIL производятся также метаданные. Метаданные описывают типы вашего кода, в том числе содержат описание каждого типа, сигнатуры вызова методов объектов, ссылки на членов вашего кода и другие необходимые при выполнении данные. MSIL и метаданные содержатся в выполняемом файле формата РЕ, который основан на расширенной версии опубликованного формата MS PE и общего объектного файлового формата, использующегося исторически для выполняемых программ. Этот файловый формат, который объединяет CIL-код и метаданные, предоставляет операционной системе компьютера исполнения всю необходимую информацию для создания объектов CLR. Присутствие в CIL-кодах метаданных позволяет коду описывать самого себя и, таким образом, отказаться от библиотек типов и языка IDL (Interface Definition Language - язык описания интерфейсов). CLR находит и извлекает метаданные из РЕ-файла по мере надобности в ходе прогона.
Компилирование CIL в машинные инструкции


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

В ходе компиляции CIL-кода он передается верификационному процессу. Верификация проверяет код CIL и метаданные в поисках выхода из надежного кода. Надежность типов объектов есть надежность их изолирования от других объектов и надежность защиты их от ошибочного иди злонамеренного разрушения.

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


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

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


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

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

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

Оптимизирующая машина сборщика мусора определяет наилучшее время для удаления мусора. В процессе очистки он удаляет из памяти объекты, которые более не используются приложением. Для этого он исследует корни приложений. Каждое приложение имеет набор корней. Каждый корень либо ссылается на объект в управляемой куче, либо содержит NIL. Корни включают указатели на глобальные и статические объекты, локальные переменные и ссылки на объектные параметры в стеке потока и регистрах процессора. Мусорщик имеет доступ к списку активных корней, которые управляются компилятором времени исполнения и CLR. Используя этот список, он проверяет корни и строит граф, который содержит все объекты, которые порождены от корня.

Объекты, которые не содержит граф, не порождены от корней приложения. Мусорщик удаляет эти объекты из памяти. При этом он оптимизирует состояние управляемой кучи и нужным образом корректирует указатели.
Сборки
Сборки - фундаментальные части программирования с .NET Framework. Сборка выполняет перечисленные ниже функции.
Она содержит код, который выполняет CLR. СIL-код в файле формата РЕ не будет исполняться, если не имеет связанного с ним манифеста сборки. Учтите, что сборка может иметь только одну точку входа.
Она формирует границы защиты. Сборка есть блок, в котором запрашиваются и выдаются разрешения.
Она формирует границы типа. Каждый идентификатор типа включает имя сборки, в которой он расположен. Тип MyType, загруженный в пределах одной сборки, в общем случае может отличаться от одноименного, но загруженного в другую сборку.
Она определяет границы видимости ссылок. Сборочный манифест содержит метаданные, которые используются для разрешения ссылок и удовлетворения ресурсных требований. Манифест указывает экспортируемые типы и ресурсы и перечисляет другие сборки, от которых зависит данная сборка.
Она определяет границы версионного контроля. Сборка представляет собой минимальный блок в CLR, все типы и ресурсы которого имеют ту же версию, что и версия блока.
Она определяет единицу распространения. В момент старта должны быть загружены только первоначально вызванные сборки. Другие сборки, такие как ресурсы локализации или сборки, содержащие вспомогательные классы, могут загружаться по требованию. Это упрощает приложения и делает их меньше, что облегчает загрузку из Интернета.
Она является единицей, для которой поддерживается параллельное выполнение (side-by-side, см. ниже).

Если вы уже имели опыт работы с Delphi или Turbo Pascal, то заметите, что многие свойства сборок соответствуют свойствам модулей этих систем программирования.

Сборки могут быть статическими и динамическими. Статические сборки включают типы .NET Framework (интерфейсы и классы), а также нужные ресурсы. Статические сборки сохраняются на диске в виде РЕ-файлов. Вы можете использовать .NET Framework для создания динамических сборок, которые не сохраняются на диске и создаются (и запускаются) непосредственно в памяти. После выполнения динамическую сборку можно сохранить на диске.

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

Объединение этих двух проблем порождает конфликты DLL, когда инсталляция одного приложения может нарушить функциональность другого из-за того, что вновь установленный компонент или DLL не совместим с предыдущей версией. При возникновении такой ситуации у ОС нет средств обнаружения и устранения проблемы.
Windows 2000 (ХР) частично решает проблему с помощью двух приемов.
Windows 2000/ХР разрешает размещать вспомогательные DLL в ту же папку, что и исполняемый файл. Такие компоненты отыскиваются первыми и поэтому игнорируются другие версии.
Windows 2000/ХР блокирует файлы, которые помещаются в системную папку System32 при установке ОС, и не позволяет другим приложениям замещать их.
Для решения проблемы версионности сборки делают следующее.
Разрешают разработчику указывать версионные правила между различными компонентами.
Реализуют инфраструктуру поддержки версионности.
Реализуют параллельное (side-by-side) выполнение разных компонентов.

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


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

Приложения изолируются прежде всего из-за того, что адресные указатели зависят от процесса. Указатель, переданный из одного приложения другому, никак не может использоваться в нем. Более того, вы не можете из одного процесса обратиться непосредственно к другому. Вместо этого вы должны использовать механизм представителей (proxy), которые реализуют косвенные вызовы, как это делается в СОМ (Component Object Model - компонентная модель объектов).

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

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

Замечание:
Нельзя выгрузить сборку или тип, но можно - домен.
Код, исполняемый в одном приложении, не имеет непосредственного доступа к коду или ресурсу другого приложения. CLR обеспечивает изоляцию путем предотвращения вызовов между объектами в разных доменах приложений. Объекты, которыми обмениваются домены, могут быть копиями или полученными через представителей. Если объект - копия, его вызов локальный. Это означает, что как получатель объекта, так и сам объект находятся в одном домене. Если объект получен через представителя, этот объект - удаленный. В этом случае получатель и объект находятся в разных доменах. Как следствие, доступ к метаданным объекта должны иметь оба домена, чтобы обеспечить правильную работу встроенному компилятору для вызова методов (в противном случае - ошибка).
Домены и сборки


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

Если одна и та же сборка используется несколькими доменами, ее код (но не данные) могут разделяться доменами. Это уменьшает затраты памяти. Этот метод подобен разделению DLL. Сборка называется доменно-нейтральной, если ее код может разделяться другими доменами в одном процессе. CLR решает, будет ли сборка доменно-нейтральной.

Сборка не разделяется между доменами, если предоставляемые ею возможности нужны лишь одному домену.
Знакомство с DELPHI 8


Ограниченная поддержка технологии .NET была реализована еще в предыдущей версии Delphi 7 Studio. Однако в этой версии .NET могла и не использоваться. Версия Delphi 8, напротив, не может не использовать эту технологию. Для совместимости с предыдущими версиями в ней используются пространства имен Borland.VCL.XXXX, позволяющие ценой небольших изменений исходного кода в версии 8 компилировать и исполнять программы, написанные в предыдущих версиях. Однако, такая совместимость - мнимая, так как компилятор новой версии порождает инструкции языка СIL, которые могут исполняться только под управлением CLR.

В этом разделе кратко рассматриваются новые возможности Delphi, связанные с переходом на новую технологию .NET.
Устаревшие и новые средства Delphi

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

Прежде всего, речь идет об указателях. Указатели считаются небезопасным типом, так как код, содержащий указатели, нельзя проверить на безопасность. Запрещена любая арифметика указателей, а также обращение к функциям и процедурам New, Dispose, GetMem, FreeMem и ReallocMem. Вместо концепции указателей программы должны использовать два класса из CTS: IntPtr и Marshal. Первый - суть универсальный платформеннонезависимый указатель, открывающий доступ к механизму межплатформенного взаимодействия P/Invoke. Второй осуществляет маршализацию данных, то есть низкоуровневое взаимодействие процессов, включая упаковку/распаковку передаваемых данных.
В следующем примере создается и используется указатель для размещения в нем целого числа.

uses System.Runtime.InteropServices;
var
X: IntPtr;
begin
X := Marshal.AllocHGlobal(SizeOf(Integer));// Создаем указатель
try // на 4 байта
Marshal.WriteInt32(X, 123456); // Наполняем его
Caption := IntToStr(Marshal.ReadInt32(X) * 2); // Используем
finally
X.Free; // Освобождаем
end
end;

Запрещены типизированные и нетипизированные файлы. Безопасный код может использовать только текстовые файлы типа FileVar: TextFile. Для работы с не текстовыми файлами рекомендуется использовать объекты класса TFileStream. Например, следующая программа создаст файл, содержащий 5 случайных вещественных чисел.

procedure TForm3.Button1Click(Sender: TObject);
var
A: Real;
k: Integer;
F: TFileStream;
begin
F := TFileStream.Create('data.dat', fmCreate);
try
for k := 1 to 5 do
begin
A := Random;
F.Write(A, SizeOf(Real));
end;
finally
F.Free
end
end;
Записи не могут содержать вариантную часть, но могут - методы (см. ниже).

В .NET Framework используются "широкие" символы (2 байта на символ). В связи с этим небезопасным считается тип PChar, который используется как ссылка на массив однобайтных символов. В то же время формат типов String в Delphi и CTS совпадает.

Поскольку тип PChar в программах Delphi используется, в основном, при обращении в функциям API, вместо PChar следует использовать класс StingBuilder. Следующая программа прочитает заголовок активного окна:

function GetText(Window: HWND;
BufSize: Integer = 1024): String;
var
Buffer: StringBuilder;
begin
Buffer := StringBuilder.Create(BufSize);
GetWindowText(Window, Buffer, Buffer.Capacity);
Result := Buffer.ToString;
end;


Устаревшие возможности кода

Компилятор Delphi отныне не поддерживает встроенный ассемблер и директивы asm.

Запрещено использовать функции прямого доступа к памяти, такие как BlockRead, BlockWrite, GetMem, FreeMem, ReallocMem, а также директиву absolute и функцию addr. Поддерживается операция @ (получение адреса).
Новые возможности Delphi

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

type
MyRec = record
a: Integer;
procedure aProc;
end;

procedure MyRec.aProc;
begin
end;

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

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

var
T: System.Type;

Однако "путь" к классу может быть достаточно длинным, и составное имя окажется громоздким. В этом случае Delphi разрешает перед именем класса ставить символ "&" (амперсанд):

var
T: &Type;

Встретив такое описание, компилятор станет просматривать список доступных модулей в поисках типа Type и найдет его в модуле System.

Существенным изменениям подверглось объявление класса. Дело в том, что Delphi и CLR по-разному трактуют области видимости секций private и protected: в Delphi члены, объявленные в этих секциях, видны всюду в пределах данного модуля. В CLR секция private объявляет члены, доступные только внутри методов класса, а секция protected - члены, доступные потомкам класса. В связи с этим, в Delphi перед названиями секций следует ставить спецификатор class - в этом случае области видимости в Delphi и CLR совпадут:

type
MyClass = class
class private
a: Integer; // Поле видно только в методах класса MyClass
class protected
b: Boolean; // Поле видно только потомкам класса и самому классу
end;

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

type
NoInst = class
public
procedure NoOverride; dynamic; final; // Метод нельзя перекрыть
end sealed; // Класс не может иметь потомков

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

procedure NoOverride; final;

Можно лишить возможности перекрывать только виртуальные методы, то есть объявленные с директивами dynamic, virtual или override.


Две модели Windows-приложений

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

С этой целью они создали пространства имен Borland.VCL.XXXX, почти полностью имитирующие библиотеку компонентов VCL (Visual Component Library - библиотека визуальных компонентов) предыдущих версий. В эти пространства имен вошли VCL-классы, хорошо известные по предыдущим версиям - TApplication, TForm, TButton, TCheckBox и т. д. Символы ХХХХ в названиях пространств имен совпадают с именами соответствующих модулей VCL. Например, пространство имен Borland.VCL.DB содержит классы, определенные в модуле DB библиотеки VCL (клас-сы для работы с базами данных). Класс TForm определен в пространстве имен Borland.VCL.Forms, в этом же пространстве определен класс TApplication, класс TButton - в пространстве имен Borland.VCL.StdCtrls, в этом пространстве объявлен также класс TCheckBox и т. д.

Пространства имен Borland.VCL.XXXX являются прозрачными надстройками над пространствами имен классов, входящих в .NET Framework, но не закрывают их. Это означает, что вам доступны и классы .NET Framework. Чтобы создать Windows-приложение, базирующееся на классах .NET Framework, вы выбираете команду меню
File > New > Windows Forms Application, для создания VCL-подобного приложения - команду File > New > VCL Forms Application.
Работа с базами данных

Отличительной особенностью системы программирования Delphi была и остается встроенная в нее возможность работы с различными промышленными базами данных (БД). Добрая треть компонентов VCL в Delphi 7 в той или иной степени связаны с созданием приложений для работы с БД.

В .NET Framework встроена архитектура ADO.NET, решающая аналогичные задачи. Упрощенная схема этой архитектуры показана на рис.1.1.

Рис. 1.1. Архитектура ADO.NET

На этой схеме Источник данных - физическая БД или XML-файл с данными. Провайдер данных обеспечивает связь с Источником данных и передает ему команды. Набор данных предназначен для отображения данных. С любым источником данных (ИД) могут быть связаны один или несколько наборов данных (НД) и наоборот - единственный НД может отображать данные из нескольких ИД.

Провайдер данных, входящий в архитектуру ADO.NET, обеспечивает взаимодействие наборов данных с такими ИД, как MS SQL Server, OLE DB и Oracle. В Delphi 8 можно использовать также провайдер BDP.NET (Borland Database Provider for .NET - провайдер баз данных корпорации Borland для .NET), который обеспечивает взаимодействие с серверами DB2, Oracle и InterBase. Дублирование в BDP.NET связи с промышленным сервером Oracle не случайно: корпорации Borland и Oracle связывает многолетнее плодотворное сотрудничество5. По оценкам разработчиков Delphi, управление сервером Oracle с помощью BDP.NET дает определенные преимущества по сравнению с управлением через провайдер ADO.NET.

Наличие BDP.NET не ограничивает новаторского подхода разработчиков Delphi к интеграции с технологией .NET Framework. Связано это с тем, что изначально Delphi тяготела к приложениям для работы с БД в значительно большей степени, чем разработанная в Microsoft технология ADO (Active Data Object - активный объект данных), которая и легла в основу ADO.NET. Delphi 7, например, поддерживала такие технологии, как BDE (Borland Database Engine - машина баз данных корпорации Borland; обеспечивала доступ к файл-серверным БД на таблицах Paradox, dBASE и т. п.), dbExpress (набор скоростных драйверов для непосредственного доступа к некоторым промышленным серверам, в том числе - к MySQL), IBX (доступ к серверу InterBase на уровне его API-функций), DataSnap (разработка многозвенных СУБД) и ряд других.

Delphi 8 определяет естественную миграцию этих технологий в новую среду. Для этого в ее состав включены такие дополнительные технологии:
TADONETConnector - универсальный класс (наследник TDataSet), который разработчики рекомендуют как наиболее простой и эффективный путь миграции существующих приложений с НД (например, TADODataSet);
dbExpress.NET - миграция технологии dbExpress;
DataSnap .NET Client - поддержка многозвенных СУБД;
IBX.NET - миграция технологии IBX;
BDE.NET - миграция технологии BDE.

Поддержка этих технологий доступна только в режиме разработки VCL Forms Application.
Работа с Интернет

Работа с Интернет никогда не была в Delphi столь же эффективной, как работа с БД. И хотя уже в Delphi 2 была вкладка Internet (компоненты FTP, HTML, POP и т. д.) поддержке Интернет в Delphi всегда не хватало некоторой системности. Даже многочисленные компоненты Indy в Delphi 7 годятся лишь на то, чтобы создать "самопальный" Outlook Express или скромный Web-браузер. В то же время в Microsoft разработали технологию ASP (Active Server Pages - активные страницы сервера), которая во многом упрощала актуальную ныне задачу создания интерактивных Web-сайтов (например, для электронной торговли товарами и услугами)6 . Технология ASP вошла в .NET Framework в виде ASP.NET и в полной мере доступна в Delphi 8. Для использования технологии ASP.NET на хостинге (то есть на машине, на которой развернут сайт) должен функционировать сервер Microsoft IIS (Internet Information Server - информационный сервер для Интернет корпорации Microsoft), а сам хостинг работать под управлением Windows 2000/ХР.

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

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

Внутри .NET Framework активные страницы получают доступ к данным через ADO.NET c "родным" провайдером или BDP.NET.

Валерий Васильевич Фаронов

Главная>>

 

Рекламодатели: www.hardwarez.ru / www.addweb.ru

Copyright © 2003-2004 Softo-Art – All Right Reserved.

Идея, дизайн и администратирование проекта Вараксин Артём a.k.a ArteX.

При копировании материалов, активная ссылка на сайт обязательна.

 

Hosted by uCoz
Железо Компьютеры