Quais são algumas boas técnicas para converter um aplicativo do MS acesso a um aplicativo .net?

Question

Nós temos um aplicativo de 12-year-old Ms Access que usamos para o nosso core armazenagem de estoque e sistema de facturação. Ele já está em execução em um backend SQL Server, mas todos a "lógica", formulários e relatórios estão em Access. Depois de experimentar as enormes quantidades de lodo de manutenção que levou para transformar transações de estoque de non-temporal para temporais, eu percebi que eu preciso converter algum dia essa coisa em código para que eu possa gerenciar melhor a lógica em um ambiente muito mais sustentável e testável.

Quais são algumas técnicas que me permita convertê-lo em um aplicativo .NET de maneira controlável e eficiente?

Uma ideia era converter as consultas para procedimentos armazenados, em seguida, converter o aplicativo em um Adp project.But eu ainda à nora sou a respeito de como lidar com os formulários e relatórios.

Além disso, eu sou o único desenvolvedor para a minha empresa, se o que importa.

Answer 1

Como você já tem asp.net com alguma lógica de negócios que você poderia abrir este até o acesso como um serviço web (arquivos ASMX). Google para o Microsoft Office Web Services Toolkit para a versão do acesso (XP / 2003 etc.) e isso vai escrever vba classes de proxy para que você possa chamar o serviço web. Você pode vincular dados de serviços da Web para as formas através de código (VBA para ler e escrever para controles) ou criar tabelas temporárias locais com dados do serviço de web e usar ligação de acesso regular.

Dependendo do que você está mais confortável com (código / tsql) você pode colocar lógica em procedimentos armazenados ou em uma camada lógica de negócios ou híbrido (ambos). Acho que é mais fácil de código de teste de procedimentos armazenados e como não ser obrigado a servidor SQL para a lógica de negócios ou seja, se você quiser alterar o banco de dados ou quer desenvolver / componentes de teste off-line sem um banco de dados. New .net recursos como LINQ têm desempenho muito bom para que você não tem que confiar em procedimentos armazenados para as atividades de banco de dados.

Mantenha a interface do usuário final acesso frontal até ter reformulado todo o seu acesso a lógica do negócio / dados para serviços web. Você pode criar um aplicativo asp.net que consome os serviços Web ou um aplicativo winform se quiser. (Ficar claro de WPF, como ui, por enquanto, pois é uma curva de aprendizagem e ainda não tem um datagrid que se pode comparar com o ponto de vista de acesso folha de dados.)

Relatórios

Os relatórios de acesso pode pode ser convertida para o Reporting Services do SQL Server (VBA em relatórios não converter e é melhor para escrever alguns tsql em procedimentos armazenados). Se você não tem o produto de servidor SQL completa você ainda pode usar o controle ReportViewer para lhe escrever relatórios (ver http: // www.gotreportviewer.com/ ) em asp.net (ou winform com a versão standard ou por Visual Studio) de ligação para o ADO.NET conjuntos de dados.

Outras opções: Você pode escrever .net dlls e a utilização de interoperabilidade. Esta abordagem permite que você começar a escrever funcionalidade gradualmente. Não use .net ui por exemplo um winform como ele não vai jogar bem com acesso ui. Você poderia escrever lógica de negócios ou lógica de acesso de dados e, em seguida, chamar essas classes do VBA. Você pode então mover este código para serviços ASP.NET ou Web, se necessário.

Coisas para descartar:

Eu não gosto da abordagem de escrever um novo aplicativo com o lado por versões secundários. Como um único desenvolvedor, você tem o suficiente para se preocupar. Você provavelmente vai acabar adicionando funcionalidades em ambas as versões e depurar duas versões, em vez de um.

As formas VB6 interoperabilidade não funciona para acesso.

ADP como dito é bastante mortos. (Eu nunca gostei deles como eu muitas vezes usam tabelas locais para otimizar o desempenho e eles só podem ser chamados através de código e não ligados)

Você pode ser capaz de converter os seus módulos de VBA e módulos de classe para vb.net usando o Visual Basic Wizard (no visual studio) Melhora mas não converter tudo (por exemplo dao / ado código para ado.net código) e não cria código que é otimizado para .net e pode não ser fácil de escrever testes de unidade sobre dependendo do projeto do código VBA. Eu recomendo reescrever o código (experimente Test Driven Development, se você é sério sobre o teste para ver se você como ele).

Answer 2

Resposta curta:. A migração não parece ser algo facilmente automatizado

Meu palpite é que sua melhor aposta é para reescrever (e instalar) o sistema de uma peça de cada vez, mesmo se (talvez) que obriga os usuários executem as velhas e novas versões lado a lado por um tempo para usar diferentes bits de funcionalidade. Você pode minimizar esse aborrecimento por uma análise cuidadosa dos quais dispõe a migrar e em que ordem.

Por exemplo, você pode ter um utilizador cuja função trabalho exige que ele ou ela usar apenas uma tela durante todo o dia. Se você migrar que a tela primeiro com acompanhamento de funcionalidade, que o usuário pode estar no novo sistema imediatamente e deixar o velho para trás, reduzindo sua carga de manutenção.

Portanto, estas são apenas algumas idéias baseadas em não muita informação. Espero que isso ajude de qualquer maneira.

Answer 3

eu consideraria olhando para os Interop Forms Toolkit . Pelo que entendi, esta ferramenta torna muito fácil de usar formas .NET de dentro VB6, então talvez ele também pode ser usado a partir do Microsoft Access? Se assim for, pode ajudá-lo a migrar o aplicativo para .NET de forma incremental. Fazendo uma rápida pesquisa, eu era incapaz de encontrar qualquer guias sobre a usá-lo com o Microsoft Access, por isso peço desculpas se este acaba por ser um beco sem saída.

Answer 4

A conversão para um adp não vai ser uma boa solução a longo prazo -. Esta tecnologia é abandonado pela Microsoft

Se você quiser mudar para .net (por quê? Você tem uma razão para favorecer .net?) Eu sugiro que você comece alguma leitura, tente criar alguns aplicativos simples e, em seguida, iniciar a tarefa de converter este banco de dados para uma aplicação .

Mas ...

Eu acho que você e a necessidade da empresa de pensar sobre os riscos envolvidos neste projecto. O que vai acontecer se você ficar doente, apenas na semana que a gestão precisa de alguns relatórios que não existam? Gostaria de sugerir que você procure uma pequena empresa de desenvolvimento de software local, eles terão prazer em ajudá-lo. Talvez você pode providenciar que você continue a ser o 'principal desenvolvedor' e só usá-los para back-up.

Answer 5

Eu tenho um problema semelhante, e dirigiu-lo através da criação de um sistema de implantação de versão na extremidade dianteira Access (agarrar e extrair um arquivo CAB), descobrir a manipulação AppDomain necessário para ser capaz de carregar a versão CLR correto para o acesso processo, carregar um arquivo config, e os dados pós em ambos os sentidos .

Ele usa chamadas C DLL padrão, de modo nenhum registro COM necessário, mas também infelizmente não suporte a Unicode.

Enviar comando - Generic, eu poderia ter feito tudo com este. Abrir Form - Destinado a ser um "drop in" substituto para DoCmd.OpenForm Abrir relatório - Destinado a ser um "drop in" substituto para DoCmd.OpenReport

Então, faça um novo relatório, ou migrar um existente para o SSRS, tornar o padrão de formato, e depois mudar DoCmd.OpenReport para netDoCmd.OpenReport no Access.

Siga uma convenção de nomenclatura para saber onde os relatórios são para carga de, e um método padrão para puxar os dados necessários para o relatório.

Agora eu estou migrando forma um ou relatório como licenças de capacidade, ou quando uma mudança é solicitada a ele.

Porque quem pode parar o desenvolvimento recurso por um ano para fazer tudo em um hit?

MDI não funciona corretamente embora. Eu acho que há algum trabalho que ainda precisa fazer em torno SetParent e UPDATE_UISTYLE

Tudo isso faz com que a interface do usuário no processo e na janela com o Access. Eu construir tudo em DLLs, e o passo final será a criação de um EXE que carrega a "primeira forma" e usar isso para substituir o front-end Access.