WINDOWS 10 VS VISUAL BASIC 6
VB6 já estava até enjoado. Sentia falta de algo novo
Por volta de 2008/2009 depois de algumas tentativas anteriores fracassadas, resolvi abraçar de vez o VB.NET, hoje uso o VB 2013
fiz um curso online e consegui arrancar. VB6 só algumas manutenções. O começo foi complicado, mas depois foi embora
O VB6 aprendi sozinho, Já o VB.NET precisei de uma ajuda, sozinho não estava saindo do lugar. Quanto mais estudava mais confuso ficava e mais duvidas surgiam.
Meu principal sistema em VB6 tem aprox 110 mil linhas de codigos, 150 forms, umas 120 tabelas em access, uns 200 realatórios e [Ô]um bilhão[Ô] de POGs (12 anos em VB6)
Pois bem , resolvi refaze-lo em VB.NET e SQL Server, comecei do zero, desde a primeira linha de código.
Depois de 3 anos desenvolvendo/Refazendo meus clientes do VB6 estão migrando para o Novo sistema, gradualmente todos irão receber. (precisa migrar banco de dados e ver as particularidades de cada cliente)
hoje ele está 80% pronto. Já passou pelas cobaias para consertos e ajustes, tudo certo
não passou ainda das 65 mil linhas de códigos, sistema ficou enxuto, com muito mais funcionalidades, praticamente zero de POGs. vb6 nunca mais.
VB.NET é infinitamente mais prazeroso programar
Por volta de 2008/2009 depois de algumas tentativas anteriores fracassadas, resolvi abraçar de vez o VB.NET, hoje uso o VB 2013
fiz um curso online e consegui arrancar. VB6 só algumas manutenções. O começo foi complicado, mas depois foi embora
O VB6 aprendi sozinho, Já o VB.NET precisei de uma ajuda, sozinho não estava saindo do lugar. Quanto mais estudava mais confuso ficava e mais duvidas surgiam.
Meu principal sistema em VB6 tem aprox 110 mil linhas de codigos, 150 forms, umas 120 tabelas em access, uns 200 realatórios e [Ô]um bilhão[Ô] de POGs (12 anos em VB6)
Pois bem , resolvi refaze-lo em VB.NET e SQL Server, comecei do zero, desde a primeira linha de código.
Depois de 3 anos desenvolvendo/Refazendo meus clientes do VB6 estão migrando para o Novo sistema, gradualmente todos irão receber. (precisa migrar banco de dados e ver as particularidades de cada cliente)
hoje ele está 80% pronto. Já passou pelas cobaias para consertos e ajustes, tudo certo
não passou ainda das 65 mil linhas de códigos, sistema ficou enxuto, com muito mais funcionalidades, praticamente zero de POGs. vb6 nunca mais.
VB.NET é infinitamente mais prazeroso programar
Citação:umas 120 tabelas em access
Tudo isso em um mesmo arquivo?????
qual foi o tamanho em mgbytes que chegou esse arquivo??
Deve ter ficado uma arquivo ginatesco e fico aqui imaginando quanto tepo levava para recuperar uma informaão com uma simples Query.
Realmente, o access estava me dando muita dor de cabeça, 120 tabelas variam nos clientes entre 40 a 300Mb e não param de crescer.
não passava um mês para alguém ligar com o banco corrompido que o restaurar do access nem sempre solucionava, tendo que recorrer ao backup.
E existem tabelas com 400 mil registros. Na verdade são 174 tabelas, umas 40 são tabelas temporárias e mais os lixos
Já no banco principal no SQL server essas 120 tabelas viraram 70, mas como já está com 80%, acho que até o fim será criado mais umas 10 tabelas
Quanto ao tempo, tinham consultas para gerar relatórios que levavam 10, 15 minutos, era trágico (VB6 + Access).
Hoje no VB.NET a mesma consulta se faz em 2 minutos, claro que como é novo, tb dei uma melhorada nas rotinas SQL e Manipular 400 mil registros num banco no SQL server não faz nem cocegas. O sistema novo está a todo vapor a 7 meses e nunca precisei restaurar o banco de dados ou puxar um backup. Os Backups são feitos automaticamente na Nuvem (Google Drive)
Como ainda tem vários cliente que ainda não passaram para o sistema novo, tenho que aturar a manutenção no VB6 e Access. até o final do ano espero que sistema esteja em todos os clientes.
Meu clientes são Escolas (Secretaria, Tesouraria e Biblioteca). Tb tenho uma parceria que faz uma parte do sistema ser disponibilizada na internet
não passava um mês para alguém ligar com o banco corrompido que o restaurar do access nem sempre solucionava, tendo que recorrer ao backup.
E existem tabelas com 400 mil registros. Na verdade são 174 tabelas, umas 40 são tabelas temporárias e mais os lixos
Já no banco principal no SQL server essas 120 tabelas viraram 70, mas como já está com 80%, acho que até o fim será criado mais umas 10 tabelas
Quanto ao tempo, tinham consultas para gerar relatórios que levavam 10, 15 minutos, era trágico (VB6 + Access).
Hoje no VB.NET a mesma consulta se faz em 2 minutos, claro que como é novo, tb dei uma melhorada nas rotinas SQL e Manipular 400 mil registros num banco no SQL server não faz nem cocegas. O sistema novo está a todo vapor a 7 meses e nunca precisei restaurar o banco de dados ou puxar um backup. Os Backups são feitos automaticamente na Nuvem (Google Drive)
Como ainda tem vários cliente que ainda não passaram para o sistema novo, tenho que aturar a manutenção no VB6 e Access. até o final do ano espero que sistema esteja em todos os clientes.
Meu clientes são Escolas (Secretaria, Tesouraria e Biblioteca). Tb tenho uma parceria que faz uma parte do sistema ser disponibilizada na internet
Bem, vamos ao assunto desempenho com .NET:
Veja bem onde você está lendo isso que escrevo agora. Em um browser, um navegador. Ele é a porta de acesso à internet, que negue o quanto quiser, é uma realidade e está aqui para ficar. Desenvolver aplicativos, é necessariamente acompanhar a evolução. Quem trabalha [Ô]por conta[Ô], sabe muito bem disso. Os clientes estão cada dia mais exigentes. Não bastam mais pequenos programinhas para controle de estoque, que ficam instalados no local. Eles querem integração bancária, com sites de vendas, com redes sociais. O futuro(aliás, o PRESENTE) é a programação WEB. E nesse quesito, o .NET é espetacular. Hoje em dia, o que faço é uma receitinha de bolo: Uma WebAPI, que disponibiliza dados e um front-end em HTML puro. A WebAPI, desenvolvo em C# mesmo e geralmente uso banco de dados SQL Server. A API, disponibiliza XML e JSON, que são consumidos pelo front-end, e acreditem, até mesmo por aplicações desenvolvidas para Android e iPhone. Os mesmos dados disponÃveis no site, estão também disponÃveis nos dispositivos móveis e praticamente tudo que está disponÃvel no site(HTML puro), está também disponÃvel nos programas para dispositivos móveis. Esta API, se torna pública ou não de acordo com a vontade do cliente. Por isso, o investimento dele é apenas no servidor, o parque de máquinas fica à critério dele, se quiser pode usar notebooks bem simples e até mesmo thin-clients sem nenhuma perda de desempenho ou mesmo funcionalidade. Se o cliente optar, essa API estando pública, tanto clientes quanto fornecedores ou qualquer outro, pode ter acesso à ela, tudo determinado por direitos e papéis(roles). Isso torna a integração muito mais simples. Os dados e funcionalidades desejadas são acessadas por terceiros em suas aplicações, que pode ou não fazer o mesmo. A aplicação web, tem uma facilidade enorme para integração com redes sociais, plataformas de venda e serviços de internet(como o google, por exemplo). Com isso, eu abro um leque de opções infinito ao cliente, que pode integrar a aplicação com e-mails, aplicativos online(como o google docs ou o office online), plataformas de vendas(como o mercado livre, OLX), redes sociais(como twitter e facebook), enfim, eu abro a internet inteira para o aplicativo dele, sem nenhum prejuÃzo de desempenho para a aplicação desenvolvida por mim e ainda possibilito que o meu cliente possa integrar seus dados com qualquer outro sistema de terceiro que ele desejar, incluindo seus clientes e fornecedores ou qualquer outro que ele queira dar acesso.
Em resumo, desenvolver aplicativos executáveis, apesar de ainda ser totalmente possÃvel e aconselhável em alguns casos, não deve mais ser cotado como primeira opção para desenvolvimento, mas sim o desenvolvimento de aplicativos Web.
Veja bem onde você está lendo isso que escrevo agora. Em um browser, um navegador. Ele é a porta de acesso à internet, que negue o quanto quiser, é uma realidade e está aqui para ficar. Desenvolver aplicativos, é necessariamente acompanhar a evolução. Quem trabalha [Ô]por conta[Ô], sabe muito bem disso. Os clientes estão cada dia mais exigentes. Não bastam mais pequenos programinhas para controle de estoque, que ficam instalados no local. Eles querem integração bancária, com sites de vendas, com redes sociais. O futuro(aliás, o PRESENTE) é a programação WEB. E nesse quesito, o .NET é espetacular. Hoje em dia, o que faço é uma receitinha de bolo: Uma WebAPI, que disponibiliza dados e um front-end em HTML puro. A WebAPI, desenvolvo em C# mesmo e geralmente uso banco de dados SQL Server. A API, disponibiliza XML e JSON, que são consumidos pelo front-end, e acreditem, até mesmo por aplicações desenvolvidas para Android e iPhone. Os mesmos dados disponÃveis no site, estão também disponÃveis nos dispositivos móveis e praticamente tudo que está disponÃvel no site(HTML puro), está também disponÃvel nos programas para dispositivos móveis. Esta API, se torna pública ou não de acordo com a vontade do cliente. Por isso, o investimento dele é apenas no servidor, o parque de máquinas fica à critério dele, se quiser pode usar notebooks bem simples e até mesmo thin-clients sem nenhuma perda de desempenho ou mesmo funcionalidade. Se o cliente optar, essa API estando pública, tanto clientes quanto fornecedores ou qualquer outro, pode ter acesso à ela, tudo determinado por direitos e papéis(roles). Isso torna a integração muito mais simples. Os dados e funcionalidades desejadas são acessadas por terceiros em suas aplicações, que pode ou não fazer o mesmo. A aplicação web, tem uma facilidade enorme para integração com redes sociais, plataformas de venda e serviços de internet(como o google, por exemplo). Com isso, eu abro um leque de opções infinito ao cliente, que pode integrar a aplicação com e-mails, aplicativos online(como o google docs ou o office online), plataformas de vendas(como o mercado livre, OLX), redes sociais(como twitter e facebook), enfim, eu abro a internet inteira para o aplicativo dele, sem nenhum prejuÃzo de desempenho para a aplicação desenvolvida por mim e ainda possibilito que o meu cliente possa integrar seus dados com qualquer outro sistema de terceiro que ele desejar, incluindo seus clientes e fornecedores ou qualquer outro que ele queira dar acesso.
Em resumo, desenvolver aplicativos executáveis, apesar de ainda ser totalmente possÃvel e aconselhável em alguns casos, não deve mais ser cotado como primeira opção para desenvolvimento, mas sim o desenvolvimento de aplicativos Web.
KERPLUNK,
Perfeita sua explicação. Tenho tentado migrar a aplicação (exe) feito em VB6 da minha empresa (Consultoria Ambiental), para VB.net, mas lendo seu texto, vejo que o ideal é migrar para WEB, então tenho que retomar meus estidos de C# ou mesmo VB.net for WEB, para que a integração seja perfeita e permitir ao meu cliente informações em tempo real e nçao dependente de uma atualização em uma determinada máquina ou in locu, mas em viagem eu posso atualizar, o site e esta atualização está disponÃvel apra todos os colaboradores, obviamente filtrada pelo nÃvel de acesso.
Aplicações internas, acredito que um executável com banco de dados, SQL Server Express (no meu caso atende) passa a ser ideal, uma vez que uma possÃvel falha de segurança, pode expor os dados internos da empresa.
Cloud coputer é sem sobra de dúvidas o presente e o futuro.
Perfeita sua explicação. Tenho tentado migrar a aplicação (exe) feito em VB6 da minha empresa (Consultoria Ambiental), para VB.net, mas lendo seu texto, vejo que o ideal é migrar para WEB, então tenho que retomar meus estidos de C# ou mesmo VB.net for WEB, para que a integração seja perfeita e permitir ao meu cliente informações em tempo real e nçao dependente de uma atualização em uma determinada máquina ou in locu, mas em viagem eu posso atualizar, o site e esta atualização está disponÃvel apra todos os colaboradores, obviamente filtrada pelo nÃvel de acesso.
Aplicações internas, acredito que um executável com banco de dados, SQL Server Express (no meu caso atende) passa a ser ideal, uma vez que uma possÃvel falha de segurança, pode expor os dados internos da empresa.
Cloud coputer é sem sobra de dúvidas o presente e o futuro.
WCOSTA,
é muito comum este medo de falhas de segurança e perfeitamente compreensÃvel. Veja bem, muita gente para tornar sua aplicação mais robusta, acaba expondo o banco de dados em si e mudando a string de conexão para conectar nesse banco remoto. Isso é muito mais perigoso do que o mais simples dos sistemas que utiliza WebAPI. Existem várias maneiras de tornar sua WebAPI muito segura, a mais comum delas, é o uso de Tokens que é parte da tecnologia OAuth. é extremamente seguro e escalonável. Você pode ter funções na sua API que não requerem Tokens para dar acesso à terceiros, por exemplo, lista de preço de produtos. Você cria um método que fica público e qualquer um pode acessar para consulta. Métodos que requerem uma autenticação, como um pedido de compra por exemplo, ficam inacessÃveis para qualquer um que não tenha efetuado um login válido. Essa autenticação pode inclusive ser [Ô]emprestada[Ô] de outros meios em que o usuário já possua um login válido, como o próprio facebook por exemplo. Ou seja, o usuário que queira fazer um pedido de compra na sua WebAPI, basta logar com seu login do facebook e autorizar a sua aplicação à acesso ao seu perfil pessoal e pronto, o login está feito, você tem vários dados para fazer qualquer verificação que queira e de quebra o usuário deixou sua aplicação [Ô]conversar[Ô] com seu facebook, abrindo a porta para que você mande ofertas que aparecerão na timeline dele. E isso é só uma das muitas possibilidades que são abertas com o uso Web. Você sequer precisa manter um sistema de login, existem engines gratuitas que cuidam disso para você e integram com os maiores provedores de identidade, como Twitter, Facebook, Google+, Microsoft e ainda um sistema próprio para usuários que não tenham ou não queiram a integração com suas redes sociais.
WebAPI, é o método que todos os grandes serviços de internet fornecem para integração. Muito mais robusta que um simples WebService e muito mais acessÃvel tecnologicamente, pois a tecnologia do cliente, indifere quanto ao seu uso. Ou seja, você pode fazer sua WebAPI numa boa com C# que vai integrar com Android, iPhone, PHP, ASP.NET, Ruby, Python, enfim, não faz diferença pois tudo funciona com chamadas HTTP com o verbo especÃfico(GET, POST, PUT, DELETE...) para cada funcionalidade. Em outras palavras, seu sistema passa a ser integrável com qualquer coisa que o cliente queira usar, até mesmo os bancos de dados mais modernos já possuem métodos para consumo de WebAPI, um [Ô]select * from[Ô] buscando dados da sua WebAPI.
Ficaria feliz em ajudar a entender tudo isso, que sei muito bem que para quem está iniciando no assunto, pode ser um bicho de sete cabeças. Estou planejando umas web-aulas em vÃdeo, explicando tudo isso, que no final vai ter uma pequena aplicação web para estudo e de quebra, aprende muita coisa. Assim que estiver tudo pronto eu posto os links para os vÃdeos!
Abraço!
é muito comum este medo de falhas de segurança e perfeitamente compreensÃvel. Veja bem, muita gente para tornar sua aplicação mais robusta, acaba expondo o banco de dados em si e mudando a string de conexão para conectar nesse banco remoto. Isso é muito mais perigoso do que o mais simples dos sistemas que utiliza WebAPI. Existem várias maneiras de tornar sua WebAPI muito segura, a mais comum delas, é o uso de Tokens que é parte da tecnologia OAuth. é extremamente seguro e escalonável. Você pode ter funções na sua API que não requerem Tokens para dar acesso à terceiros, por exemplo, lista de preço de produtos. Você cria um método que fica público e qualquer um pode acessar para consulta. Métodos que requerem uma autenticação, como um pedido de compra por exemplo, ficam inacessÃveis para qualquer um que não tenha efetuado um login válido. Essa autenticação pode inclusive ser [Ô]emprestada[Ô] de outros meios em que o usuário já possua um login válido, como o próprio facebook por exemplo. Ou seja, o usuário que queira fazer um pedido de compra na sua WebAPI, basta logar com seu login do facebook e autorizar a sua aplicação à acesso ao seu perfil pessoal e pronto, o login está feito, você tem vários dados para fazer qualquer verificação que queira e de quebra o usuário deixou sua aplicação [Ô]conversar[Ô] com seu facebook, abrindo a porta para que você mande ofertas que aparecerão na timeline dele. E isso é só uma das muitas possibilidades que são abertas com o uso Web. Você sequer precisa manter um sistema de login, existem engines gratuitas que cuidam disso para você e integram com os maiores provedores de identidade, como Twitter, Facebook, Google+, Microsoft e ainda um sistema próprio para usuários que não tenham ou não queiram a integração com suas redes sociais.
WebAPI, é o método que todos os grandes serviços de internet fornecem para integração. Muito mais robusta que um simples WebService e muito mais acessÃvel tecnologicamente, pois a tecnologia do cliente, indifere quanto ao seu uso. Ou seja, você pode fazer sua WebAPI numa boa com C# que vai integrar com Android, iPhone, PHP, ASP.NET, Ruby, Python, enfim, não faz diferença pois tudo funciona com chamadas HTTP com o verbo especÃfico(GET, POST, PUT, DELETE...) para cada funcionalidade. Em outras palavras, seu sistema passa a ser integrável com qualquer coisa que o cliente queira usar, até mesmo os bancos de dados mais modernos já possuem métodos para consumo de WebAPI, um [Ô]select * from[Ô] buscando dados da sua WebAPI.
Ficaria feliz em ajudar a entender tudo isso, que sei muito bem que para quem está iniciando no assunto, pode ser um bicho de sete cabeças. Estou planejando umas web-aulas em vÃdeo, explicando tudo isso, que no final vai ter uma pequena aplicação web para estudo e de quebra, aprende muita coisa. Assim que estiver tudo pronto eu posto os links para os vÃdeos!
Abraço!
KERPLUNK,
Com certeza sua ajuda será bem vinda a todos. Quando postar as Web aulas compartilha aqui, pois muitos irão agradecê-lo imensamente (Eu ->
).
Quanto as questões de segurança vocês tem razão. Aplicar o protocolos corretos é o suficiente para minimizar ao máximo problemas com acessos indevidos.
Abraço.
Com certeza sua ajuda será bem vinda a todos. Quando postar as Web aulas compartilha aqui, pois muitos irão agradecê-lo imensamente (Eu ->
).Quanto as questões de segurança vocês tem razão. Aplicar o protocolos corretos é o suficiente para minimizar ao máximo problemas com acessos indevidos.
Abraço.
Uma coisa a ser considerada é: Em se tratando de TI/sistemas, não existe absolutamente nada 100% seguro e isso é FATO. Para cada pessoa pensando em segurança, tem pelo menos 20 pensando em como burlar. Falhas de segurança existem até mesmo em VB6, veja por exemplo o grande número de pessoas aqui no fórum mesmo, que ainda utiliza concatenação de strings para formar um comando SQL. Isso é uma brecha enorme de segurança, para SQL Injection, um usuário um pouco mais espertinho consegue isso sem muitos problemas. Também vejo muitos casos de pessoas que [Ô]abrem[Ô] o banco de dados e conectam via ADO por LAN e até mesmo por internet. Isso é outra falha colossal de segurança. WebAPI, como já mencionei, é o método usado para integração pelos maiores provedores de serviço da internet. Ele possui falhas de segurança? Bem, sim, se mal implementado pode ser uma faca de dois gumes. Existe como prevenir isso? Sem dúvida! E informação para isso é o que não falta aqui na internet. Existem milhares, literalmente milhares de vÃdeos, artigos, fora(plural de Fórum), blogs, apostilas, enfim uma infinidade de informação sobre isso. Como é uma coisa muito mais conceitual do que necessariamente prática, as pessoas têm dificuldade de entender e se não tem nenhuma experiência com isso acaba desistindo na [Ô]sopa de letrinhas[Ô] que acaba se tornando.
Tópico encerrado , respostas não são mais permitidas