Кращі практики для переміщення великого додатка MS Access до .Net?

У нас дійсно величезний додаток MS Access, розроблений власним чином для наших особистих потреб, який потім перетворився на комерційне програмне забезпечення та успішно продається. Програмне забезпечення є свого роду "всебічним програмним забезпеченням для вашого бізнесу" і містить декілька модулів, включаючи систему управління документами, планування ресурсів підприємства, управління запасами, управління взаємовідносинами з клієнтами, аналіз даних тощо. Ми дуже задоволені сучасним функціональність програми, але для задоволення запитів наших клієнтів ми розуміємо, що нам потрібно перейти до чогось нового.

Ми вирішили поступово перенести наш додаток у бік .Net, оскільки ми можемо дотримуватися Visual Basic .Net: навіть якщо це нова мова для більшості розробників тут, ми глибоко знаємо VBA та кілька десятків малих проектів, реалізованих у VB6.

Ми вже почали переміщувати функціональність рівня даних нашої програми на MS SQL Server, так що кожна маніпуляція та пошук даних виконується безпосередньо на сервері.

Ми шукаємо найкращі практики для поступового переміщення нашого широкого графічного інтерфейсу (близько 500-600 різних форм, включаючи підформи, близько 200 звітів із підтримкою на декількох мовах тощо). Після нещодавнього прохання нашого потенційного клієнта впровадити асинхронне шифрування даних на документах у DMS, ми також будемо раді повністю відключити цю частину від MS Access та впровадити її в .Net.

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

Редагувати:

Ми намагалися застосувати деякі практики з книги Мартіна Фаулера « Шаблони інтеграції підприємств », щоб досягти певної інтеграції між додатком MS Access та деякими невеликими утилітами, які ми впровадили в .Net для різних потреб. Але нам вдалося лише використати шаблон "спільної бази даних", і ми не були дуже задоволені нашим рішенням.

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

В основному ми використовували ADO.NET для прямого доступу до баз даних MS Access у форматі MDB та заповнення таблиці з деякими обробленими даними (як, наприклад, дані про поштові повідомлення з наведеного вище прикладу: у нас є поля FROM, TO, CC, BCC, Предмет і тіло).

Працювати з форматом даних MDB від .Net абсолютно немає проблем , більше того, ми не хочемо залишатися з MDB і майже все переширюємо на MS SQL Server 2008 - це дає нам набагато більше свободи щодо управління даними та масштабованості.

Основна проблема тут полягає в тому, що ми не знаємо, як реалізувати своєрідний "зворотний виклик" в Access, щоб ми могли спровокувати виконання певного коду VBA під час оновлення даних.

Ми великі сподівання, що MS Access 2010 підтримує оновлення та вставляє тригери для таблиць даних , але виявилося, що ми можемо використовувати для цих тригерів лише макроси MS Access, і немає можливості виконати будь-який спеціальний код VBA в межах тригера.

Ми також спробували деякі рішення, направляючи натискання клавіш безпосередньо у вікно MS Access, щоб імітувати деякий запит даних, викликаних користувачем. Це працює, але ми не вважаємо, що це надійне рішення, яке можна використовувати у виробництві.

Ми також розглянули DDE для MS Access, але нам не вдалося знайти хорошого зразкового рішення, що реалізує команди DDE та використовує їх для обміну даними в пам'яті та обміну командами.

Отже, головна проблема полягає у тому, щоб програма MS Access та .Net співіснували та взаємодіяли між собою.

EDIT2 :

Я забув згадати, що ми також впровадили бібліотеку MSMQ у VBA для передачі повідомлень між .Net та MS Access, проблема знову була у відсутності зворотного виклику тут: нам дійсно довелося опитувати чергу на нові повідомлення та враховуючи, що VBA насправді не підтримує багатонарізка це було не дуже приємне рішення.

Це буде великий і дуже задіяний проект. Я відповідав за переміщення баз даних Access до .NET багато разів, але ніколи такого масштабу. Я згоден, що поступовий підхід, мабуть, буде найбільш реалістичним. Спроба взяти все за один кадр - це простий спосіб провалитись.

Як і в інших відповідях, першим і найважливішим кроком буде переміщення всього на SQL Server. Роблячи це, задокументуйте базу даних, якщо цього ще не зроблено, і визначте області для рефакторингу, якщо вони існують. Доступ до баз даних, що зростають для задоволення змін, що часто розвиваються, часто мають моделі даних, які можна вдосконалити при огляді великої картини.

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

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

Після того, як ви зробите перший підрозділ, подивіться, що сталося з точки зору викликів, труднощів тощо, і використовуйте цей рух уперед.

Одне, що я сильно заважаю, - це реалізувати частково працюючі модулі (наприклад: "ми перемістили CRM, але функції X, Y, Z ще не в новій системі"). Це призведе до того, що користувачі швидко засмучуються від незавершеної системи, коли стара для них була «ідеальною». Подібні розробки можуть спрацьовувати в інших областях, але не в бізнесах, де користувачі бачать "нічого поганого" зі старим монолітом Access і не розуміють міграційних потреб.

Ось такий план перетворення програми MS Access на додаток VB.Net шляхом мутації.

Це не загальний план, наступний план залежить від описаного вами проекту.

Крок 1: переміщення всіх даних на SQL Server

Не використовуйте ODBC для підключення Доступ до SQL Server, використовуйте натомість Проект доступу (ADP). Проект доступу - це файл доступу з розширенням .adp, він має повні функції доступу (макроси, форми, звіти, модулі), але з'єднання знаходиться безпосередньо в базі даних SQL Server замість файлу MDB. Файли ADP дуже сумісні з файлами MDB. Вони, схоже, не підтримуються в Access 2010, хоча насправді функція прихована, але вона дуже добре підтримується. Як і MDE, ADP-файли можна "компілювати" у файли ADE.

Перехід на SQL Server коштуватиме декількох модифікацій структури даних та коду, але все мігрувати досить просто. І це остаточна мета.

Забудьте про запуск подій бази даних до коду VBA або VB.Net. Це технічно можна зробити за допомогою розширених збережених процедур SQL Server, але це дуже поганий трюк. Ваш проект має майбутнє життя, тому краще застосувати його структуру даних, уникаючи такого типу руйнуючого моста. Взагалі, грати з пусковими механізмами бази даних, це розумно, але досить складно в обслуговуванні.

Крок 2: зробіть аутентифікацію рівномірною

Добре, що ваша програма не базується на безпеці доступу (файл MDW).

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

Оскільки автентифікація в архітектурі додатків є поперечною, це буде простіше перерізати між версією Access до версії VB.Net.

Крок 3: підготуйте функцію маркера для того, щоб зробити міст між Access і VB.Net

Ви сказали, інтерфейс доступу повинен буде відкрити інтерфейс VB.Net з деякими точними параметрами, а також аутентифікацією. І вам, мабуть, доведеться робити те саме іншим способом.

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

Якщо вам потрібен зворотний дзвінок з VB.Net для доступу (напевно, будете), я думаю, що можливо активувати якийсь код VBA у відкритому файлі доступу до MDB, використовуючи OLE.

Крок 4: міграція інтерфейсу користувача та екрана модулів за екраном, модуля за модулем

Зараз велика підготовка зроблена. Ви можете почати мігрувати інтерфейс користувача з Ms Access на VB.Net.

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

Я вражений, що ти все це зробив із Access. Є дуже важливе питання, якого ви не задаєте. NET Windows Forms або .NET WPF. WPF має більш круту криву навчання, але, на мою думку, вона є більш потужною та покращує інтерфейс користувача. Нещодавно ми перетворили нашу комерційну програму з Forms на WPF і вже отримуємо більше продажів. Ми також додали нові функції, але інтерфейс WPF просто сексуальніший. Перегляньте свій дизайн столу та почистіть його - тепер саме час. Переконайтеся, що ви оголосили всі ваші ФК. Під час доступу ви можете додавати речі на льоту досить легко, коли деякі речі прослизають. Якщо це ваш перший інтерфейс WPF, побудуйте деякі прототипи. Ми можемо більше запакувати WPF, що новий додаток має більше функцій, менше екранів і менше набагато менше коду. Ви перейдете від ненависті XAML до того, як любити це. Розглянемо таку структуру, як MVVM.

Оскільки ви вже добре розумієте модель об'єкта Access, я думаю, що ви хочете використовувати Access Interop з вашого .NET-додатка. Це повинно (більше чи менше) дозволяє автоматизувати управління додатком Access, без непрозорості DDE.

Я не знаю глибоких знань про рівень вашої бізнес-логіки, але ви також можете отримати доступ до баз даних MS Access у вашому додатку .NET. Якщо справа не лише в отриманні даних, ви можете встановити TCP / IP-з'єднання між вашими програмами (VB6 та VB.NET програми). Перегляньте статтю про CodeProject .

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

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

Ми вирішили поступово перенести наш додаток у напрямку .Net

Часто помилка. Найкраща практика - не намагатися «поступово».

незважаючи на те, що це нова мова для більшості розробників тут, ми глибоко знаємо VBA та кілька десятків малих проектів, реалізованих у VB6.

Не дуже хороша основа для прийняття рішення. Якщо ви хочете вивчити нову мову, не вивчайте VB. Вивчіть C # або щось ще краще, як Java.

"Нова мова для більшості розробників тут, ми глибоко знаємо VBA" - це загальна кодова фраза для "у нас є гуру VBA, якого ми не хочемо дратувати". Це теж можливо, що погано.

Ми шукаємо найкращі практики для поступового переміщення нашого широкого графічного інтерфейсу

Найкращі практики не передбачають "поступового". Вони включають "Відкинути цілком".

Поступові міграції, які я бачив, розбилися, бо це так важко.

Вам краще робити це.

1. Збережіть найцінніший актив . Дані. Перемістити всі дані на SQL Server. Все це. Перезапишіть усі MS-Access, щоб використовувати з'єднання ODBC до SQL Server. Негайно.

2. Запустіть усіх, хто створює тимчасові таблиці чи дані чи що-небудь у MS-Access. Усі дані повинні жити в базі даних поза MS-Access. Дані в MS-Access викликають проблеми, тому зупиніться зараз і будьте впевнені, що всі згодні. Якщо вони не згодні, знайдіть їм нову роботу, яка не передбачає злому в MS-Access, поки ви намагаєтеся позбутися MS-Access.

3. Знайдіть систему звітування, яка автоматично генерує звіти, близькі до того, що ви маєте зараз. Немає програмування. Просто дайте йому стіл або вид і стукніть! зроблено.

4. Перерахуйте всі 500 звітів. Розділіть їх на звіти, які легко створюються за допомогою інструменту, і звіти, які складніше. Розподіліть пріоритети жорстких на "Повинен мати", "Повинен мати", міг би мати "та" Не буду робити до цього пізніше ". Замініть автоматизовані звіти та обов'язкові звіти цим інструментом звітування повністю поза MS-Access.

   Мій досвід полягає в тому, що перегляд бази даних часто повторно використовується в приблизно 20 або більше звітах. З цього можу припустити, що у вас є 25 відповідних поглядів, з яких виведено 500 звітів. Будь-який інструмент, який може автоматизувати створення звітів, повинен обробляти більшість ваших звітів із невеликого набору добре складених представлень SQL. Кілька звітів будуть занадто складними або складними для автоматизованого інструменту.

5. Знайдіть рамку розробки, яка автоматично будує транзакції CRUD.

6. Розділіть свої 200 форм на форми CRUD (які можна створити автоматично) та не-CRUD форми. Серед тих, хто не є CRUD, надайте пріоритет використанню правил MoSCoW (Must, Should, Could, Won't).

   Часто 60-80% форм заявок - це прості автоматизовані форми CRUD. 20-40% складніші і потребують більш кваліфікованого програмування. Виходячи з цього, у вас є від 120 до 160 форм CRUD, які вам не потрібно переписувати, а лише автоматизувати. У вас 40-80 серйозно складних транзакцій.

7. Створіть форми CRUD та Must-have форми, які не мають CRUD.

8. Оцініть прогалини. Поставте пріоритет та розпочніть роботу над найважливішими частинами списку "Треба мати".

Напевно, найпростіше відмовитись від Access повністю. Уникайте поступовості.

Ви збираєтеся витратити всі гроші в підсумку.

Ви можете також бюджет на це і витратити зараз.

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