Створення комерційних додатків на Microsoft Access., MS Office, Програмні керівництва, статті

У статті розглянуті способи створення і розповсюдження програм, розроблених в середовищі Microsoft Access. Стаття написана на підставі семирічного досвіду розробки на Access VBA (версії 97-2002) автором особисто, а також співробітниками Консультаційної групи Воронов і Максимов.



Введення


У багатьох розробників програмного забезпечення (як початківців, так і досвідчених) є стійке упередження до Microsoft Access як до засобу розробки професійних програмних продуктів. Спробую описати стандартні причини виникнення цього, з дозволу сказати, омани.



Access, як система управління базами даних, позиціонується як засіб управління даними кінцевим користувачем без залучення програміста. Це безумовно є плюсом Access як програми, але веде до активного неприйняття його IT-професіоналами.


В наслідок вищевикладеного, програми на Access / VBA намагаються писати люди, які не мають достатнього досвіду і досвіду програмування. Такі розробки навіть поширюються на комерційній основі, а також викладаються для вільного доступу в інтернеті. Професійний програміст жахається при ознайомленні з кодом таких «програм» і поширює свою думку на засіб розробки.


Так звана «література для чайників» тільки посилює враження про Access як несерйозною системі. Викладання розробки баз даних в ВУЗах часто також засновано на подібних книгах і посібниках.


Зіткнувшись в перший раз з необхідністю написання власної програми на Access, професіонал об’єктно-орієнтованого програмування (C + +, Delphi) часто не знає з якого боку підійти до процесу розробки, так як Visual Basic for Application пропонує своєрідний набір засобів роботи з класами. Тут необхідно зауважити, що програмісту, який попередньо глибоко вивчив COM-програмування Windows буде набагато легше зрозуміти способи взаємодії класів, посилань і т.п.


Access пропонує абсолютно нестандартний по відношенню до поширених засобів розробки підхід до програмування користувальницького інтерфейсу (форми, звіти). Це може викликати труднощі для розуміння навіть для досвідчених програмістів, і навіть розробників на родинному мовою Visual Basic. Основоположний момент тут – це те, що елементи управління (контролю) Access не є Windows-контролем і не мають контексту вікна (hWnd). Хоча ці контроли і виглядають як стандартні, а також мають набори властивості і подій, по суті вони є просто картинки, прорисовуємо додатком на формі. Також нетрадиційний підхід реалізований для списків і форм з даними. Контроли, а також сама форма, завжди має джерело даних, який може налаштовуватися динамічно без створення додаткових компонентів. Найчастіше, не розібравшись в подібних особливості мови і середовища розробки, програмісти посилаються на «неправильність» всієї системи.


Також багато хто звинувачує Access в недостатній захищеності програм і даних від несанкціонованого доступу. Мабуть, це єдиний момент з яким можна погодитися. Тобто, правильніше сказати, що для забезпечення захисту даних можуть знадобитися додаткові дії, які в принципі не потрібні при використання інших систем розробки. Детальніше на цю тему – див главу «Обмеження».


З іншого боку, я згоден з тим, що спочатку Access призначався для створення локальних додатків і не був повною мірою засобом розробки комерційних програмних продуктів. Той хто працював з Access 2.0, я думаю, підтвердить, що з точки зору програміста система була дуже незручною. На захист можу сказати лише те, що предок сучасного Delphi, версії 1.0 – мені довелося з ним працювати – Теж був далекий від ідеалу. Можливості поточних версій Access (версії 2000 і далі) настільки зросли, що на ньому цілком можна створювати дуже складні програми як локального характеру, так і тиражовані системи.


Опис деяких наведених у статті рішень передбачає наявність спеціальної версії для розробника Microsoft Access: для версії Office 97 – це Access Developer’s Toolkit (ADT), для більш пізніх версій – Office Developer’s Edition (ODE).


Далі в статті описані необхідні, на мій погляд, дії по створенню професійної програми на Microsoft Access. Хотілося б лише зауважити, що дані рекомендації не є яким-небудь стандартом, це скоріше набір правил, яким би хотілося дотримуватися при розробці власних додатків.


Розробка розповсюджуваного програми



Розробка бази даних


Тут необхідно вирішити питання з вибором сховища даних і способом доступу до цих даних. Access пропонує достатній вибір: Jet / DAO, ODBC, ADO. На жаль, немає можливості зупинятися докладно на цьому важливому питанні в даній статті. Варто хіба що відзначити, що стратегія розвитку Microsoft Access йде шляхом витіснення власного сховища (MDB) серверними джерелами даних (SQL-сервер).


Головне питання, незалежно від сховища – це структура бази даних. Процеси нормалізації структури даних (як, до речі, і зворотного денормолізаціі) безумовно можуть проводитися і в процесі розробки програми, але бажано спочатку мати стійке ядро ​​бази даних, до якого можуть прив’язуватися нові структури і інтерфейси користувача.


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



Розробка концепції інтерфейсу користувача


При розробці інтерфейсу користувача настійно рекомендується обмежитися використанням стандартних засобів інтерфейсу Windows (меню, панелі інструментів, майстри, повідомлення). Власні «красивості» можуть виглядати привабливо з вашої точки зору, але будуть інтуїтивно незрозумілі кінцевому користувачеві.


Структура форм і звітів по можливості повинна бути єдиною. Наприклад, всі форми для редагування даних мають «стрічковий» тип і стандартну колірну палітру, заголовок містить набір фільтрів, кнопки управління розташовуються в лівому нижньому кутку.



Поділ інтерфейсу і бази даних


Про це йдеться практично в будь-якій книзі або статті з програмування в Access для початківців. Просто додам, що повне відділення інтерфейсу може викликати деякі труднощі при роботі з MDB / MDE. Безумовно загальні дані повинні бути перенесені на сервер (файл або SQL). Але все-таки недоцільно тримати тимчасові таблиці (якщо такі використовуються) в додатковому локальному MDB-файлі. Тим більше що це, на жаль, не призводить до стабілізації розміру основного файлу інтерфейсу (все одно потрібно регулярне стиснення).



Групова розробка


Access цілком підходить для розробки програми кількома програмістами, попри те, що робочий проект (MDB або ADP) являє собою єдиний файл. Категорично не можна використовувати спільний доступ до робочого файлу інтерфейсу – це призведе до пошкодження самого проекту. Але Access містить спеціальні методи збереження і відновлення об’єктів програми в текстовому вигляді (Application.LoadFromText, Application.SaveAsText). На жаль, з незрозумілих мені причин розробники не включили можливості складання проекту з модулів в середу розробки. Але при наявності деякого досвіду ви можете написати власну надбудову по висновку проекту в текстовий вигляд і подальшого відновлення (розроблена в нашій компанії надбудова дозволяє перетворювати в текстові файли всі можливі об’єкти Access: форми, модулі, звіти, запити, таблиці з даними, посилання, панелі інструментів). Це потрібно для підтримки популярних програм групової розробки додатків (CVS, SourceSafe, TortoiseSVN). Включається до ODE-версію Access програма SourceSafe за ідеєю мала б підтримувати таку операцію автоматично, але нам не вдалося знайти таку опцію (буду радий помилитися, якщо вона там таки є).



Документація


Пишіть по можливості код, який не вимагає додаткового пояснення. Це може здатися дивним для багатьох, але одна з сучасних концепцій програмування передбачає практично повну відсутність коментарів у тексті процедур і функцій. Програмні ідентифікатори повинні самі себе описувати – використовуйте короткі процедури, що «говорять» імена класів, функцій, таблиць, полів, не економте на довжині ідентифікаторів.


Що може зажадати додаткових коментарів і навіть окремої документації, так це структура бази даних. Існує безліч систем для моделювання структур даних і бізнес-процесів (ErWin, Power Designer). Мінімально необхідні дії з оформлення структури даних можна виконати за допомогою власних діаграм даних Access або SQL-сервера.


Спеціальні засоби



Спадкування інтерфейсів


Про неможливість «нормального» спадкування в класах Visual Basic може повідати будь-який програміст, вихований на класичних об’єктно-орієнтованих мовах програмування. Не буду нікого переконувати – Навіть швидше погоджуся з цим твердженням. Судячи по напрямку розвитку засобів розробки від Microsoft, в наступних версіях Access цю прогалину таки буде усунутий. Тим не менш, навіть в поточній версії можна (і треба) використовувати можливості ООП VBA по максимуму. Постарайтеся зрозуміти можливості спадкування інтерфейсів. Ця особливість мови можливо і не додасть очікуваної функціональності спадкування, але зробить код програми більш наочним, зрозумілим, простим для розвитку та перенесення на іншу платформу.



Шаблони коду


VBA не підтримує спеціальної функціональності шаблонів класів або що-небудь подібного. Під шаблоном коду, я тут маю на увазі, стандартний набір описів, процедур і функцій, потрібних в декількох модулях програми. Це може бути набір стандартних обробників подій для робочих форм, або, наприклад, код з організації форм-майстрів. Такі шаблони можуть бути розроблені як попередньо, так і в процесі розробки. Не бійтеся повторювати такий однаковий код в декількох місцях програми – такий код виглядає наочніше, зрозуміліше і простіше для тестування і внесення спеціальних змін, ніж виклики глобальні функцій і процедур. Оновлення шаблону також не є трудомісткою операцією. У багатьох випадках шаблони коду має сенс поєднувати з успадкуванням інтерфейсів.



Екземпляри форм


Access дозволяє працювати з декількома екземплярами однієї й тієї ж форми або звіту. З незрозумілих мені причин в документації та прикладах Microsoft рекомендує використовувати традиційний спосіб відкриття форм (через команду DoCmd.OpenForm). З досвіду роботи ми не знайшли будь-яких прихованих помилок при використанні примірників форм, при тому що це додає значно більше можливостей з програмування інтерфейсу і робить його більш сучасним і зручним кінцевому користувачеві.



Тимчасові таблиці і запити


Цей пункт включений в перелік тільки для того, щоб звернути увагу на особливості роботи з тимчасовими таблицями і запитами при використанні примірників форм і звітів. Якщо які-небудь форма заснована на тимчасовій таблиці, то потрібно створювати окрему копію такої таблиці для використання в екземплярах форми. В цьому випадку має сенс розробити генератор тимчасових таблиць і запитів.



Обробка власних подій


Орієнтація на події є великим кроком вперед у розвитку програмних систем. Програми Access також можна змусити обробляти ваші власні події, причому без залучення функціональності сабклассінга і Windows API. Події в цьому випадку є об’єкт класу і обробляються спеціальними прихованими формами (процесорами), завантажуваними при старті програми. Через події можна передавати результати з модальних вікон, контекстно оновлювати списки на всіх відкритих робочих формах, запускати серверні процедури в асинхронному режимі і т.п. Таким чином, можна практично позбавитися від використання глобальних змінних. Крім того, VBA надає спеціальну функціональність для взаємодії класів через події (див. довідку по WithEvents і RaiseEvent).



Умовна компіляція


Це потужний засіб, що дозволяє тиражувати програмні модулі в різні проекти при незначній зміні функціональності (див. довідку по #If). Хотілося б тільки звернути увагу, що умовна компіляція має сенс тільки при додаванні умови безпосередньо у властивості проекту VBA (меню Tools Properties). При використанні ключового слова #Const більшість корисних властивостей умовної компіляції втрачається, тому що така константа має область видимості тільки на рівні модуля.



Надбудови


Може виявитися корисним винести деяку функціональність програми в окремий файл надбудови. Access підтримує три типи надбудов: окремий файл, інсталюються надбудови (потребують USysRegTable) І COM-надбудови. Надбудова у вигляді окремого файлу повинна бути встановлена ​​в той же каталог, що й файл msaccess.exe. В цьому випадку не потрібно встановлювати зв’язок з цим файлом на рівні колекції References. Дуже корисно при програмуванні надбудов використовувати опис Friend для властивостей і методів класів – в звичайному проекті Access це опис не відрізняється від Public. Інстальована і COM-надбудови в основному призначаються для полегшення процесу розробки і можуть бути безкорисними кінцевому користувачеві програми (користувач може взагалі не мати стандартну версію Access).



Сабклассінг


Намагайтеся обійтися без використання сабклассінга (перевизначення головної функції вікна). Особливо це стосується головного вікна програми. При виникненні будь необробленої помилки додаток закриється з системним сполученням Access (можливо після цього буде проведена спроба відновлення бази даних), що виглядає для користувача лякаюче. Взагалі хорошим стилем є можливість відновлення значень глобальних змінних і перезавантаження прихованих форм при виникненні будь-якої критичної помилки в програмі.


Створення runtime програми



Перетворення інтерфейсу в MDE (ADE)


Для розповсюдження програми із закритим програмним кодом використовується перетворення файлу проекту у формат MDE або ADE. Відповідно не використовуйте в коді програм операції неприпустимі в MDE-файлі. Дуже акуратно використовуйте посилання (References), в MDE-файлі встановити їх програмним способом не вдасться. Крім того, з власного досвіду роботи, Access не завжди коректно відновлює посилання на бібліотечні файли різних версій. Зокрема через проблеми з роботою під різними версіями Microsoft Office, в розробках нашої компанії не використовується посилання на бібліотеку Microsoft Excel Object Library. Замість цього в усіх операціях обміну даними з Excel використовується тип Object і пізніше зв’язування (CreateObject(“Excel.Application”)). Будьте впевнені, що програма установки вашого застосування розмістить бібліотечні файли (ActiveX, DLL, надбудови) саме в тих папках (за типами: системна, програмна, OfficeLibrary і т.п.), куди посилався основний файл проекту перед перетворенням в MDE / ADE.



Access Run-time


ODE версія включає в себе програму для підготовки настановного пакету (Package Wizard), в який може бути включена run-time версія Microsoft Access. Ця програма поширюється разом з кінцевим додатком Access за ліцензією ODE і дозволяє запускати файли користувачам, які не мають встановленого пакета Microsoft Office Professional. Run-time версія Access – це набір виконуваних і бібліотечних файлів, причому деякі абсолютно ідентичні звичайної версії Access (наприклад, msaccess.exe), інші відрізняються і за змістом, і за назвами (msoX.dll і msoXrt.dll). Встановити Run-time версію вручну досить складно. Починаючи з версії 2002 Package Wizard формує окремий msi файл Access Run-time для установки за допомогою WindowsInstaller’a. Для попередніх версій run-time версія також була доступна у вигляді звичайного setup-файла. Run-time версія дещо відрізняється від стандартної: зокрема відсутній вікно бази даних, не доступні ніякі засоби редагування проектів, немає стандартних панелей інструментів. Я ніколи також не чув про локалізованих run-time версіях Access (ODE не поширюється з російською локалізацією). Будьте готові до того, що всі системні повідомлення треба або замінювати, або змиритися з тим що вони будуть виводитися на англійській мові (наприклад, текст в рядку стану).



Тестування додатків в Run-time


Тестування готових програм необхідно виробляти саме в run-time версії. Для цього швидше за все знадобиться окремий комп’ютер без встановлених офісних програм. Командний рядок Access пропонує використання опції «/ runtime» для тестування додатків. Не користуйтеся цією можливістю, оскільки поведінка програми та результати роботи в цій run-time версії можуть відрізнятися! Додаткова інформація по ODE для Access 97 доступна за адресою faqs.org.ru/progr/database/ode.htm


Стандарти для клієнтських додатків


Тут перераховані стандартні інтерфейсні засоби, що робить клієнтське додаток дружнім користувачеві.



Заставка


Додаток повинен мати заставку з назвою програми, авторський копірайт і рік (дату) випуску, номер версії. Якщо програма має систему реєстрації, то повинна бути виведена інформація про зареєстроване користувача і тип ліцензії. Інформація про авторів повинна бути також доступна через меню та довідкову систему.



Іконка для вікон


Щоб максимально приховати походження програми і засіб її розробки, має сенс замінити іконки для форм і звітів програми. Для цього можна скористатися властивостями запуску в меню Access, або налаштовувати іконку через виклик API-функцій при відкритті вікна.



Меню, панелі інструментів


Використовуйте всі можливості (не дуже, до речі, багаті) для розробки дружнього інтерфейсу користувача. Замініть стандартне меню на власне, розробіть панелі інструментів і контекстні меню.



Довідкова система


Розробка довідкової системи та комплекту користувача документації справу безумовно непросте, але обов’язкове. Контекстний виклик довідки можна налаштувати через виклики функцій бібліотеки “hhctrl.ocx” (HTMLHelpStdCall).
Компілятор help-файлів входить до складу ODE.



Засоби адміністрування бази даних


Включіть до складу пакета програми засоби обслуговування бази даних і інтерфейсного файлу. Це можуть бути найпростіші програми з резервного копіювання, відновлення, стиснення бази даних і інтерфейсного файлу.


Створення програми установки для закінчених додатків



Програма установки


Програма створення настановних пакетів Package Wizard, що входить до складу ODE, здатна зробити setup-файл для вашого додатку. Але за всіма відгуками і з власного досвіду можливості і результат роботи цієї програми абсолютно не ті, що хотілося б побачити. Ця програма (версії ODE2002) не підтримує російських налаштувань Windows, не дозволяє налаштувати алгоритм установки, і навіть відмовляється створювати архів на диску з файловою системою NTFS! Таким чином, настійно не рекомендується використовувати цю програму для поширення власних додатків. Головне що можна взяти після роботи Package Wizard, це msi-файли для Access Run-time і Microsoft Desktop Engine. Розробити програму установки можна у будь-інсталяційної системі, наприклад, InstallShield, Wise. У цьому випадку буде потрібно налаштувати ці програми для виклику msi-архівів з командного рядка. Іноземні розробники дуже рекомендують програму SageKey, спеціально налаштовану для роботи з додатками Access. Наша компанія використовує вільно поширювану програму InnoSetup (www.jrsoftware.org/).



Створення ярлика для запуску програми


Використовуючи будь-яку програму установки не забувайте вказувати повний шлях запуску в ярлику програми, наприклад: ‘C: Program FilesMicrosoft OfficeOfficemsaccess.exe’ ‘C: MyProgramMyProgram.mde’ / wrkgrp ‘C: MyProgramMySystem.mdw’.



Оновлення


При поставці багатокористувацької версії програми має сенс подумати про метод установки оновлень з єдиного сервера. Програма (і можливо база даних) повинна зберігати номер поточної версії (у власному коді або в зовнішньому файлі на комп’ютері користувача) і перевіряти при запуску наявність поновлення на сервері. Аналогічним чином можна організувати процедуру стиснення інтерфейсу, автоматично перевіряючи розміру виконуваного файлу.


Обмеження


Тут описані причини, які можуть послужити для відмови від Access при виборі засобу розробки.



Несанкціонований доступ


На жаль, додаток Access практично неможливо захистити від несанкціонованого доступу до даних «хакерськими» методами. В інтернеті отримали широке поширення програми для злому паролів файлів робочих груп і баз даних.


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


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


З власного досвіду в 9 випадках з 10 не потрібно глобальна система захисту додатків від «хакерських» атак. Крім того, збитки від невірних дій користувачів з санкціонованим доступом можуть бути навіть вище, так як призводять до прихованих помилок. Проте забезпечити мінімально необхідний рівень захисту даних безумовно необхідно. Далі наведено перелік дій для забезпечення такого рівня безпеки:



  1. Налаштування опцій запуску («захист від Shift»).
  2. Налаштування прав на об’єкти на рівні сервера та / або файла робочих груп.
  3. Забезпечення входу в додаток тільки з зазначенням пароля.
  4. Підключення при вході і відключення при виході лінковані таблиць в проектах MDB / MDE.
  5. Налаштування автоматичних процедур резервного копіювання даних на сервері.
  6. Ведення журналів зміни критичних даних.

Рекомендується створювати окремий файл робочої групи (спочатку скопіювавши system.mdw), потім запускати додаток через використання опції командою рядка «/ wrkgrp».


Взагалі-то в розробках нашої компанії не використовується розмежування доступу через стандартні функції робочої групи Access. З багатьох причин довелося розробити власний модуль настройки користувачів і груп. Тому оцінити роботу зі стандартною системою розмежування доступу до об’єктів і даних я, на жаль, не можу. Детальніше про безпеку і розмежування доступу – см. am.rusimport.ru/MSAccess/topic.aspx?ID=469



Приховані помилки Access


Як і будь-яка система розробки, Access, містить помилки у власній програмної реалізації. Їх кількість зростає або скорочується у зв’язку з випуском різних версій і сервіс-паків. Незважаючи на наявність таких помилок і недоробок, в цілому Access при коректному використанні досить стійка система. А кількість непереборних або непояснених помилок взагалі надзвичайно мало. У 99% так звані «помилки» Access насправді пов’язані з неправильним алгоритмом або програмним кодом.


У наших розробках виникали такі складні для усунення проблеми:



Повне руйнування mdb-проекту без можливості відновлення при імпорті об’єктів без подальшої компіляції. Вирішується резервним копіюванням і збереженням об’єктів в текстовому вигляді.

Втрата посилань при використанні бібліотек різних версій. Вирішується через використання типу Object і пізніше зв’язування.

Помилки при роботі з ActiveX. Наприклад, невірні дані ієрархії листя TreeView, якщо дерево не відображається в даний момент на формі. Тут у кожному випадку треба розбиратися окремо.

Втрата пункту користувацького меню. Вирішується через програмне створення меню і панелей інструментів.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*