что такое dot net

Обеспечение согласованной объектно-ориентированной среды программирования для локального сохранения и выполнения объектного кода, для локального выполнения кода, распределенного в Интернете, либо для удаленного выполнения.

Предоставление среды выполнения кода, в которой:

сведена к минимуму вероятность конфликтов в процессе развертывания программного обеспечения и управления его версиями;

гарантируется безопасное выполнение кода, включая код, созданный неизвестным или не полностью доверенным сторонним изготовителем;

исключаются проблемы с производительностью сред выполнения скриптов или интерпретируемого кода;

обеспечиваются единые принципы разработки для разных типов приложений, таких как приложения Windows и веб-приложения;

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

Обозреватель Internet Explorer может служить примером неуправляемого приложения, размещающего среду выполнения (в виде расширений типов MIME). Размещение среды выполнения в обозревателе Internet Explorer позволяет внедрять управляемые компоненты или элементы управления Windows Forms в HTML-документы. Такое размещение среды позволяет выполнять управляемый мобильный код и пользоваться его существенными преимуществами, в частности выполнением в условиях неполного доверия и изолированным хранением файлов.

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

Возможности среды CLR

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

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

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

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

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

Наконец, среда выполнения может размещаться в высокопроизводительных серверных приложениях, таких как Microsoft SQL Server и службы IIS (Internet Information Services). Такая инфраструктура позволяет использовать управляемый код для написания собственной логики программ, пользуясь при этом высочайшей производительностью лучших производственных серверов, которые поддерживают размещение среды выполнения.

Приложения с графическим интерфейсом Windows (Windows Forms). См. статью Windows Forms.

Приложения Windows Presentation Foundation (WPF). См. статью Windows Presentation Foundation.

Сервисноориентированные приложения, использующие Windows Communication Foundation (WCF). См. статью Разработка сервисноориентированных приложений с помощью WCF.

Приложения, поддерживающие бизнес-процессы Windows Workflow Foundation (WF). См. Windows Workflow Foundation.

Источник

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

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

Кроссплатформенные

Поддерживаемые архитектуры процессоров:

.NET позволяет использовать специальные возможности платформы, такие как API операционной системы. Примерами являются Windows Forms и WPF в Windows и собственные привязки к каждой мобильной платформе из Xamarin.

Открытый исходный код

Поддержка

Инструменты и производительность

.NET предоставляет возможность выбора языков, интегрированных сред разработки (IDE) и других средств.

Языки программирования

C# (произносится как «си шарп») — современный объектно-ориентированный и типобезопасный язык программирования. C# относится к широко известному семейству языков C, и покажется хорошо знакомым любому, кто работал с C, C++, Java или JavaScript.

Язык F# поддерживает функциональные, объектно-ориентированные и императивные модели программирования.

Интегрированные среды разработки

Онлайн-среда Visual Studio Code, которая в настоящее время доступна в виде бета-версии.

Пакет SDK и среды выполнения

Загружаемый пакет SDK содержит следующие компоненты.

Загружаемая среда выполнения содержит следующие компоненты.

Дополнительные сведения см. в следующих ресурсах:

Система проектов и MSBuild

И вот один для веб-приложения:

NuGet

Дополнительные сведения см. в документации NuGet.

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

Дополнительные сведения см. в следующих ресурсах:

Модели выполнения.

.NET CLR — это кроссплатформенная среда выполнения, которая включает поддержку Windows, macOS и Linux. Среда CLR обрабатывает выделение памяти и управление ей. Среда CLR также является виртуальной машиной, которая не только выполняет приложения, но и создает, а также компилирует код с помощью JIT-компилятора.

Для получения дополнительной информации см. Common Language Runtime.

JIT-компилятор и промежуточный язык

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

Компилятор AOT

Автоматическое управление памятью

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

GC — это одна из служб CLR, которая помогает обеспечить безопасность памяти. Программа является безопасной по памяти, если она обращается только к выделенной памяти. Например, среда выполнения гарантирует, что приложение не обращается к невыделенной памяти за пределами границ массива.

Дополнительные сведения о сборке мусора см. в статьях Автоматическое управление памятью и Основы сборки мусора.

Работа с неуправляемыми ресурсами

Дополнительные сведения см. в разделе Очистка неуправляемых ресурсов.

Модели развертывания

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

Исполняемые файлы создаются для конкретных целевых платформ, которые указываются с помощью идентификатора среды выполнения (RID).

Библиотеки среды выполнения.

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

Расширения библиотек среды выполнения

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

Доступ к данным

.NET предоставляет объектно-реляционный модуль сопоставления (ORM) и способ написания SQL-запросов в коде.

Entity Framework Core

LINQ позволяет писать декларативный код для работы с данными. Данные могут быть представлены разными формами (например, объектами в памяти, содержимым базы данных SQL или XML-документом), но обычно создаваемый код LINQ не отличается для каждого из источников данных.

Уточнение терминологии

Среда выполнения

платформа

Пакет SDK

platform

Сложные сценарии

Взаимодействие на уровне машинного кода

Основным способом осуществления взаимодействия с собственными API является «вызов неуправляемого кода» или сокращенно P/Invoke. P/Invoke поддерживается на платформах Linux и Windows. Способ, который подходит только для Windows, называется «COM-взаимодействием» и используется для работы с COM-компонентами в управляемом коде. Он основан на инфраструктуре P/Invoke, но работает иначе.

Небезопасный код

Дополнительные сведения см. в разделе Небезопасный код и указатели.

Источник

.NET – набор вертикалей

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

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

Рождение переносимых библиотек классов (Portable Class Library, PCL)

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

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

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

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

Это позволяет говорить о различиях в API между вертикалями уже на уровне сборок в отличие от индивидуальных различиях в API, как это было раньше. Это позволяет нам реализовать механизм библиотек кода, которые нацелены на множество вертикалей. Такие библиотеки сегодня известны как переносимые библиотеки классов (portable class libraries).

Объединение формы API против объединения реализаций

Намного лучше унифицировать реализации: вместо того, чтобы только предоставлять хорошо декомпозированное описание, мы должные подготовить декомпозированную реализацию. Это позволит вертикалям просто использовать одну и ту же реализацию. Сближение вертикалей больше не будет требовать дополнительных действий; оно достигается просто за счет правильного конструирования решения. Конечно все равно будут случаи, в которых необходимы различные реализации. Хороший пример этого – это файловые операции, требующие использования разных технологий в зависимости от окружения. Однако, даже в этом случае намного проще попросить каждую команду, отвечающую за конкретные компонент, подумать, как из API будут работать в разных вертикалях, чем постфактум пытаться предоставить единый набор API поверх. Переносимость – это не есть что-то, что вы можете добавить после. К примеру, наш File API включает поддержку Windows Access Control Lists (ACL), которые не поддерживаются всем окружениями. При дизайне API нужно учитывать такие моменты и, в частности, предоставлять подобную функциональность в отдельных сборках, которые могут отсутствовать на платформах, не поддерживающих ACL.

Фреймворки для всей машины против локальных фреймворков для приложения

Это все очень редкие случаи, но, когда у вас пользовательская база в 1.8 миллиарда машин, быть совместимым с 99.9% по-прежнему означает, что 1.8 миллиона машин затронуто.

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

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

Это позволяет выпускать обновления в гораздо более гибкой манере. NuGet также предлагает возможность попробовать предварительные версии, что позволяет нам выпускать сборки без строгих обещаний относительно работы конктретных API. Такой подход позволяет нам поддерживать процесс, в котором мы предлагаем вам наш свежий взгляд на дизайн сборки – и, если вам не нравится, просто его изменить. Хороший пример это – это неизменяемые коллекции (immutable collections). Бета-период длился порядка 9 месяцев. Мы потратили много времени, пытаясь добиться правильного дизайна прежде, чем выпустить первую версию. Нет необходимости говорить, что финальная версия дизайна библиотеки, — благодаря вашим многочисленным отзывам, — намного лучше, чем начальная.

.NET Core – это модульная реализация, которая может использоваться широким набором вертикалей, начиная с дата-центров и заканчивая сенсорными устройствами, доступная с открытым исходным кодом, и поддерживаемая Microsoft на Windows, Linux и Mac OSX.

NuGet как первоклассный механизм доставки

Для слоя BCL у нас будет прямое соответствие между сборками и пакетами NuGet.

В дальнейшем NuGet-пакеты будут иметь те же имена, что и сборки. К примеру, неизменяемые коллекции перестанут распространяться под именем Microsoft.Bcl.Immutable и вместо этого будут в пакет, называющемся System.Collections.Immutable.

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

Согласованность именования и версионности между сборками и пакетами сильно облегчит их поиск. У вас не должно возникнуть вопроса, в каком пакете содержится System.Foo, Version=1.2.3.0 – он находится в пакете System.Foo с версией 1.2.3.

Готов для корпоративного использования

Основа для открытого кода и кросс-платформенности

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

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

Наличие всех трех элементов позволяет нам добиться широкого спектра гибкости и зрелости решений:

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

.NET Framework 4.6

Windows Store и Windows Phone

Более детально выбор между двумя подходами описан в статье «Sharing code across platforms».

Итоги

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

А вот и другие наши статьи по схожей тематике:

Источник

DotNet, которая должна изменить мир

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

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

За последние годы стоимость компьютеров и аппаратного обеспечения упала в сотни раз, а производительность возросла в тысячи. Однако стоимость разработки ПО практически не изменилась. Почему? Каждый отвечает на этот вопрос по-своему, и к тому же всякий раз по-разному. Если же считать существующую систему разработки программ саморазвивающейся, то ответ лежит на поверхности — причины следует искать в современных технологиях. Как и в природе, где все закономерно, лучше других приспособлены к условиям среды обитания именно те формы, которые отвечают требованиям времени, т. е. жизнь сама выбирает, что лучше. В пользу этой версии свидетельствует и то, что технологии разработки ПО у разных производителей весьма схожи.

Сейчас в компьютерном мире правит бал корпорация Microsoft. Но здесь не будем предаваться размышлениям на тему, хорошо это или плохо. Ругают или нет Windows, она все равно царит повсеместно. Ругают или нет серверные продукты Microsoft (SQL Server, Exchange Server и т.д.), а их доля на рынке постоянно возрастает. Не столь важно, чем такой успех обеспечен, — удачным маркетингом или отличными технологиями, сколь важно то, что появление огромного количества продуктов Microsoft на рынке приводит к качественным изменениям. Значит, уже можно говорить о том, что есть два компьютерных мира — Microsoft вместе с компаниями, идущими близким курсом, и все остальные. Почти во всех сферах своей деятельности Microsoft испытывает мощное противоборство: в области серверных ОС с ним соперничает Sun, в сфере создания продуктов для Internet — Apache, в СУБД — Oracle и другие производители. Однако ни один противник не способен противопоставить ей что-либо по всем фронтам.

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

Однако рассмотрим ситуацию исключительно с технической стороны. Microsoft выдвинула интересную инициативу, названную «.Net» (читается и пишется «dotNet» — «дотНет»). Так что же она собирается предпринять?

Что такое и что дает dotNet?

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

Итак, ясно: чтобы получить полное представление о dotNet, нужно узнать, из чего она состоит и что дает.

На сайте Microsoft (рис. 1) всех интересующихся dotNet разделили на три категории (интересная классификация, не правда ли): пользователи и разработчики, профессионалы в области информационных технологий, бизнесмены, и для каждой предложили разъяснение, что дает dotNet именно ей.

Рис. 1. Первая страница сайта Microsoft, посвященного dotNet

Разработчикам dotNet позволяет создавать мощные программы, использующие все возможности современных компьютеров и сетей без реализации вспомогательных функций (практически почти все эти функции берет на себя платформа), и заниматься только реализацией бизнес-логики своего продукта. Следовательно, они будут способны быстро создавать качественные (и простые!) программы, имеющие множество возможностей, интегрированных c Internet, столь необходимые пользователям. Это ведет к улучшению и удешевлению ПО, а также к уменьшению количества ошибок.

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

Сейчас время бурного развития электронной коммерции. Имеющийся инструментарий создания сетевых торговых площадок уже не всегда удовлетворяет требованиям бизнеса. И при разработке новых средств для этой области основное слово должна сказать технология Web-сервисов (WebService).

Рис. 2. Структура dotNet

Претендующая на всеохватность технология dotNet должна состоять из множества компонентов, связанных между собой. Структура платформы dotNet (рис. 2) делится на несколько частей:

Среда dotNet (.Net Framework)

К основным компонентам среды dotNet (рис. 3) относятся операционная система, под управлением которой работает Среда исполнения общего языка (CLR, Common Language Runtime) и ее сервисы (библиотеки классов и библиотеки, поддерживающие технологии WebService, WebForms, WinForms и т. д.).

Рис. 3. Основные компоненты среды dotNet

Технология dotNet позволяет упрощать создание программных компонентов и контролировать исполнение. Их можно разрабатывать на языках программирования Cи++, Visual Basic и совершенно новом языке C# фирмы Microsoft (его название произносится как «си-шарп», а если перевести с языка нотной записи, то как до-диез, т. е. тот же Cи или Cи++, но на полтона выше). Это достигается с помощью Среды исполнения общего языка. Если раньше все программы, кроме интерпретируемых, выполнялись непосредственно с помощью ОС и команд процессора, то с появлением CLR разработчики смогут выбирать, какие создавать продукты: либо выполняющиеся на свой страх и риск, самостоятельно оперирующие возможностями ОС и процессора, либо такие, за работой которых будет строго следить CLR, проверяя, правильно ли выделяются и вовремя ли высвобождаются ресурсы, не происходит ли недопустимых действий и т. д. Неконтролируемые (unmanaged) программы пишутся только на Cи++, а контролируемые (managed) — на Cи++, Visual Basic или C#. Но чудес не бывает — и контролируемые программы делаются только на подмножестве Cи++. Несколько примиряет с этим то, что теперь разрешено создавать класс на Cи++, наследовать от него в Visual Basic, а использовать на C#.

Среда CLR напоминает и Java, и виртуальную машину Java с исполнением байт-кода, за исключением следующего:

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

Серверные продукты dotNet

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

Позже были реализованы средства для обеспечения совместной работы, например Lotus Notes и Exchange, которые, кроме того, служат и платформами для разработки.

Затем вошли в обиход продукты, обеспечивающие доставку сообщений (Message Oriented Middleware), такие как IBM MQSeries и MSMQ. Они позволяют организовать обмен сообщениями в распределенной системе, имеющей разнородные (и подчас ненадежные) каналы связи. Их отличие от почтовых серверов заключается в том, что они ориентированы на обмен информацией не между людьми, а между различными частями программных систем.

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

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

Все шире применяется специализированное серверное программное обеспечение. Microsoft в системе dotNet лишь развивает это направление, оставив существующие продукты (Exchange и SQL) и добавив новые (BizТalk Server, Application Center 2000). Кратко опишем их возможности.

Некоторые серверы, ранее бывшие отдельными продуктами, теперь вошли в состав Windows 2000, например Internet Information Server, ставший Internet Information Services, Certificate Server, MSMQ (Microsoft Message Queue Server), MTS (Microsoft Transaction Server) и т.д.

Web-сервисы

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

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

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

Технология Web-сервисов, предоставляющая открытые стандарты взаимодействия корпораций между собой, поможет позволить реализовывать межкорпоративные информационные системы без длительного согласования интерфейсов. Такие стандарты уже есть — HTTP как транспортный протокол, язык XML как средство представления информации и новый протокол SOAP взаимодействия программных компонентов в Internet. (см. «Мир ПК» 12/2000, с.154)

Средства и технологии разработки

Чтобы создавать ПО для работы на платформе dotNet, потребовались новые средства и технологии, среди которых наиболее заметными стали управляемое исполнение кода (managed execution) и новый язык программирования C#. Последнему сейчас уделяется излишнее внимание, и многие, говоря о dotNet, думают о C#, а ведь это, хотя и заметное, все же лишь одно из множества новшеств.

Язык C# достаточно похож по синтаксису и возможностям на Java (да простят меня адепты и Sun, и Microsoft) и давно служит желанной цели (уж очень давно к ней стремятся) — созданию языка, столь же мощного, как Cи++, но простого и безопасного. Можно назвать это и одним из проявлений борьбы между универсальностью и эффективностью, в которую включился и такой критерий, как простота использования.

Однако в C# нет ничего, чего не встречается в других языках программирования.

Технология доступа к данным ADO+ — это существенно переработанная версия ADO (Active Data Objects). От существующих технологий ее отличает (помимо того, что она имеет совершенно другую объектную модель) возможность распределенной работы благодаря использованию XML и строгая типизация. Кроме того, она обладает расширенными возможностями работы с неструктурированными или слабоструктурированными данными.

Компоненты ASP+, WebForms и WinForms технологии dotNet отличаются новшествами в создании пользовательского интерфейса: WinForms предоставляют возможности для его разработки в локальных программах, ASP+ (Active Server Pages) и WebForms — в Internet. Технология WinForms развивает общепринятую тенденцию разработки библиотек классов пользовательского интерфейса, а ASP+ и WinForms привносят эти методы в программирование интерфейса в Web-решениях.

Рис. 4. Среда разработки Visual Studio

Долгожданная версия средств разработки Visual Studio.Net (рис. 4) корпорации Microsoft целиком ориентирована на dotNet. Счастливчики уже этим летом могли увидеть и попробовать в работе Visual Studio.Net. На конференции профессиональных разработчиков PDC (Professional Developers Conference), прошедшей в июле этого года, участникам были розданы диски с даже не бета-версией, а всего лишь с ознакомительным вариантом Visual Studio. Тем не менее продукт оказался достаточно стабильным и доработанным, на нем уже сейчас можно создавать ПО для платформы dotNet. (Пока готовилась статья, уже вышла в свет бета-версия Visual Studio.Net. — Прим. ред.)

Следует также отметить наличие в Visual Studio.Net единой среды разработки для перечисленных выше языков программирования, возможности управлять всей программной системой (состоящей из серверов, БД и т.д.) прямо из этой среды, и возросшее удобство работы.

Практически все, познакомившись с dotNet, задаются вопросом: чем же этот набор технологий отличается от Java? С определенной натяжкой можно сказать, что dotNet — ответ Microsoft Sun. Microsoft сначала попыталась пойти по пути взаимодействия с Java, но не встретила отклика со стороны Sun. Видимо, многочисленные судебные разбирательства привели Microsoft к мысли, что проще разработать свою технологию, нежели пытаться принять и развить подходы, являющиеся собственностью другой, конкурирующей компании. Тем более что dotNet гораздо богаче Java и по идеям, и по возможностям реализации. Основной парадигмой Java была (и, судя по всему, остается) многоплатформность (отчасти надуманная), а у dotNet задачи несколько иные (хотя не отрицается и эта). К самому ощутимому минусу технологии dotNet (хотя я считаю это явным плюсом) можно отнести то, что в ней имеется множество отличий от всего ныне существующего. Значит, всем нам, особенно разработчикам ПО, придется адаптироваться к новым условиям и переучиваться. А у нас, судя по популярности консольных приложений и Turbo Pascal 7.0, которому посвящают все новые и новые книжки, овладевать чем-нибудь новым не очень-то любят.

Правда, внушает оптимизм бурная реакция на появление dotNet со стороны производителей ПО — проявила интерес Corel (пусть и несколько вынужденный) и возникли слухи о переносе dotNet на Unix (слишком уж активно опровергаемые). Определенно, нас ждут интересные события в компьютерном мире — Microsoft приготовила еще немало сюрпризов и раскрыла не все карты. Так что следите за новостями.

Александр Ложечкин — системный аналитик компании Digital Design, e-mail: alozhechkin@hotmail.com

Для тех, кто хочет узнать больше

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

Источник