Лучшие практики для перемещения большого приложения 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 для подключения Access к SQL Server, используйте вместо этого Access Project (ADP). Проект доступа - это файл доступа с расширением .adp, он имеет полные функции доступа (макросы, формы, отчеты, модули), но соединение находится непосредственно в базе данных SQL Server, а не в файле MDB. ADP-файлы очень совместимы с MDB-файлами. Похоже, они не поддерживаются в Access 2010, хотя на самом деле эта функция скрыта, но поддерживается очень хорошо. Как и MDE, файлы ADP можно «скомпилировать» в файлы ADE.

Миграция в SQL Server обойдется в несколько модификаций в структуре данных и коде, но все довольно легко перенести. И это конечная цель в конце концов.

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

Шаг 2: сделать аутентификацию единообразной

Хорошо, что ваше приложение не основано на безопасности доступа (файл MDW).

Составьте план для целевой аутентификации для приложения VB.Net, а затем определите способ переноса аутентификации Access в эту цель, чтобы обеспечить одинаковую аутентификацию между двумя приложениями.

Поскольку аутентификация является поперечной в архитектуре приложения, ее будет легче разделить между версией Access и версией VB.Net.

Шаг 3: подготовить функцию токена для создания моста между Access и VB.Net

Вы сказали, что пользовательский интерфейс Access должен будет открыть пользовательский интерфейс VB.Net с некоторыми точными параметрами, а также аутентификацией. И вам, вероятно, придется сделать то же самое другим способом.

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

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

Шаг 4: перенести пользовательский интерфейс и модули экран за экраном, модуль за модулем

Теперь большая часть подготовки завершена. Вы можете начать миграцию пользовательского интерфейса с Ms Access на VB.Net.

Нет хороших автоматических инструментов для этого. VBA и .Net слишком разные. Вы должны подготовить свою работу к такой миграции. Начните с небольшой формы, такой как поле «О программе», и переходите от простых форм к сложным формам. Конечно, вам придется связывать и планировать некоторые миграции, но вы будете постепенно переносить свои экраны, отчеты и библиотеки из Ms Access в VB.Net.

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

Поскольку вы уже хорошо понимаете объектную модель Access, я думаю, что вы хотите использовать Access Interop из вашего приложения .NET. Это должно (более или менее) позволить вам автоматизировать управление приложением Access без непрозрачности DDE.

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

Вы просите лучшую практику о том, как поступить неправильно. Там нет ни одного. Лучшие практики включают в себя способы эффективного создания обслуживаемой системы, чтобы даже в случае сбоя шины и необходимости полного восстановления новой команды разработка и поддержка могли продолжаться. Система, которую вы описываете, отправит большинство разработчиков на работу. У вас есть продукт, созданный с использованием устаревших технологий, и вы хотите взаимодействовать с современными технологиями. И вы хотите сделать это, не обращаясь к любому из анти-паттернов, которые вы описали для основного продукта. Те разработчики, которые готовы заняться этим, скорее всего, не захотят делать это с теми условиями, которые вы предлагаете.

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

Мы решили постепенно переместить наше приложение в .Net

Часто ошибка. Лучшая практика - не пытаться «постепенно».

Несмотря на то, что это новый язык для большинства разработчиков, у нас есть глубокие знания VBA и несколько десятков небольших проектов, реализованных в VB6.

Не очень хорошая основа для принятия решения. Если вы хотите выучить новый язык, не учите VB. Изучите C # или что-то еще лучше, как Java.

«новый язык для большинства разработчиков здесь, у нас есть глубокие знания VBA» - это обычная кодовая фраза для «у нас есть VBA Guru, которого мы не хотим раздражать». Возможно, это тоже плохо.

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

Лучшие практики не включают «Постепенный». Они включают «Откажитесь полностью».

Постепенные миграции, которые я видел, сломались, потому что это так тяжело.

Тебе лучше делать это.

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 (Должен, Должен, Мог, Не будет).

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

7. Создайте формы CRUD и Must-have не-CRUD.

8. Оцените пробелы. Перераспределите приоритеты и начните работать над наиболее важными частями списка «Нужно иметь».

Вероятно, проще всего полностью отказаться от Access. Избегайте постепенности.

Вы собираетесь потратить все деньги в конце концов.

Вы можете также составить бюджет и потратить его сейчас.

Попытка сделать это постепенно может быть более дорогой из-за сложности управления сосуществованием.