4.14.2. Достоинства и недостатки .Net.

Объектно-ориентированное программирование

Старый Windows API был написан на С и, следовательно, является полностью процедурным.

Это означает, что API состоит буквально из тысяч функций. Напротив, .NET и С# пол­ностью основаны на принципах ООП. В частности, библиотека .NET является библиоте­кой классов, а не функций. Можно создавать экземпляры этих классов и во многих случаях производить наследование классов, а также вызывать их общие методы. Это по­зволяет создавать интуитивно понятный, хорошо структурированный и более надежный клиентский код, что невозможно сделать с помощью Windows API.

Хороший дизайн

Мнение о том, что является хорошим дизайном, субъективно, однако Microsoft в течение долгого времени обсуждала с разработчиками самые разные вопросы по поводу .NET и извлекла уроки из ошибок прошлого. В результате появилась библиотека базовых клас­сов, которая разработана с чистого листа и сделана интуитивно понятной. В подавляю­щем большинстве случаев достаточно всего лишь взглянуть на определение метода, чтобы понять, что он делает и как его использовать. Безусловно, такого нельзя сказать о Windows API, функции которого не всегда понятны и зачастую требуют передачи пара­метров, которые необходимы для запутанной внутренней работы API или обеспечения обратной совместимости, а не для выполнения цели данной функции.

Языковая независимость

Хотя раньше СОМ-компоненты могли общаться друг с другом независимо от того, на ка­ком языке они написаны, все же существовала большая пропасть между Visual Basic, Visu­al J++ _и Visual C++. Типы данных различались, и создание СОМ-объекта, который должен быть доступен из других языков, означало наложение жестких ограничений на сигнату­ры его методов, часто за счет ограничения производительности. И, конечно же, невоз­можно было смешивать различные языки а одном и том же блоке кода.

Теперь все изменилось. С применением платформы .NET любой язык, включая VB.NET, С# и управляемый C++, может компилироваться в общий промежуточный язык. Это означает, что языки совместимы на совершенно новом уровне. Например, в отлад­чике можно перешагивать с кода C++ прямо на код С#, а затем на код VB.NET без ка­ких-либо проблем. Более того, все языки используют теперь общую среду разработки.

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

Напротив, Microsoft осуществила этот переход путем добавления в каждый язык тех свойств, которые превосходно показали себя в других языках. VB.NET теперь содержит классы и наследование, ранее являвшиеся прерогативой C++. Если для программирова­ния используется C++, то среда разработки поддерживает элементы управления drag-and-drop точно так же, как это было реализовано в VB. Тем не менее некоторые особенности языка C++, такие как множественное наследование и шаблоны, не поддерживаются в .NET и, следовательно, не могут использоваться в управляемом коде.

Отказ от применения DLL

Когда было объявлено о создании DLL (dynamic linked libraries), это было большим до­стижением по части экономии дискового пространства и памяти и позволяло различным процессам совместно использовать один и тот же код. Однако по мере работы с DLL ста­ло понятно, что их применение приводит к появлению ряда проблем, в основном из-за отсутствия какой-либо формальной системы контроля над версиями и из-за того, что бо­лее новая версия DLL, как правило, затирает собой предыдущую версию.

Проблема в большинстве случаев заключается в том, что некоторое программное обеспечение перезаписывает разделяемую DLL новой версией. Обновленная версия оказывается не полностью совместимой с предыдущей, в результате чего обнаруживает­ся, что некоторые программы, использующие ту же DLL, больше не работают на данной машине. Такие ошибки трудно отыскать. Платформа .NET лишена этого недостатка. .NET полностью изменила способ, с помощью которого код совместно используется приложениями, введя концепцию сборки (assembly), заменившей традиционную DLL. Сборки имеют встроенные средства контроля версий, а разные версии сборок могут со­существовать одновременно.

Улучшенная безопасность

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

Простая установка (Zero Impact Installation)

Начиная с Windows 95, СОМ-объекты должны регистрироваться в реестре. Эта практика является хорошей в плане обеспечения централизованной информации о том, какие программы установлены в системе. Однако в результате использования системой СОМ-объектов библиотек типов появляются дополнительные проблемы из-за того, что информация о приложении хранится в разных местах. Например, код, который пред­ставляет собой компонент, может находиться в файле ЕХЕ или DLL, описания методов и интерфейсов будут храниться где-то еще в библиотеке типов, a GUID и т.п. будут описаны в реестре.

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

В то же время различные эффективные и сложные алгоритмы хэширования обеспе­чивают во время выполнения проверку того, что сборка не была модифицирована. Мож­но также различать общие сборки, доступные для других приложений, и частные сборки, которые могут использоваться только тем приложением, которое их установи­ло. Это решает еще одну проблему СОМ — проблему того, что реестр постепенно забива­ется информацией о тысячах компонентов, которые на самом деле не предназначены для совместного использования.

Поддержка web-служб

Web-службы, по мнению многих людей из ИТ-индустрии, являются тем, что будет иметь большое значение в течение следующих нескольких лет. Идея состоит в том, что различ­ные методы объекта могут быть вызваны по Интернету при помощи стандартных web-протоколов. Это придает новый смысл технологии распределенных приложений: различные компании смогут предоставлять такие услуги, как прогнозы погоды, состоя­ния счетов и проверки кредитных карт, с помощью этих методов, а клиенты смогут вы­зывать их по Интернету с помощью собственного программного обеспечения. Вплоть до настоящего времени Microsoft обеспечивала ограниченную поддержку web-служб посред­ством инструментария SOAP. .NET имеет полностью встроенную поддержку разработки web-служб, и создавать их теперь так же легко, как и любые другие типы приложений.