Отправляет email-рассылки с помощью сервиса Sendsay

Изучаем .NET Framework

Подписаться Бесплатная новостная рассылка Подписчиков 31 RSS
  Ноябрь 2003   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


За последние 60 дней ни разу не выходила


Сайт рассылки: http://msdotnet.narod.ru/
Открыта: 16-11-2003

Автор
Олег

Статистика

31 подписчиков
0 за неделю
←   Все выпуски   →

Изучаем .NET Framework


Информационный Канал Subscribe.Ru

Библиотека .NET Framework. Выпуск №1.

Для чего нужен .NET.

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

Разработчики ПО всегда начинают свой проект с величественных замыслов и колоссальных обещаний. Как алкаш, стоящий у руля партии, мы клянемся, что благодаря тщательному тестированию мы избежим ошибок, а наш весь код будет полностью документирован. Мы его всесторонне оттестируем, а после этого никаких дополнительных функций включать не будем. Более того, мы составим реалистичный график и будем его придерживаться. (“Эта функция ОС делает не совсем то, что нам нужно, но я за недельку напишу получше, так что наши требования к программе менять не надо”.) Создать надежное и полезное (в меру) приложение - в наших силах; все, что нам нужно, - дисциплина. Никаких пасьянсов. Во всяком случае, до пяти часов. Ну, ладно, одно игру во время обеда. “Черт! Проиграл! Еще разок для ровного счета, идет? Ого! Уже 16:00?” Все проекты, которые я знал, начинались с таким угарным пылом.

Хоть кто-нибудь это сделал? Хоть один разработчик сдержал свои обещания? Нет. Такого никогда не было и не будет. Когда мы даем такие обещания, в глубине души мы знаем, что безбожно врем. Это не лечится. Как у наркоманов, выход здесь один (не считая летального исхода).

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

  1. Выбирая язык программирования, мы сразу же столкнемся с противоречием. Хотя теоретически на любом языке можно создать программу, которая задействует все преимущества ОС, уж слишком часто приходится слышать: “Эй, парень, если ты пишешь на C++, то не сможешь использовать автоматическое управление памятью”. Хотелось бы, чтобы выбор языка определялся тем, насколько он хорошо подходит для реализации прикладной области, а не соответствиям возможности системы - хватит нам граждан второго сорта!
  2. После выхода в 1993 г. Технологии COM разработчики ПО для Microsoft Windows поняли, что им больше не надо писать весь код приложения "с нуля". COM позволяет клиенту вызывать функции сервера на уровне двоичного кода, не требуя компиляции исходного текста. Как и в случае большинства архитектур ПО, с помощью COM удалось в определенной мере облегчить ситуацию. Но теперь ее внутренняя структура из вспомогательного фактора превратилась в источник затруднений. У COM две главные проблемы: во-первых, она требует от приложения развитой инфраструктуры, например фабрик классов и преобразователей интерфейсов. В каждой среде разработки эти механизмы реализованы по-своему, поэтому они несколько отличаются и не настолько совместимы, как хотелось бы. Во-вторых, отличия между реализациями интерфейсов COM коварны и трудно согласуемы. Например, в C++ строки реализованы иначе, чем в Microsoft Visual Basic. При передаче строки от сервера COM, написанного на Visual Basic, клиенту, написанному на C++, кто-то должен сглаживать эти отличия. У программистов уходит куча времени на устранение отличий в реализации. Необходимо сгладить эти различия, допуская более тесное взаимодействие приложений.
  3. Утечки памяти сегодня - одна из самых существенных причин сбоев программ, особенно тех, что, работают в течение долгого времени. Случается, программист выделяет в ОС блок памяти с намерением освободить его позже, но забывает это сделать и выделяет следующий блок. Тогда говорят, что произошла “утечка” блока памяти, поскольку в дальнейшем его уже не используешь. Если приложение работает долго, “утечки” накапливаются, и ему не хватает памяти.
  4. Ни один продукт не достигает совершенства к моменту начала поставок. (Знаю, знаю: ваши достигают, но согласитесь, что все остальные - нет, да? Кроме того, как без обновлений получить деньги за уже проданное ПО?) Спустя некоторое время после выхода первой версии вы начинаете поставлять обновленную версию продукта с новыми функциями и исправлениями ошибок в старых. После этого начинается веселье: не важно, сколько усилий вы затратили на поддержку преемственности нового выпуска со всеми старыми клиентами, на деле это осуществить очень трудно и практически невозможно испытать. Как было бы здорово иметь механизм, используя который, серверы публиковали бы сведения о версии их ПО. Было бы не плохо, если б эти механизмы позволяли клиентам читать сведения о версиях ПО всех доступных серверов и выбрать совместимый или, при отсутствии такового, точно определить отсутствующие компоненты.
  5. Благодаря таким методикам, как классы и наследование, ООП проникло в мир разработки ПО. Программы, сложность которых превышает определенный не слишком высокий уровень, можно создавать по этим методикам. К сожалению, все языки поддерживают очень разные сочетания функций ООП, которые в силу естественных причин несовместимы. Это значит, что взаимодействие различных языков возможно лишь на очень низком уровне абстрагирования. Хотелось бы, чтобы функции ООП были доступны не только в каждом языке, но и чтобы функции ООП одного языка были доступны в другом.
  6. Web очень быстро становится для пользователей главным средством получения ПО, что ведет к возникновению серьезных проблем в области безопасности. Хотелось бы, чтобы в нашем распоряжении был какой-то механизм, позволяющий устанавливать для различных программ разрешенные и запрещенные действия, а ОС могла бы реализовывать эти ограничения. Скажем, только что загруженной программе можно было бы разрешить чтение файлов, но запретить запись.
  7. По мере роста ОС Windows стала невообразимо большой. Будучи вначале скромным сервером игры "Пасьянс" с парой сотен функций, она выросла в чудовищный сервер "Свободной ячейки", у которого более 5000 функций. Нужную функцию просто невозможно отыскать в алфавитном списке - на это уходит слишком много времени. Программисты управляют сложными проектами, организуя ПО в логические объекты. Чтобы получить хоть какой-то шанс найти нужную функцию, нужен аналогичный способ организации функций ОС в логически связанные группы.

.NET Framework - это продукт для ОС, созданных Microsoft, который представляет готовые решения для перечисленных проблем при программировании. Ключевым понятием этой платформы является управляемый код (managed code). Управляемый код работает в среде CLR (Common Language Runtime), которая поддерживает более богатый набор служб, чем стандартная ОС Win32. Любой инструмент разработки, совместимый с CLR, компилирует свой исходный текст в программы на стандартном языке Microsoft Intermediate Language (MSIL или, для краткости, IL). Поскольку независимо от языка исходного текста все инструменты разработки выдают программы на одном и том же языке - IL, все различия в их реализации исчезают к моменту достижения CLR. Код на IL, созданный инструментом разработки, не может сразу работать ни на каком компьютере. Для этого требуется следующий шаг - компиляция по требованию (just-in-time, JIT). Утилита компилятор по требованию (just-in-time-compiler или JITter) читает исходный текст на IL и производит настоящий машинный код, способный работать на данной платформе.

Вот наверное и все, что я хотел рассказать вам сегодня.
С уважением Олег msdotnet@mail.ru.

http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное