основи технології

ЗМІСТ

Сторінка 1 з 6

Платформа .NET вирішує багато проблем, які дошкуляли програмістам в минулому. До їх числа відносяться проблеми, пов'язані з розгортанням додатків, управлінням версіями, витоком пам'яті, а також проблеми безпеки. Платформа .NET дозволяє розробляти потужні, незалежні від мови програмування, настільні додатки і масштабовані (розгортаються) Web-служби, побудовані на базі нової потужної повнофункціональної бібліотеки класів .NET Framework.

Проблеми, пов'язані з розробкою 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 я б не став.

додатки майбутнього

Навіть якби платформа .NET змогла усунути всі проблеми минулого, цього все одно було б недостатньо. Постійне зростання вимог з боку клієнтів до функціональних можливостей додатків є одним з непорушних законів програмування.
Можливість безперешкодної роботи додатків в різних комп'ютерних мережах, обумовлена ​​розвитком Internet, стала імперативом. Функціональні можливості компонентів повинні бути доступні також і з інших машин. При цьому ніхто з програмістів не хоче писати базовий каркас; всі вони жадають писати програми, призначені для безпосереднього вирішення проблем своїх клієнтів.

Друга частина описує всі керуючі переваги, які додаток може отримати від COM +. Ця частина містить подробиці про поліпшення доступності та стабільності за допомогою COM + і про те, кого треба відстежувати і як використовувати дані спостереження для швидкого і легкого виявлення джерел проб.

• Завантажити приклад 1 (C #) - 7.35 КБ • Завантажити приклад 1 (VB.NET) - 12.57 Кб • Завантажити приклад 2 (C #) - 15.14 Кб • Завантажити приклад 2 (VB.NET) - 16.38 Кб Введення У проекті для останнього замовника довелося реалізувати свого роду "програму швидкого замовлення" для компанії-виробника машин. Метою цього п.

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

• Завантажити виконавчі DLL прикладів програм - signatures_binary.zip - 16.07 Кб • Завантажити вихідний код прикладів програм - signatures_source.zip - 6.14 KB Зміст 1. сигнатури (продовження) 1.1 LocalVarSig 1.2 CustomAttrib 1.3 MethodSpec 1.4 TypeSpec 1.5 MarshalSpec 2. Елементи.