Каковы хорошие методы для преобразования приложения Ms Access в приложение .Net?

Question

У нас есть 12-летнее приложение Ms Access, которое мы используем для нашей основной системы складирования и выставления счетов. Он уже работает на бэкэнде SQL Server, но вся «логика», формы и отчеты находятся в Access. Испытав огромное количество шлама на обслуживание, необходимого для превращения транзакций инвентаризации из невременного во временное, я понял, что мне нужно когда-нибудь преобразовать эту вещь в код, чтобы я мог лучше управлять логикой в ​​гораздо более удобной и проверяемой среде. 1001 *

Какие методы позволят мне преобразовать его в приложение .Net управляемым и эффективным способом?

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

Кроме того, я единственный разработчик для своей компании, если это имеет значение.

Answer 1

Краткий ответ: миграция не выглядит легко автоматизированной.

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

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

Так что это всего лишь некоторые идеи, основанные на не слишком большом количестве информации. Надеюсь, в любом случае это поможет.

Answer 2

Поскольку у вас уже есть asp.net с некоторой бизнес-логикой, вы можете открыть его для доступа в качестве веб-службы (файлы asmx). Google для Microsoft Office Web Services Toolkit для вашей версии доступа (XP / 2003 и т. Д.), И это будет писать прокси-классы VBA для вас, чтобы вызвать веб-службы. Вы можете связать данные веб-службы с формами с помощью кода (vba для чтения и записи в элементы управления) или создать локальные временные таблицы с данными из веб-службы и использовать регулярное связывание доступа.

В зависимости от того, с чем вам удобнее всего (code / tsql), вы можете поместить логику в хранимые процедуры или в слой бизнес-логики или в гибрид (оба). Я считаю, что тестировать код легче, чем хранимые процедуры, и, например, не привязываться к серверу SQL для бизнес-логики, т. Е. Если вы хотите изменить базу данных или хотите разрабатывать / тестировать компоненты в автономном режиме без базы данных. Новые функции .net, такие как LINQ, имеют довольно хорошую производительность, поэтому вам не нужно полагаться на хранимые процедуры для операций с базой данных.

Сохраняйте пользовательский интерфейс доступа до тех пор, пока вы не реорганизуете всю свою бизнес-логику / доступ к данным к веб-службам. Затем вы можете создать приложение asp.net, которое использует веб-сервисы или приложение winform, если хотите. (Пока что держитесь подальше от wpf как пользовательского интерфейса, поскольку это крутая кривая обучения, и у него еще нет сетки данных, которую можно сравнить с представлением таблицы доступа.)

Отчеты

Отчеты о доступе могут быть увеличены до служб отчетов SQL Server (vba в отчетах не увеличивается, и лучше написать некоторые tsql в хранимых процедурах). Если у вас нет полноценного продукта SQL Server, вы все равно можете использовать элемент управления reportviewer для написания отчетов (см. http://www.gotreportviewer.com/) в asp.net (или winform со стандартной версией Visual Studio или выше), связывающих ado .net наборы данных.

Другие опции: Вы можете написать .net dll и использовать com interop. Такой подход позволяет постепенно начать писать функциональность. Не используйте .net UI, например. Winform, так как он не будет хорошо играть с UI доступа. Вы можете написать бизнес-логику или логику доступа к данным, а затем вызывать эти классы из vba. Затем вы можете переместить этот код на asp.net или веб-службы, если это необходимо.

Что следует исключить:

Мне не нравится подход написания нового приложения с параллельными версиями. Как один разработчик, вам есть о чем беспокоиться. Вы, вероятно, в конечном итоге добавите функции в обеих версиях и отладите две версии, а не одну.

Взаимодействие форм vb6 не работает для доступа.

ADP, как указано, довольно мертв. (Мне они никогда не нравились, так как я часто использую локальные таблицы для оптимизации производительности, и их можно вызывать только через код, а не связывать)

Вы можете преобразовать свои модули vba и модули классов в vb.net с помощью мастера обновления Visual Basic (в Visual Studio), но он не увеличивает все размеры (например, код dao / ado в код ado.net) и не создает код, оптимизированный для .net, и может быть нелегко писать модульные тесты в зависимости от дизайна кода vba. Я рекомендую переписать код (попробуйте Test Driven Development, если вы серьезно относитесь к тестированию, чтобы увидеть, нравится ли вам это).

Answer 3

Я бы посоветовал взглянуть на Interop Forms Toolkit . Насколько я понимаю, этот инструмент очень упрощает использование форм .NET из VB6, поэтому, возможно, его также можно использовать из Microsoft Access? Если это так, это может помочь вам перенести приложение в .NET пошаговым способом. При быстром поиске я не смог найти никаких руководств по его использованию с Microsoft Access, поэтому прошу прощения, если это окажется тупиком.

Answer 4

Преобразование в adp не будет хорошим решением в долгосрочной перспективе - Microsoft отказывается от этой технологии.

Если вы хотите переключиться на .net (почему? У вас есть причина отдать предпочтение .net?), Я предлагаю вам начать чтение, попробуйте создать несколько простых приложений, а затем начать задачу преобразования этой базы данных в приложение .

Но ...

Я думаю, что вы и компания должны подумать о рисках, связанных с этим проектом. Что произойдет, если вы заболеете, как раз на той неделе, когда руководству понадобятся отчеты, которых еще нет? Я бы посоветовал вам обратиться в небольшую местную компанию по разработке программного обеспечения, они будут рады вам помочь. Возможно, вы можете договориться о том, что вы продолжаете быть «ведущим разработчиком» и использовать их только для резервного копирования.

Answer 5

У меня есть похожая проблема, и я решил ее, создав систему управления версиями в интерфейсе Access (захват и извлечение файла CAB), выясняя, какие манипуляции с AppDomain требуются для загрузки правильной версии CLR в Access обработайте, загрузите файл .config и отправьте данные в обе стороны .

Он использует стандартные вызовы C DLL, поэтому регистрация COM не требуется, но, к сожалению, и не поддерживается Unicode.

Отправить команду - Общий, я мог бы сделать все с этим. Открытая форма - предназначена для замены "вставки" в DoCmd.OpenForm Открытый отчет. Предполагается, что он станет заменой DoCmd.OpenReport

.

Создайте новый отчет или перенесите существующий в SSRS, сделайте формат стандартным, а затем измените DoCmd.OpenReport на netDoCmd.OpenReport в Access.

Следуйте соглашению об именах, чтобы узнать, откуда должны загружаться отчеты, и стандартному методу извлечения данных, необходимых для отчета.

Теперь я перемещаю одну форму или отчет, если это позволяет емкость, или когда запрашивается изменение.

Потому что, кто может остановить разработку функций на год, чтобы сделать все это одним ударом?

Хотя MDI не работает должным образом. Я думаю, что есть еще кое-что, что мне нужно сделать в отношении SetParent и UPDATE_UISTYLE

Все это делает пользовательский интерфейс в процессе и в окне с Access. Я строю все в DLL, и последним шагом будет создание EXE-файла, который загружает «первую форму» и использует его для замены внешнего интерфейса Access.