Práticas recomendadas para mover aplicativos grandes do MS Access para .Net?

Temos um aplicativo MS Access realmente enorme, desenvolvido internamente inicialmente para nossas necessidades pessoais, que depois foi transformado em um software comercial e vendido com sucesso. O software é uma espécie de "software completo para o seu negócio" e contém vários módulos, incluindo Sistema de Gerenciamento de Documentos, Planejamento de Recursos Empresariais, Gerenciamento de Inventário, Gerenciamento de Relacionamento com Cliente, Análise de Dados etc. Estamos bastante satisfeitos com o atual funcionalidade do aplicativo, mas para atender às solicitações de nossos clientes, percebemos que precisamos mudar para algo novo.

Decidimos mudar gradualmente nosso aplicativo para .Net porque podemos seguir o Visual Basic .Net: embora seja uma nova linguagem para a maioria dos desenvolvedores aqui, temos um profundo conhecimento do VBA e várias dezenas de pequenos projetos implementados no VB6.

Já começamos a mover a funcionalidade da camada de dados de nosso aplicativo para o MS SQL Server, para que todas as manipulações e pesquisas de dados sejam realizadas diretamente no servidor.

O que procuramos são práticas recomendadas para mover gradualmente nossa GUI abrangente (cerca de 500 a 600 formulários diferentes, incluindo subformulários, cerca de 200 relatórios com suporte em vários idiomas etc.). Após a recente solicitação do nosso cliente em potencial para implementar criptografia de dados assíncrona em documentos no DMS, também ficaríamos felizes em separar completamente essa parte do MS Access e implementá-la no .Net.

A questão é como integrar perfeitamente o aplicativo .Net ao sistema existente do MS Access, para que possamos invocá-lo com determinados parâmetros (direitos do usuário etc.) e permitir a troca de dados entre esse aplicativo e o aplicativo MS Access em execução.

EDITAR:

Tentamos aplicar algumas práticas do livro de Martin Fowler " Enterprise intergration patterns " para obter alguma integração entre o aplicativo MS Access e alguns pequenos utilitários que implementamos no .Net para diversas necessidades. Mas nós apenas conseguimos usar o padrão "banco de dados compartilhado" e não estávamos realmente satisfeitos com nossa solução.

Por exemplo, implementamos um pequeno utilitário em execução como um serviço do Windows que baixa automaticamente todas as mensagens do servidor de correio usando a conexão POP3 e as armazena em uma tabela, enquanto todos os anexos são armazenados no sistema de arquivos.

O que fizemos principalmente foi usar o ADO.NET para acessar diretamente os bancos de dados do MS Access no formato MDB e preencher a tabela com alguns dados processados ​​(como os dados sobre mensagens de email do exemplo acima: temos campos para FROM, TO, CC, BCC, Sujeito e Corpo).

Não há absolutamente nenhum problema em trabalhar com o formato de dados MDB da .Net , além disso, não queremos ficar com o MDB e aumentar o tamanho de tudo para o MS SQL Server 2008 - isso nos dá muito mais liberdade em relação ao gerenciamento e escalabilidade de dados.

O principal problema aqui é que não sabemos como implementar uma espécie de "retorno de chamada" no Access para que possamos disparar a execução de determinado código VBA na atualização de dados.

Tínhamos grandes esperanças de que o MS Access 2010 suportasse gatilhos de atualização e inserção de tabelas de dados , mas descobrimos que só podemos usar macros do MS Access para esses gatilhos e não há como executar qualquer código VBA personalizado dentro do gatilho.

Também tentamos algumas soluções com o envio de pressionamentos de teclas diretamente para a janela do MS Access para imitar alguns requisitos de dados invocados pelo usuário. Isso funciona, mas não achamos que seja uma solução confiável que possa ser usada na produção.

Também analisamos o DDE para MS Access, mas não conseguimos encontrar uma boa solução de exemplo implementando comandos DDE e usando-os para troca de dados e memória na memória.

Portanto, o principal problema é ter o aplicativo MS Access e .Net coexistindo e interagindo entre si.

EDIT2 :

Esqueci de mencionar o que também implementamos na biblioteca MSMQ no VBA para passagem de mensagens entre .Net e MS Access, o problema foi novamente a falta de retorno de chamada aqui: realmente tivemos que pesquisar a fila em busca de novas mensagens e, uma vez que o VBA realmente não suporta multi-threading, não era realmente uma solução agradável.

Este será um projeto grande e muito envolvido. Fui responsável pela migração de bancos de dados do Access para o .NET várias vezes, mas nunca nessa escala. Concordo que uma abordagem gradual provavelmente será a mais realista. Tentar enfrentar tudo de uma vez é uma maneira fácil de falhar.

Como em outras respostas, o primeiro e mais importante passo será mover tudo para o SQL Server. Enquanto isso, documente o banco de dados, se isso ainda não tiver sido feito, e identifique áreas para refatoração, se existirem. Os bancos de dados de acesso que crescem para atender às crescentes necessidades geralmente têm modelos de dados que podem ser aprimorados quando se olha para o cenário geral.

Em seguida, identifique os módulos do aplicativo que são "independentes". Como esse é um banco de dados do tipo "faça tudo", provavelmente haverá módulos quase completamente separados um do outro. Depois de ter essas partes separadas, identifique um dos módulos menores que mais têm a ganhar com a atualização e leve-o primeiro.

Ao migrar para o .NET, não faça apenas uma cópia simples de 1 para 1 do aplicativo. Reúna informações dos usuários para identificar pontos problemáticos com o aplicativo atual. Você deseja que sua primeira unidade de migração seja um grande sucesso para obter a compra completa de todos os outros.

Depois de concluir a primeira unidade, observe o que aconteceu em termos de desafios, dificuldades, etc., e use isso daqui para frente.

Uma coisa que eu desencorajaria seria implementar módulos parcialmente funcionando (por exemplo: "migramos o CRM, mas os recursos X, Y, Z ainda não estão no novo sistema"). Isso fará com que os usuários rapidamente fiquem frustrados por terem um sistema incompleto quando o antigo para eles estava "perfeitamente bem". Esse tipo de desenvolvimento pode funcionar bem para outros domínios, mas não em empresas em que os usuários veem "nada de errado" com o antigo monólito do Access e não entendem as necessidades de migração.

Aqui está um tipo de plano para transformar seu aplicativo MS Access em um aplicativo VB.Net por mutação.

Este não é um plano geral; o plano a seguir depende do projeto que você descreveu.

Etapa 1: migrar todos os dados para o SQL Server

Não use ODBC para conectar o Access ao SQL Server, use um Access Project (ADP). Um projeto do Access é um arquivo do Access com uma extensão .adp, possui recursos completos do Access (macros, formulários, relatórios, módulos), mas a conexão está diretamente em um banco de dados do SQL Server em vez de um arquivo MDB. Os arquivos ADP são muito compatíveis com os arquivos MDB. Eles parecem não ter suporte no Access 2010, enquanto na verdade o recurso está oculto, mas é muito bem suportado. Como o MDE, os arquivos ADP podem ser "compilados" em arquivos ADE.

A migração para o SQL Server custará poucas modificações na estrutura e no código dos dados, mas tudo é muito fácil de migrar. E é um objetivo final, afinal.

Esqueça o gatilho de eventos do banco de dados para o código VBA ou VB.Net. Tecnicamente, isso pode ser feito usando os Procedimentos armazenados estendidos do SQL Server, mas é um truque muito ruim. Seu projeto tem uma vida futura, portanto, é melhor reforçar sua estrutura de Dados, evitando esse tipo de ponte de desestruturação. Em geral, minimizar os gatilhos de banco de dados, é inteligente, mas bastante difícil de manter.

Etapa 2: tornar a autenticação uniforme

É bom que seu aplicativo não seja baseado na segurança de acesso (arquivo MDW).

Faça um plano para a autenticação de destino do aplicativo VB.Net e defina uma maneira de migrar a autenticação do Access para esse destino para ter uma autenticação uniforme entre os dois aplicativos.

Como a autenticação é transversal em uma arquitetura de aplicativo, será mais fácil dividir entre a versão do Access e a versão do VB.Net.

Etapa 3: prepare um recurso de token para fazer uma ponte entre o Access e o VB.Net

Você disse que a interface do usuário do Access precisará abrir uma interface do usuário do VB.Net com alguns parâmetros precisos e também autenticação. E você provavelmente terá que fazer o mesmo da outra maneira.

Uma boa solução é criar um pequeno recurso de token com base em uma tabela de token: as colunas podem ser um ID de token (número inteiro), uma chave de token (string longa), uma data de token e uma lista de parâmetros (string longa ou texto). Sempre que o Access precisar abrir uma tela do VB.Net, salve um token no banco de dados com os parâmetros e abra o aplicativo VB.Net apenas com o ID do token e a chave do token. O VB.Net é aberto, pesquisa o ID do token no banco de dados, verifica a chave (isso se aplica como autenticação) e lê os parâmetros. Em seguida, abra o formulário correspondente e faça o que for necessário. Não se esqueça de dar uma duração aos tokens e limpar os tokens antigos.

Se você precisar retornar o VB.Net para o Access (provavelmente), acho que é possível ativar algum código VBA em um arquivo MDB Access aberto, usando OLE.

Etapa 4: migrar interface do usuário e módulos tela por tela, módulo por módulo

Agora a grande parte da preparação está pronta. Você pode começar a migrar a interface do usuário do Ms Access para o VB.Net.

Não há boas ferramentas automáticas para fazer isso. VBA e .Net são muito diferentes. Você precisa preparar seu trabalho para essa migração. Comece com um formulário pequeno, como a caixa "Sobre", e continue de formulários simples para formulários complicados. É claro que você precisará agrupar e agendar algumas migrações, mas migrará gradualmente suas telas, relatórios e bibliotecas do Ms Access para o VB.Net.

Estou surpreso que você tenha feito tudo isso com o Access. Há uma pergunta muito importante que você não solicitou ao .NET Windows Forms ou ao .NET WPF. O WPF tem uma curva de aprendizado mais íngreme, mas, na minha opinião, é mais poderoso com uma interface do usuário melhor. Recentemente, convertemos nosso aplicativo comercial de Forms para WPF e já estamos obtendo mais vendas. Também adicionamos novos recursos, mas a interface do WPF é apenas mais sexy. Revise o design da sua mesa e limpe - agora é a hora. Certifique-se de declarar todos os seus FKs. No Access, você pode adicionar coisas rapidamente, algumas vezes que elas escorregam. Se esta é sua primeira interface do usuário do WPF, crie alguns protótipos. Poderíamos incluir mais no WPF que o novo aplicativo tenha mais recursos, menos telas e muito menos código. Você vai deixar de odiar o XAML e até adorá-lo. Considere uma estrutura como MVVM.

Como você já tem um bom entendimento do modelo de objeto do Access, acho que deseja usar o Access Interop no seu aplicativo .NET. Deve (mais ou menos) permitir que você automatize o controle de um aplicativo do Access, sem a opacidade do DDE.

Não conheço nenhum conhecimento profundo sobre a camada lógica de negócios, mas você também pode acessar os bancos de dados do MS Access no aplicativo .NET. Se não se trata apenas de buscar dados, você pode implementar uma conexão TCP / IP entre seus programas (aplicativos VB6 e VB.NET). Por favor, dê uma olhada em um artigo no CodeProject .

Você está pedindo uma prática recomendada de como fazer a coisa errada. Não há um. As práticas recomendadas abrangem como criar efetivamente um sistema de manutenção, para que, mesmo que um ônibus entre em colapso e uma equipe totalmente nova precise entrar no clima, o desenvolvimento e o suporte possam continuar. O sistema que você descreve enviará a maioria dos desenvolvedores correndo para as colinas. Você construiu um produto com tecnologia obsoleta e deseja interagir com a tecnologia atual. E você deseja fazer isso sem resolver nenhum dos anti-padrões que você descreveu para o produto principal. Os desenvolvedores que estão dispostos a lidar com isso provavelmente não estariam dispostos a fazê-lo com as condições que você propõe.

No entanto, seu barramento não travou para que você possa aproveitar a equipe existente que entende o sistema. A melhor maneira de desenvolver gradualmente que eu encontrei é usando a Metodologia Ágil. Ele suporta um processo iterativo que aborda os requisitos de alto risco desde o início e atende bem às necessidades de negócios.

Decidimos mudar gradualmente nosso aplicativo para .Net

Muitas vezes um erro. A melhor prática é não tentar "gradualmente".

embora seja uma nova linguagem para a maioria dos desenvolvedores aqui, temos um profundo conhecimento do VBA e várias dezenas de pequenos projetos implementados no VB6.

Não é uma base muito boa para uma decisão. Se você quiser aprender um novo idioma, não aprenda VB. Aprenda C # ou algo ainda melhor como Java.

"uma nova linguagem para a maioria dos desenvolvedores aqui, temos um profundo conhecimento do VBA" é uma frase em código comum para "temos um Guru do VBA que não queremos irritar". Isso é algo que é possivelmente ruim também.

O que procuramos são práticas recomendadas para mover gradualmente nossa extensa GUI

As melhores práticas não envolvem "Gradual". Eles envolvem "Descartar totalmente".

As migrações graduais que eu vi foram interrompidas porque é muito difícil.

É melhor você fazer isso.

1. Preserve o ativo mais valioso . Os dados. Mova todos os dados para o SQL Server. Tudo isso. Reescreva todo o MS-Access para usar conexões ODBC com o SQL Server. Agora mesmo.

2. Dispare qualquer um que criar tabelas ou dados temporários ou qualquer coisa no MS-Access. Todos os dados devem estar em um banco de dados fora do MS-Access. Dados no MS-Access é o que está causando os problemas; portanto, pare agora e verifique se todos concordam. Se eles não concordarem, encontre um novo emprego que não envolva hackers no MS-Access enquanto você tenta se livrar do MS-Access.

3. Encontre uma estrutura de relatório que gere automaticamente relatórios próximos ao que você tem agora. Sem programação. Basta dar uma mesa ou uma vista e bater! está feito.

4. Enumere todos os 500 relatórios. Particione-os em relatórios que são facilmente construídos com a ferramenta e em relatórios mais difíceis. Priorize os mais difíceis para "Deve ter", "Deveria", Poderia ter "e" Não fará até mais tarde ". Substitua os relatórios automatizados e os relatórios obrigatórios que essa ferramenta de relatórios está completamente fora do MS-Access.

   Minha experiência é que uma exibição de banco de dados geralmente é reutilizada em cerca de 20 relatórios. A partir disso, acho que você tem 25 visualizações relevantes das quais os 500 relatórios são derivados. Qualquer ferramenta que possa automatizar a produção de relatórios deve lidar com a maioria dos seus relatórios a partir de um pequeno conjunto de visualizações SQL bem criadas. Alguns relatórios serão muito complexos ou difíceis para uma ferramenta automatizada.

5. Encontre uma estrutura de desenvolvimento que construa transações CRUD automaticamente.

6. Particione seus 200 formulários em formulários CRUD (que podem ser criados automaticamente) e não-CRUD. Entre os não-CRUD, priorize o uso das regras do MoSCoW (deve, deve, poderia, não quer).

   Frequentemente, 60-80% dos formulários de inscrição são simples, formulários CRUD automatizados. 20-40% são mais complexos e requerem programação mais qualificada. Com base nisso, você tem de 120 a 160 formulários CRUD que não precisa reescrever, apenas automatize. Você tem de 40 a 80 transações seriamente complexas.

7. Crie os formulários CRUD e os formulários Must-have non-CRUD.

8. Avalie as lacunas. Priorize novamente e comece a trabalhar nas partes mais importantes da lista "Deveria ter".

Provavelmente é mais fácil descartar completamente o Access. Evite o gradualismo.

Você vai gastar todo o dinheiro eventualmente.

Você também pode fazer um orçamento e gastá-lo agora.

Tentar fazer isso gradualmente pode realmente ser mais caro, devido à complexidade de tentar gerenciar a coexistência.