Architecture Net или что такое Microsoft.NET?
Проблемы, связанные с разработкой Windows-приложений
Представьте себе симфонический
оркестр, в котором группам струнных
смычковых и ударных инструментов предстоит
исполнить свои партии, используя при этом
разные варианты партитуры. В таком случае,
чтобы исполнить даже простейшую
музыкальную композицию, музыкантам
пришлось бы приложить героические усилия.
Этот пример достаточно хорошо иллюстрирует
деятельность разработчиков Windows-приложений.
В процессе работы перед разработчиком
возникает целый ряд вопросов. Использовать
ли в приложении классы библиотеки базовых
классов Microsoft (Microsoft Foundation Classes — MFC)? На каком
языке писать приложение, на Visual Basic или на C++? Какой интерфейс для работы с базами данных использовать в приложении: открытый интерфейс взаимодействия с базами данных (Open Database Connectivity Interface — ODBC) или интерфейс OLE для баз данных, OLEDB? Использовать в приложении интерфейс модели компонентных объектов Microsoft (Component Object Model — COM) или интерфейс прикладного программирования (API) в стиле языка С? Если выбор сделан в пользу интерфейса модели компонентных объектов Microsoft (COM), какой тогда интерфейс использовать: IDispatch, дуальный (двойственный) интерфейс или только интерфейс с виртуальной таблицей? Какая роль во всем этом отводится Internet? До тех пор пока не появилась платформа .NET, довольно часто проект приложения искажался используемыми в процессе его реализации технологиями, которыми в тот период времени владели разработчики. Или же разработчику приходилось изучать еще одну технологию, которой было суждено через пару лет быть вытесненной следующей.
Развертывание приложения может оказаться трудной и неприятной задачей. В процессе развертывания приложения должны быть сделаны соответствующие записи в системном реестре, который является достаточно хрупким, а его восстановление — нелегкий труд. К тому же не существует хорошей стратегии управления версиями компонентов. Новые версии приложений могут разрушить уже существующие программы и при этом остается лишь догадываться о том, что же собственно произошло. Чтобы избежать проблем, связанных с хранением сведений о конфигурации системы в системном реестре, в других технологиях для этой цели используются метабазы или сервер SQL Server.
Еще одной проблемой в Win32 является безопасность. Существующая модель безопасности тяжела для понимания. Еще более тяжело ее использовать на практике. Многие разработчики просто ее игнорируют. Разработчики, которые были вынуждены использовать существующую систему безопасности, пытались в этой трудной модели программирования делать все от них зависящее. Возрастающее значение безопасности, связанное с развитием Internet, грозит изменить плохую ситуацию на потенциальный кошмар.
Даже там, где компания Microsoft попыталась облегчить процесс разработки приложений, проблемы все еще оставались. Многие системные службы приходилось разрабатывать с самого начала, по существу создавая инфраструктуру приложения, которая имела мало общего с бизнес-логикой. Гигантским шагом в сторону создания служб более высокого уровня стали сервер транзакций корпорации Microsoft (Microsoft Transaction Server, MTS) и COM+. Тем не менее, потребовалась еще одна парадигма разработки приложений. Модель компонентных объектов Microsoft (Component Object Model — COM) сделала возможным настоящее программирование с использованием компонентов. При этом приложение можно было создать достаточно просто с помощью языка Visual Basic. Но такие приложения не обладали достаточной гибкостью. Значительно более мощные приложения можно было создать с помощью языка C++, но при этом нужно было приложить значительные усилия. И это не говоря уже о том, что на языке C++ приходилось постоянно писать (постоянно воссоздавать) повторяющийся каркас (инфраструктуру) приложения. Если бы от этого всего можно было избавиться, скучать за ILJnknown я бы не стал.
