Recursos e Procedimentos para Adotar com dotNet

Developer
May 29, 2009 at 1:28 PM

Abri esse post para incluirmos tudo que se refere a Tecnologias em nosso projeto ou ligadas ao dotNet. Como iremos incluir uma série de recursos e funcionalidades associadas a tecnologias diferentes (pocktPC, Web, etc...) esse tópico poderá ser muito útil.

Então dando o "ponta-pé" inicial, abro o tópico com um assunto polêmico e que fica muito pertinente ao iniciarmos o estudo de uma ferramenta nova, nesse caso o VB.net.

Já voi discutido no VBM sobre a pseudo compilação das linguagens do VS.net, que são códigos pré-interpretados para que na primeira execução o frameworks adequado correspondente ao sistema operacional em uso, realize a compilação definitiva. Esse processo não se dá 100% durante a primeira execução, mas sim a cada rotina executada, onde a compilação completa pode levar meses dependendo do tamanho do sistema, pois ninguém usa o software inteiro no primeiro uso.

Partindo deste princípio, surge uma grande questão: A segurança.
É sabido que esse pseudo código pode ser facilmente revertido para sua linguagem original, com isso a Microsoft instituiu a engenharia reversa oficial. Da mesma forma criadas ferramentas para criptografar esses códigos de forma que não se pudesse analisá-los, porém não sei até que ponto podem evitar que ele seja revertido a linguagem original. O que fica claro é a política da Microsoft de criar ferramentas incompletas que "nos obrigam" a comprar outras ferramentas complementares para fazer o que já deveria ser feito.

O motivo dos comentários acima é para elucidar o que pergunto agora. Com base nesse cenário, seria possível compilar o projeto e executá-lo em nosso próprio micro, obrigando assim o framework a compilar definitivamente e só então incluir esse novo EXE em nossa instalação? Será que isso resolveria o problema do código ficar exposto?

Sei que se perderia a possibilidade de multiplas plataformas, porém até o momento só o Windows tem os framworks e pelo que conheço da Microsoft, talvez nunca criem framworks para outros sistemas operacionais. Dessa forma a único inconveniência que vejo nessa "Solução" que questionei acima é relativo ao TRABALHÃO que teríamos em executar todo o nosso programa antes de distribuí-lo, se é que isso funcionaria.

Exposto isso, surge uma outra pergunta: E quando precisarmos dar manutenção no sistema, corrigir uma rotina ou formulário, o código inteiro seria novamente pré-compilado para distribuir sem a proteção ou somente a parte alterada? Isso leva a questão da lentidão no cliente, quando o software é executado pela primeira vez, pois o framework tem de compilar definitivamente. E se a cada alteração que fizermos no sistema, ou seja, corrigir um bugzinho ele obriga a recompilação integral no cliente, isso pode gerar reclamações pelo cliente ou não? Como ainda não sei como tudo isso funciona, muito menos o tempo que demora nessa compilação, não tenho como avaliar, mas já lí em vários lugares sobre essa lentidão inicial.

Developer
May 30, 2009 at 10:20 PM
Edited Jun 12, 2010 at 11:15 PM

Boa noite!

Hoje passei o dia pesquisando, estudando, etc.... UFAAAA...!
Então descobri algumas coisas, umas boas outras não muito. Vejam este link sobre o VS 2010 ( http://www.infoq.com/br/news/2008/12/FSharp-Release ). Apesar de não ser claro (direto), dá a entender que o VS continuará nessa "onda" de reformulações constantes que alguns chamam de atualização, porém tem sempre um monte de mudanças (aperfeiçoamento), novos recuros (uma montanha deles) e que nem sempre iremos usar isso. Agora nesse artifo informa que será incluída a linguagem F# (que coisa é essa?). Apesar de informar que o C# e VB.Net são o carro chefe do VS 2010, também há todo indício do incentivo ao uso do F# e que ele passará a ser a linguagem Microsoft das próximas versões.

Estou querendo comprar o VS Profissional, mas fiquei na maior dúvida do que fazer. Primeiro queria ter a licença legalizada e não um Express, só que o valor é bem salgado. Assim é preciso tomar uma decisão bem coerente. Gostaria até de uma reflexão dos colegas sobre certas coisas do VS 2008 que desconheço:

1) Previsto para novembro 2009 o lançamento do Windows 7 que será muito mais leve e rápido em tudo que o Vista e XP. SO 100% reformulado que irá marcar uma nova fase do windows, com outro padrão de criação de aplicativos, conforme relato de quem já fez testes com versão BETA. Sendo assim o VS 2010 vem com suporte ao novo Windows 7 com uma nova tecnologia para criação de forms e programação (algo como XAML ou algo assim), com um monte de recursos de produtividade e dizem mais simplicidade na escrita dos códigos.

Agora fico pensando...não sei quase nada de .net, estou estudando que nem "louco" e já vai sair uma nova ferramenta que começa a mudar tudo novamente, claro que são indíciosm mas bem fortes e a Microsoft é conhecida por descontinuar coisas sem avisar, e mudar tudo de uma hora para outra.

Então pergunto: Será que esse novo Windows 7 será para o VS 2008 algo como o vista foi para o VB 6, digo um prenúncio de que em poucos anos (talvez menos de 3 pelo rítivo das atualizações atuais que são de 2 anos) o VB 2008 possa ter problemas também com o Windows 7. Já li também que parece ser possível não haver mais suporte aos frameworks 1.0 e 2.0 nas próximas atualizações, ficando só o 3.0 e 3.5 com o novo 4.0, tipo só existir as 3 últimas versões. Não sei até que ponto é verdade, mas onde há fumaça há fogo...

2) Agora não sei se compro o VS 2008 ou espero. O que estou receoso é que hoje o VS 2008 custa R$ 2.490,00 mas pelo andar da carruagem, estou achando que o VS 2010 virá muito mais caro, e quando lançam a nova versão geralmente recolhem rapidamente a anterior, e olha que não tem muito dele aqui no Brasil, só encontrei 2 lojas com ele em São Paulo, e aqui no interior nem existe só pela Web mesmo.

Pelo cenário acima e por tudo que conhecemos do mercado e Microsoft, o que vocês acham de tudo isso?

Só para avaliação - Acompanhamento das evoluções do dotNet:

Visual Studio 2002 / .NET Framework 1.0
A primeira versão oficial da plataforma surgiu em fevereiro de 2002, com o .NET Framework 1.0 e Visual Studio 2002 (codinome Rainer).

Visual Studio 2003 / .NET Framework 1.1
Um ano depois, em Abril/2003 surgiu mais uma versão da plataforma, esta chamada de .NET Framework 1.1 e Visual Studio 2003 (codinome Everett).

Visual Studio 2005 / .NET Framework 2.0
Em Outubro de 2005 a Microsoft lança uma versão mais “madura” da plataforma, é o .NET Framework 2.0 com o Visual Studio 2005 (codinome Whidbey).

.NET Framework 3.0
No lançamento do Windows VISTA surgiu uma nova versão da Framework, a 3.0 (essa versão trouxe: WPF, WCF, WWF, entre outras). Apesar de não ter “saído” um novo Visual Studio, foi possível utilizar essas tecnologias através de pacotes que eram instalados na versão 2005.

Visual Studio 2008 / .NET Framework 3.5
Em Novembro de 2007 foi o lançamento do .NET Framework 3.5 e do Visual Studio 2008 (codinome Orcas). Aqui tivemos o lançamento do LINQ.

VS2008 / .NET 3.5 Service Pack 1
Menos de um ano depois, em Agosto de 2008, a Microsoft lançou o Service Pack 1 do Visual Studio 2008 e .NET Framework 3.5. Neste SP1 temos como novidade alguns dos principais temas do momento: ADO.NET Entity Framework, ADO.NET Data Services, ASP.NET Dynamic Data, etc.

Visual Studio 2010 / .NET Framework 4.0
Em Abril/2010, com bastante atraso, a Microsoft anuncia o lançamento de mais uma versão da plataforma. É o .NET Framework 4.0 e o Visual Studio 2010 (codinome Hawaii).


Comparando com o VB 6 (cerca de 10 anos se não estou enganado).

Coordinator
May 30, 2009 at 10:59 PM

Acredito que o W7 seja realmente o grande lançamento da Microsoft. Acompanhei alguns videos da apresentação do W7 e ele promete ser mais rápido e melhor que seus antecessores.

Eu acredito que SIM, o Windows 7 será para o VS 2008 assim como foi o VISTA para o VB6. O maior problema é iniciar o desenvolvimento propriamente dito na plataforma .NET, mas depois de algumas linhas de código , já é possível se familiarizar com o ambiente de desenvolvimento.

Essas atualizações só completam o que já existe, e no caso do VB 2010 associará a nova ferramenta ao novo trabalho.

Com relação as versões anteriores do framework(1.0/2.0) confesso que não tive que alterar em nada para migrar para 3.0/3.5.

Agora o ponto principal. Que versão comprar ?

Amigo isso é como carro, eu cai na bobeira de comprar um ZERO que já tinha uma versão mais nova(PALIO), alguns meses depois eu já estava querendo trocar de carro.

Sugiro que você utilize as versões de teste para ir se familiarizando com o ambiente, e assim que disponível você pode comprar a versão mais atualizada.

 

 

Coordinator
May 30, 2009 at 11:16 PM

Luis, enquanto eu redigia o post vc editou o seu (rsrsrsrs).

Só completando o raciocícnio...

Se uma tecnologia evolui é sinal de progresso, consequentemente acompanha a tendência do mercado.

Diferentemente disso , o VB6 estagnou no SP6(se não me engano) e ficou para trás.

Estou desenvolvendo em VB.NET a pouco mais de um ano, e confesso que passei mais de 8 meses ensaiando para migrar, se eu soubesse que seria tão fácil me adaptar com a nova tecnologia teria migrado em 2002/2003.

A mesma coisa foi migrar de SGBD. Exitava ao máximo migrar de ACCESS para MySQL, quando resolvi migrar percebi que já deveria ter migrado há muito tempo.

 

Developer
Jun 4, 2009 at 1:36 PM
Edited Jun 4, 2009 at 7:12 PM

Editado depois de postado (Complementando)

Bem amigos, continuando sobre o assunto (MSIL)  ou IL, Microsoft Intermediary Linguage do .Net, segue um link que explica isso: http://www.macoratti.net/vbn5_pco.htm

http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.br.dotnet&tid=bc6fcd7d-1e73-4b3a-87b1-b7c574a2041d&cat=pt_BR_3730dcb8-4891-47ca-bfff-31fd2cb87f88&lang=pt&cr=BR&sloc=&p=1

O detalhe é que a Microsoft instituiu realmente a engenharia reversa em sua plataforma, apesar dos ofuscadores comentados, ele só tem função real para usuários leigos e desenvolvedores como nós, pois para um Hacker ou programadores Assembler isso é igual um brinquedo lego para crianças de 4 anos.

Sendo assim será que realmente há tantas empresas empenhadas com a plataforma .Net?
Será que ninguém mais se importa com a propriedade de seus códigos fonte ou se vão copiá-la?
O tempo e investimento gasto no desenvolvimento de aplicações não tem importância?

Fiz uma colocação a este respeito no post inicial deste tópico, mas ninguém respondeu. Será que é possível gerar uma compilação final em nosso micro antes de enviar ao cliente? Assim não disponibilizariamos a IL e sim o EXE final realmente compilado. Porém como isso seria feito? Será que bastaria executar o aplicativo depois de gerada a IL e ir abrindo/rodando cada rotina do mesmo? Como isso iria funcionar para usar com o ClicOnce?

Será que eu sou o único preocupado com este assunto?
Nota: Esse foi o único e real motivo para eu ter relutado tanto em migrar do VB6 para o .Net. Porém agora decidi migrar, mas voltou essa "Neura", pois correr o risco de perder 10 anos de trabalho só por mudar de linguagem? O engraçado é que nenhuma ferramenta da Microsoft é fornecida para nós dessa forma, ou seja, tudo deles é 100% fechado (compilado 100%), se isso é tão bom assim, porque não fazem o mesmo com os produtos deles?

Resposta:
Agora vejo que não, fui pesquisar no google e acabei encontrando um monte de tópicos sobre o assunto. A maioria datada entre 2001 e 2005, e parece que muita gente já estava se dando conta dessa Vulnerabilidade de plataforma dotNet e por isso também relutando bastante em migrar.

Verifiquei que muitas empresas que estão migrando para dotNet NÃO SABEM dessa vulnerabilidade, pois seguem apenas o que o marketing forte da Microsoft prega e o lado bom da tecnologia, praticidade, atualizações fáceis. o dotNET segue a mesma linha do JAVA com linguagem de metadata e por isso deixam as aplicações vulneráveis.

O fato de terem softwares desenvolvidos, como já citado, para ofuscar e vejam que a palavra é bem coerente "Ofuscar" vem de prejudicar momentaneamente a vista, então a princípio dá uma certa confundida em quem quer analisar o código, mas depois que os olhos acostumam, ou se for bom mesmo em programação, conseguirá passar por cima desses ofuscadores do mercado.

Pelo que andei lendo, esse assunto parece que "Caiu no esquecimento" após 2005, pois o VS 2005 continuou com o mesmo programa disponível na versão 2003. Na versão 2008 ainda não encontrei nada a respeiro, o que me leva a crer que essa tecnologia dotNet não estará sendo levada a sério pelos desenvolvedores de aplicações importantes, somente de empresas que ainda não se deram conta do problema ou de pequenos desenvolvedores. Quem sabe disso deve estar usando outras linguagens menos vulneráveis.

Só como comentário: Parece que existem centenas de programas para isso. Os free tem confiabilidade muito duvidosa, já os pagos, além de caríssimos para algo que deveria ser nativo da linguagem, também não são seguros como já dito. Os valores variam muito, porém um que verifiquei custa 1.300 Euros.

Gostaria da opnião dos colegas, pois só vejo como este projeto evoluar com a participação de todos.

Coordinator
Jun 5, 2009 at 4:12 AM
Edited Jun 5, 2009 at 4:13 AM

Neste artigo http://www.macoratti.net/vbn_dcp.htm o Macoratti apresenta uma ferramenta que permite decompilar um código MSIL para C#.

Quero destacar algumas partes do texto. Segue abaixo...

 


 

Você pode então usar o Anakrino para aprender como seus assemblies serão expostos e também para espiar os assemblies de outras fontes. É claro que existe uma forma de impedir a decompilação e muitas empresas vão querer proteger sua propriedade intelectual.

Minha missão foi então mostrar a você que existe uma ferramenta que você pode usar para decompilar assemblies em C#. Fica por sua conta e risco sua utilização.  (O Anakrino esta completo no Super CD.NET )

Ah !!! existe outro decompilador para a plataforma .NET - Salamander .NET Decompile - que converte arquivos EXE ou DLL de linguagem intermediária  (IL , MSIL , CIL) no formato binário para um código fonte em linguagem de alto nível como C# , VB .NET , etc.  Não é gratuíto e eles também vendem um ofuscador de código.


Bom, o ideal é continuar buscando informações na Web.

 

 

Developer
Jun 5, 2009 at 12:08 PM
Edited Jun 5, 2009 at 12:21 PM

Tecla ao meu ver a Microsoft parece ter tratado a comunidade de desenvolvimento como "Bando de Moleques". Criar uma plataforma sem segurança nos dias de hoje é burrice, pior é quem não consegue ver isso.

Tenho lido sobre dezenas de programas gratuitos para decompilação (verdadeira) de 100% de códigos no dotNet, agora aparece um pago? Parece brincadeira de mau gosto.

Então essa "empresa", pois não sei se é empresa mesmo ou alguém que tem um site e fez isso em casa, deixando mais dúvidas do que certeza sobre sua eficiência, tem uma versão paga para ver o código alheio e também uma versão para proteger? Além da péssima aparência deste site, para um produto comercializado e que não é barato (aproximadamente R$ 1.600,00), nós ainda teríamos que fazer inúmeros testes para avaliar se realmente isso irá funcionar corretamente, pois como existem dezenas de decompiladores, esse Salamander pode não quebrar sua própria segurança e seria um absurdo se não fizesse isso, mas será que os demais não conseguem? Para saber só testando todos, pois nesse assunto acho que tem mais "Conversa para boi dormir" do que material eficaz e idôneo. Virou uma terra de ninguém e todos querendo ganhar as custas do desenvolvedor. Isso já ultrapassou a chamada "Venda Casada" e virou "Venda Compulsória" como o governo gosta de chamar quando toma nosso dinheiro na "mão grande".

Mal comparando seria como se a Microsoft estivesse vendendo um Super Carro Novo, com motor V 1.000 cilindradas todo equipado de última geração, porém sem freios (segurança do código), se você comprar é obrigado a comprar o freio (ofuscadores) separadamente e com qualidade duvidosa. Se não comprar amigo boa sorte na hora de parar seu carro (lançar seu software no mercado) o desastre pode ser fatal.

Estou muito descontente com isso, é como se a plataforma dotNet estivesse "Matando" a criação de softwares protegidos ou a propriedade intelectual do desenvolvedor, ou pior ainda, inviabilizando o investimento em desenvolvimentos novos.

Não cheguei a entender direito algumas partes do texto desse site, e infelizmente por enquanto não tenho condições de avaliar tal ferramenta, não só pelo que diz fazer mais testar sua segurança com os outros decompiladores também. O mais engraçado disso é que aparentemente após 2005 os posts sobre esse assunto parecem ter desaparecido da Web, porque será? Como disse será que o mundo abandonou o dotNet em função disso? Será que as empresas estão tão envolvidas em codificar que ainda não se "tocaram" no tamanho do problema? Ou será que decidiram aceitar passivamente a imposição da Microsoft, acatando sua nova plataforma e deixando seus códigos a qualquer sorte no mercado?

Agora imagina ter de comprar uma licença VS 2008 (R$ 2.500,00) e mais uma licença Salamander (R$ 1.600,00) ou outro qualquer como uma européia de um ofuscador que parece não resolver nada como os demais por (R$ 3.000,00) e a cada atualização do Visual Studio teria de comprar novas licenças de ambos os programas para sempre estar "protegido".

Só para acompanhamento pelos amigos, sou uma pessoa muito crítica e questionadora. Procuro alternativas para todas as situações, isso em qualquer assunto da minha vida. Nesse ponto não poderia ser diferente, então tenho pensado em formas para contornar o problema, e a cada solução que encontro, acabo esbarrando em outros problemas igualmente maiores. Estou trocando idéias com o ICEMAN do VBM também, sobre algum caminho para tentar seguir. A princípio parece não ter muita solução ainda, pois todas as alternativas que encontramos tem seus efeitos colaterais de igual monta, ex:

Solução 1
Pensei em após gerar o MSIL executar o código tela por tela, função por função no meu micro, e distribuir a versão 100% ou quase totalmente compilada realmente.
Problema
Imagine o trabalho monstruoso rodar cada rotina de um sistema mais complexo com 100 telas e 200 classes, 100 funções, etc...?
Agora imagina distribuir e seu cliente encontrar um bug, como que acontece frequentemente ou então pedir um novo recurso, campo ou tela no projeto, vai recompilar e novamente executar tudo novamente antes de distribuir.
Conclusão INVIÁVEL

Solução 2
Desenvolver em 3 camadas, colocando as regras de negócio no servidor e só telas no front and.
Problema 1
Suas DLLs da segunda camada ficariam no servidor do cliente, só que as DLLs são tratadas igual aos EXE no dotNet, assim ficando desprotegidas até sua primeira execução também.
Problema 2
Suas Dlls ficariam num servidor Web seu, além do custo de hospedagem e segurança deste seu website, você teria o custo de tráfego na rede, e que convencer seu cliente de ficar com a aplicação dele hospedada em um site que não é dele e sem o controle dele.
Problema 3
O cliente ficaria preso a Web, se não tiver condições de deixar todos os funcionários 100% plugados, além de problemas de lentidão etc... ainda correria o risco de ficar sem o sistema caso ocorra problemas de conexão o que em São Paulo com o Speedy está se tornando comum em algumas regiões.
Conclusão INVIÁVEL

Solução 3
Colocar todas as regras de negócio de sua aplicação (parte que deve ser protegida) em OCX´s.
Problema 1
As OCX pelo que eu saiba são legado do VB 6 e trabalham na COM e não são mais criadas no dotNet, apesar de suportadas. Isso implica em registro de controles o que não existe mais na plataforma dotNET já que tudo é só copiar e colar, simplificando as instalações e atualizações de aplicativo, bem como eliminando conflito de versões. Assim você continuaria tendo complicações nas suas instalações e compilações, não sei até que ponto ocorreriam problemas.
Problema 2
As OCX teriam de continuar sendo desenvolvidas em VB6 e o resto da aplicação em dotNET. Isso parece absurdo e improdutivo, sem contar na dificuldade de integração das tecnologias.
Problema 3
A manutenção de uma aplicação seria muito mais complicada, imagina identificar em que parte do sistema um bug ocorreu no cliente, se no dotNet, no OCX ou na integração das duas tecnologias?
Conclusão: INVIÁVEL

Bem o texto já está monstruoso, mas finalizando por enquanto:
Sobre a plataforma dotNet acredito que é ótima por todos os novos recursos, mas para aplicações comerciais acredito que não seja viável enquanto a Microsoft não resolver definitivamente esse problema e oferecer uma solução integrada e nativa ao Visual Studio para resolver esse problema de forma 100% eficaz.

Sobre utilizar outras plataformas, se pensarmos em soluções Web como PHP, ASP etc... teremos outros problemas para enfrentar também além de mudar de desktop para web, como: Aumento na segurança, tando do seu código no servidor Web como nos ataques de hascker e na segurança dos dados de seus clientes. Na possível lentidão das aplicações pelo constante enviar e receber dados e páginas no browser o que para aplicações com grande volume de acessos complica para o usuário, principalmente quem tratalha com atendimento ao público e não pode perder tempo esperando carregamento de telas, exemplo as agências do correio onde para enviar uma carta perdemos mais de 10 minutos. só no guichê, não digo na fila não que isso passa de 1 hora. Faço isso toda semana e sei bem como é, sistemas super lentos.

Continuar com VB6, apesar de parecer a melhor opção, não temos como saber até quando a sobrevida dele continuará. Estão falando da compatibilidade 100% de aplicativos Windows XP com o novo Windows 7 (lançamento no final deste ano), a princípio é a melhor notícia, mas até quando? Um outro problema disso é que não se encontra licenças do Vb 6 para comprar. Estou a procura de uma a muito tempo, pago em dinheiro desde que legalizada, com mídias, manuais e Nota Fiscal, mas ainda não consegui.

Vender lanches e bebidas num quiósque na Praia, "Tem Coisas que o Dinheiro Não Pode Comprar" (risos). Pode ser uma opção, largar a dor-de-cabeça do desenvolvimento e viver a vida na praia, com uma barraquinha atendendo turístas e VIVA a VIDA na NATUREZA!

Desculpem mas precisava terminar o post em ALTO ASTRAL.

Developer
Jun 5, 2009 at 2:05 PM

Só completando informações sobre dotNet. Conversando hoje com um conhecido, ele havia iniciado a migração de sua aplicação (complexa) para vb 2008, porém após 6 meses parou e voltou a implementar no VB6.

Os argumentos:

- a demora na implementação do código, assimilação dos recursos para migração

- o maior problema, a lentidão do dotNET. No VB6 fazia o carregamento e exibição de 20 mil registros em tela em 5 segundos, no VB.net conseguia exibir 2 mil em 30 segundos. Os processos são lentos em demasia, exige micros muito potentes e mesmo assim o VB 6 supera em todos os itens relativos a performance.

- Agora associando a segurança dos fontes piorou.

Segundo ele, vários profissionais desistiram do dotNet, porém a Microsoft continua forçando por imposição sua tecnologia, sem atentar para as reais necessidades de seus clientes (os desenvolvedores) e dos usuários finais (nossos clientes).

Esses podem ser os motivos pelos quais não se vê muitos posts mais sobre segurança do dotNET, pois devem existir poucos usuários dele no momento, só que isso não é informado.

Um outro reflexo disso é que aqui no Brasil é difícil encontrar o VS net para vender, só encontrei 2 lojas virtuais grandes de São Paulo capital que tem. Porque será não?

Developer
Jun 8, 2009 at 1:54 PM

Abordando OOP

Como o dotNet, também estou iniciando o estudo de OOP ou POO como quiserem (Programação Orientada a Objetos), porém tenho uma série de dúvidas. Como isso funciona na prática com um sistema de banco de dados.

Gostaria de entender como se cria essa estrutura num programa com os dados do banco, ex:

Com uma tabela Funcionários, relacionada com tabela departamentos, tabela cargos e tabela telefone por exemplo (forma simples).

tabFuncionarios (IDFunc, Nome, IDDepto, IDCargo, DtAdmissao, Sexo, etc...)
tabCargos (IDCargo, Titulo, Experiencia, Revisao, etc....) aqui há vinculos com outras tabelas, (Idiomas, Atitudes, etc...)
tabDepartamentos (IDDepto, Nome)
tabTelefones (IDFone, IDFunc)

Como se montaria as classes para usar os objetos Funcionários em nossos forms, nas consultas, inclusões, etc... não estou conseguinto visualizar isso em codificação.

Nota: Hoje em VB6 tenho de carregar um recordset (ADO), e depois atribuir um a um dos dados nos campos do form. Não há uma estrura básica geral, cada formulário tem a sua codificação. Para acessar cada informação, tenho de recorrer ao nome dos campos. Pelo que andei lendo de OOP, é criada uma estrutura (CLASSE) funcionários e em qualquer parte do projeto o objeto instanciado Funcionário pode ser acessado assim:

Funcionario.Nome
Funcionario.DtAdmissao
Etc...

Coordinator
Jun 8, 2009 at 3:55 PM

No .NET, este recurso ao qual se referiu chama-se DataSet Tipado (também existe o DataSet Não-Tipado).

A vantagem do DataSet, é que o mesmo trás o novo conceito Desconectado da base de dados.

Não sei se já começou a estudar a classe de dados ADO.NET, pois nesta existem alguns conceitos específicos, além de novas maneiras de se comunicar com um banco de dados. Seguem algumas classes que compõem o ADO.NET.

IDbConnection: Classe responsável por gerenciar a conexão com a base de dados

IDbCommand: Classe que encapsula um comando SQL (INSERT, SELECT, UPDATE, DELETE além de passagens de parâmetros para Store Procedures)

IDbReader: Semelhante a um Recordset do ADO, mas só permite a leitura para frente dos registros (uma espécie de MoveNext sem MovePrevious).

Na prática, já consigo utilizar um pouco a classe IDbReader e algumas rotinas com DataSet.

Fui!

Developer
Jun 8, 2009 at 10:49 PM

OOP

Tecla então não dá para se trabalhar como com ADO comum, onde se criava um recordset com um Select todo relacionado? Agora é preciso criar sempre a estrutura de relacionamento (tabelas) em memória para cada formulário que se vai trabalhar?

Eu sempre puxava somente um registro por vez, só o que se precisava trabalhar, a menos que fosse para exibir num grid, então eu trazia um grupo de registro, ao selecionar a linha do grid, povoava os campos, alterava se necessário e gravava (update) só esse registro que nem tinha mais o recordset carregado, pois sempre trabalho desconectado. Então fico pensando, será que vou ter de baixar todos os dados do banco sempre que carregar um form? Isos não aumenta em muito o fluxo de dados na rede e acessos ao banco? Não entendi qual a vantagem disso nessa nova tecnologia?

OFUSCADORES

Continuando minhas pesquisas, encontrei algo que fiquei até surpreso. O tópico da pesquisa era ofuscador, mas trouxe isso http://nqk18469.blogspot.com/2009/05/editando-o-magicantileech-v5.html
um link para ensinar a usar o Visual Studio 2008 Pro para editar um programa chamado MagicAntiLeech v5 . Não sei se entendi direito, mas acho que foi para liberar o programa, será que ví direito? Minha nossa!

Tentei entrar no site do ofuscador que vem com o VS 2008, acho que é esse o link pelo nome do programa http://www.dotfuscator.com/ porém não consegui entender nada nele. Tem 3 versões, alguém consegue descobrir para que cada uma serve? Não encontrei nenhuma informação sobre preço no site, nem dados mais concretos sobre o programa.

Nesse link do MSDN há uma relação de Ofuscadores e Decompiladores para dotNet. Eu ainda não tenho condições de realizar uma avaliação dessas ferramentas, pois sinceramente não sei quase nada de dotNet ou VS 2008, mas quem puder fazer uma análise de cada software e avaliar qual o melhor, e se descobrir outros na web diferentes. http://msdn.microsoft.com/pt-br/vcsharp/aa336818.aspx

Developer
Jun 3, 2010 at 9:33 PM

Continuando nossa saga do "pontapé inicial", nesse tópico todos os itens continuam válidos, pois as "lebres" foram levantadas, mas nenhuma solução foi postada.

A única coisa que deu uma pequena esperança contra ofuscadores, foi a sugestão do Tecla em MP no VBM, que sugeriu sempre incluir todas as regras de negócio dentro de DLLs. Porém estas DLLs terão de ser compiladas não para MIL mas para código binário direto, se isso for possível, pois segundo o texto publicado acima do Macoratti, tais ofuscadores podem reverter não só EXE mas DLL também.

Amigos quem for achando material explicativo e alternativas viáveis e testadas para solucionar os problemas abordados nesse tópico, favor postar aqui.