TRANSFERÊNCIA DE CONSULTA
é O SEGUINTE...
ESTOU APRENDENDO VB AINDA, MAIS POR HOBBY, CREIO QUE PARA VOCES ISSO SERIA MOLEZA...
TENHO 2 FORMS
- LANÇAMENTO DESPESAS
- CONSULTA DESPESAS
* ESTOU USANDO O aCESS COMO BANCO E CONECÇÃO DATACONTROL.
ATE AI TUDO BEM.
GOSTARIA QUE QUANDO EU CLICASSE NO BOTÃO OK DO FORM [Ô]CONSULTA DESPESAS[Ô]
ELE TRANSFERISSE OS DADOS DA CONSULTA REALIZADA PARA OS CAMPOS DO FORM [Ô]LANÇAMENTO DESPESAS[Ô]
TENTEI ASSIM, MAS NÃO ACHEI O MéTDODO PROFISSIONAL.
command1_click()
data1.recordset.fileds![Codigo] = frmLancamento_despesas.text1.text
etc...
etc...
end_sub
ESTOU APRENDENDO VB AINDA, MAIS POR HOBBY, CREIO QUE PARA VOCES ISSO SERIA MOLEZA...
TENHO 2 FORMS
- LANÇAMENTO DESPESAS
- CONSULTA DESPESAS
* ESTOU USANDO O aCESS COMO BANCO E CONECÇÃO DATACONTROL.
ATE AI TUDO BEM.
GOSTARIA QUE QUANDO EU CLICASSE NO BOTÃO OK DO FORM [Ô]CONSULTA DESPESAS[Ô]
ELE TRANSFERISSE OS DADOS DA CONSULTA REALIZADA PARA OS CAMPOS DO FORM [Ô]LANÇAMENTO DESPESAS[Ô]
TENTEI ASSIM, MAS NÃO ACHEI O MéTDODO PROFISSIONAL.
command1_click()
data1.recordset.fileds![Codigo] = frmLancamento_despesas.text1.text
etc...
etc...
end_sub
GIOGOMES,
O DataControl por si só não é profissional. O Access também não é o que eu chamo de profissional.
O certo é usar o ADO e se conectar a base de dados, trabalhar com o sistema em três camadas (sendo a camada DAL {Data Access Layer} de acesso aos dados), etc.
Se você não programa profissionalmente, não precisa se preocupar com nada. A não ser se sua performance de BD estiver muito ruim mesmo.
[][ô]s,
Tunusat.
O DataControl por si só não é profissional. O Access também não é o que eu chamo de profissional.
O certo é usar o ADO e se conectar a base de dados, trabalhar com o sistema em três camadas (sendo a camada DAL {Data Access Layer} de acesso aos dados), etc.
Se você não programa profissionalmente, não precisa se preocupar com nada. A não ser se sua performance de BD estiver muito ruim mesmo.
[][ô]s,
Tunusat.
Citação::
GIOGOMES,
O DataControl por si só não é profissional. O Access também não é o que eu chamo de profissional.
O certo é usar o ADO e se conectar a base de dados, trabalhar com o sistema em três camadas (sendo a camada DAL {Data Access Layer} de acesso aos dados), etc.
Se você não programa profissionalmente, não precisa se preocupar com nada. A não ser se sua performance de BD estiver muito ruim mesmo.
[][ô]s,
Tunusat.
assim como o vb também não é profissional.
GIOGOMES,
O que não é profissional é a maneira de programar em VB (VB6 e VB.Net) e não a ferramenta em si. Se você quiser fazer um programa sem profissionalismo, desrespeitando conceitos de camadas, desrespeitando acesso ao banco de dados, deixando tudo desprotegido, pode fazer isto até em JAVA. Já vi um programador experiente em JAVA ter medo de fazer manutenção em determinado sistema pois estava, segundo ele, com a estrutura da base da programação totalmente errada. Usava um framework de maneira incorreta. Na verdade em JAVA é mais fácil fazer péssimos sistemas do que em VB6, pois o VB6 funciona até em baixo dágua! KKKKK! Pelo menos até o Windows 8...
100% dos programas que fiz manutenção na minha vida escritos em VB6 foram escritos da forma monolÃtica.
Estudei Análise de Sistemas e em momento algum da matéria de programação aprendi a programar em 3 camadas.
O que eu sempre digo: No Brasil TUDO é muito caro e subdimensionado (para maximizar os lucros). O problema maior é que todos aceitam isto naturalmente.
[][ô]s,
Tunusat.
O que não é profissional é a maneira de programar em VB (VB6 e VB.Net) e não a ferramenta em si. Se você quiser fazer um programa sem profissionalismo, desrespeitando conceitos de camadas, desrespeitando acesso ao banco de dados, deixando tudo desprotegido, pode fazer isto até em JAVA. Já vi um programador experiente em JAVA ter medo de fazer manutenção em determinado sistema pois estava, segundo ele, com a estrutura da base da programação totalmente errada. Usava um framework de maneira incorreta. Na verdade em JAVA é mais fácil fazer péssimos sistemas do que em VB6, pois o VB6 funciona até em baixo dágua! KKKKK! Pelo menos até o Windows 8...
100% dos programas que fiz manutenção na minha vida escritos em VB6 foram escritos da forma monolÃtica.
Estudei Análise de Sistemas e em momento algum da matéria de programação aprendi a programar em 3 camadas.
O que eu sempre digo: No Brasil TUDO é muito caro e subdimensionado (para maximizar os lucros). O problema maior é que todos aceitam isto naturalmente.
[][ô]s,
Tunusat.
GIOGOMES
você colocou assim
data1.recordset.fileds![Codigo] = frmLancamento_despesas.text1.text
e o correto é inverter isso assim
frmLancamento_despesas.text1.text = Data1.Recordset.Fields([Ô]codigo[Ô])
você está aprendendo ainda então da forma que esta fazendo esta bom demais, porém quando pensar em algo para comercializar ai sim mude seus conceitos.
você colocou assim
data1.recordset.fileds![Codigo] = frmLancamento_despesas.text1.text
e o correto é inverter isso assim
frmLancamento_despesas.text1.text = Data1.Recordset.Fields([Ô]codigo[Ô])
você está aprendendo ainda então da forma que esta fazendo esta bom demais, porém quando pensar em algo para comercializar ai sim mude seus conceitos.
GIOGOMES:
Olhando especificamente o que você pede, o DataControl possui uma propriedade que é ao mesmo tempo um objeto: A propriedade Recortdset.
Esse objeto pode ser [Ô]passado[Ô] entre formulários que já estejam ambos instanciados (Set Form1.DataControl1.Recordset Form2.DataControl1.Recordset), assim como pode ser [Ô]passado[Ô] para uma variável global (ou pública) do tipo Recordset do aplicativo, para ser posteriormente utilizado por outros formulários, dependendo de como se dá a carga inicial dos dados.
Mas formulários são, mesmo no VB6, ao contrário do que muitos acham, classes, que possuem uma instância e que estão prototipados na coleção Forms do aplicativo. Assim, ao encerrar efetivamente uma instância de formulário, um Recordset de um Datacontrol perde seu ponteiro e não é mais possÃvel utiliza-lo.
Mas lembre-se de que o VB6 não [Ô]mata[Ô] automaticamente uma instância de formulário que tenha sido carregado á partir da coleção Forms, isto é, se você tem um formulário chamado Form1 e, por exemplo, no evento Click de um item de menu, usa um [Ô]Form1.Show[Ô] para mostrar o formulário, a instância desse formulário não será descarregada quando você [Ô]fechar[Ô] o mesmo, pois ele permanence na coleção Forms, apenas não está mais ativo. E com isso, como cada Datacontrol possui uma conexão própria com a base/fonte de dados, essa conexão permanecerá ativa mesmo após o encerramento do formulário.
é por essa razão que os programadores costumam não se utilizar desses (e outros) componentes, pois apesar de serem práticos, exigem um cuidado maior, então são um bom recurso para criar um layout básico para apresentar uma idéia, mas não são ideais para um projeto real.
O ideal, portanto, para o seu caso de hobbista, não é se ater á instância do DataControl ou do objeto Recordset que ele possui, mas sim ao texto contido na propriedade Source desse Recordset. Por ser um texto e não um objeto, não [Ô]pesa[Ô] tanto e pode ser mantido por uma variável pública do tipo String para ser utilizada em outros pontos do aplicativo. Ao encerrar o formulário, no evento Form_Closing, você atribui esse texto da propriedade Source á sua variável global, e no evento Form_Load de outro formulário, poderá então ler esse valor e passar á outro DataControl.
* Como saber se uma conexão está ativa (conectada) á base MS-Access, sem usar o Immediate Windows, já que o Form1 não está mais visÃvel e eu não consigo obter a propriedade ? Basta olhar a pasta onde o arquivo está gravado: Caso um arquivo de mesmo nome, com uma extensão diferente, esteja lá, a conexão está ativa.
Olhando especificamente o que você pede, o DataControl possui uma propriedade que é ao mesmo tempo um objeto: A propriedade Recortdset.
Esse objeto pode ser [Ô]passado[Ô] entre formulários que já estejam ambos instanciados (Set Form1.DataControl1.Recordset Form2.DataControl1.Recordset), assim como pode ser [Ô]passado[Ô] para uma variável global (ou pública) do tipo Recordset do aplicativo, para ser posteriormente utilizado por outros formulários, dependendo de como se dá a carga inicial dos dados.
Mas formulários são, mesmo no VB6, ao contrário do que muitos acham, classes, que possuem uma instância e que estão prototipados na coleção Forms do aplicativo. Assim, ao encerrar efetivamente uma instância de formulário, um Recordset de um Datacontrol perde seu ponteiro e não é mais possÃvel utiliza-lo.
Mas lembre-se de que o VB6 não [Ô]mata[Ô] automaticamente uma instância de formulário que tenha sido carregado á partir da coleção Forms, isto é, se você tem um formulário chamado Form1 e, por exemplo, no evento Click de um item de menu, usa um [Ô]Form1.Show[Ô] para mostrar o formulário, a instância desse formulário não será descarregada quando você [Ô]fechar[Ô] o mesmo, pois ele permanence na coleção Forms, apenas não está mais ativo. E com isso, como cada Datacontrol possui uma conexão própria com a base/fonte de dados, essa conexão permanecerá ativa mesmo após o encerramento do formulário.
é por essa razão que os programadores costumam não se utilizar desses (e outros) componentes, pois apesar de serem práticos, exigem um cuidado maior, então são um bom recurso para criar um layout básico para apresentar uma idéia, mas não são ideais para um projeto real.
O ideal, portanto, para o seu caso de hobbista, não é se ater á instância do DataControl ou do objeto Recordset que ele possui, mas sim ao texto contido na propriedade Source desse Recordset. Por ser um texto e não um objeto, não [Ô]pesa[Ô] tanto e pode ser mantido por uma variável pública do tipo String para ser utilizada em outros pontos do aplicativo. Ao encerrar o formulário, no evento Form_Closing, você atribui esse texto da propriedade Source á sua variável global, e no evento Form_Load de outro formulário, poderá então ler esse valor e passar á outro DataControl.
* Como saber se uma conexão está ativa (conectada) á base MS-Access, sem usar o Immediate Windows, já que o Form1 não está mais visÃvel e eu não consigo obter a propriedade ? Basta olhar a pasta onde o arquivo está gravado: Caso um arquivo de mesmo nome, com uma extensão diferente, esteja lá, a conexão está ativa.
Demais colegas em geral:
O colega GIOGOMES foi claro em seu tópico: Ele não é programador, é um hobbista. Provavelmente gosta de informática, busca conhecimentos relacionados e não tem a pretenção de alçar vôos muito maiores, senão a própria diversificação de conhecimentos, o que é algo excelente para qualquer pessoa.
Dessa forma, não faz sentido olharmos sua codificação com a expectativa de encontrarmos algo mais [Ô]profissional[Ô]. E, para todo e qualquer efeito, é sempre bom lembrar que TODAS as linguagens de programação são tão profissionais quanto quanto a lógica de quem as utiliza, nem mais, nem menos.
E já que enveredei nesse caminho, devo acrescentar alguns dados interessantes.
Segundo algumas pesquisas recentes, o tópico [Ô]programação[Ô] é uma das questões centrais, um [Ô]problema[Ô] que está na evolução das Ciências da Computação e do Processamento de Dados, onde a especialização segue um ritimo mais acelerado do que aquele [Ô]ritimo natural[Ô] de evolução das sociedades. Seguindo a cronologia, temos o seguinte:
- Até a década de 80 (1940-1979), programadores eram na verdade engenheiros eletrônicos, especializados, caros e portanto disponÃveis para poucas empresas.
- Na primeira metade da década de 80, com o advento da micro-informática e principalmente do PC da IBM, criou-se a idéia de que todos podiam aprender como programar, bastando-lhes o acesso ao conhecimento de uma linguagem de programação. BASIC, BASICA, QuickBasic, Cobol, Clipper, Pascal e tantas outras, foram implementadas para o PC, mas ainda havia um baixo interesse das pessoas em geral em aprender [Ô]uma segunda lÃngua[Ô] e [Ô]ficar fechado numa sala, recebendo a pizza por baixo da porta[Ô] como profissão.
- Na segunda metade da década de 80, com as plataformas gráficas como o Windows, percebeu-se que o foco em uma linguagem não estava dando os resultados esperados, e apostou-se na criação de ferramentas do tipo [Ô]arrastar-e-colar[Ô], as quais, em teoria, dariam mais liberdade aos desenvolvedores para que focassem mais na lógica e perdessem menos tempo com sintaxes.
- Nos anos 90, com o advento da Intenet de Massa, essas ferramentas se diversificaram e se especializaram, mas se percebeu que mesmo elas não haviam dado o resultado esperado: Não haviam muito mais bons programadores do que antes! O que estava errado? Depois de algum estudo, verificou-se que o problema já não era mais em [Ô]decorar[Ô] linguagens de programação, mas em ser capaz de criar uma lógica de negócio que fosse viável para a automação. Assim, a maioria das linguagens passou á oferecer siporte á OOP, onde então seria possÃvel aos desenvolvedores criarem objetos que se assemelhassem mais à queles aos quais o [Ô]jargão[Ô] do negócio estava acostumado. Em outras palavras, seria possÃvel criar um objeto [Ô]Cliente[Ô], um objeto [Ô]Pedido[Ô], um objeto [Ô]Produto[Ô] e assim por diante.
- Nos anos 2000, viu-se que as mesmas ferramentas gráficas que [Ô]libertavam[Ô] os programadores da sintaxe passavam a falsa impressão de que a OOP era descartável. Ainda nessa década, constatou-se que mesmo com toda a evolução decorrida, o número de bons programadores não havia aumentado, e então as empresas passaram á oferecer ferramentas como as de ORM, á partir das quais os programadores poderiam inferir objetos á partir de bases de dados, simplificando a OOP para aqueles que não conseguiam entender bem esse processo.
- Na década atual, o que ficou constatado é que,independente de quão evoluÃda seja uma ferramenta ou um conjunto de ferramentas, a idéia de que [Ô]todos poderão aprender programação[Ô] é falsa, e que na verdade, apenas 6 em cada 1000 pessoas conseguem efetivamente abstrair lógicas de negócio. Com esse [Ô]novo[Ô] fato, as empresas passaram á focar as ferramentas de abstração, como o NHibernate e a Entity Framework como parte do ferramental, aprofundando a separação entre lógica, dados e aplicativo. Assim, conceitos (ou metodologias, ou modelos) como o MVVM e o MVC vêm se desenvolvedo e evoluindo, e ao mesmo tempo em que [Ô]forçam[Ô] uma parte dos desenvolvedores à pensar nas lógicas de negócio, dão liberdade aos designers para criarem interfaces de usuário sem [Ô]esquentar a cuca[Ô] com bancos de dados e aos DBAs a possibilidade de não se depararem com [Ô]elefantes brancos[Ô]. Agora, portanto, cientes de que uma única pessoa não será aquela que efetivamente cria uma aplicação complete de ponta á ponta: Ela depende de um grupo de trabalho. E com isso, as empresas passaram á difundir os repositorios de códigos e as IDEs de programação colaborativas.
Não se trata de dizer que você, eu, o TUNUSAT ou qualquer outro não vamos conseguir abrir um novo projetinho, criar um cadastro básico ou um site [Ô]completo[Ô] MVC: Vamos, sim. Mas não será uma aplicação corporativa, por mais que tentemos, o que sairá após alguns poucos meses de trabalho. Será uma aplicação pequena, focada e especÃfica. Caso tentemos ir adiante, além desse ponto, nossos prazos terão de ser revistos e nossos conhecimentos técnicos, revisitados com freqüência, até a finalização.
Não é porquê não sejamos capazes ou porquê sejamos incompetentes, mas sim porquê o conjunto de conhecimentos técnicos de uma interface de usuários excelente não é o mesmo conjunto de conhecimentos requeridos para uma implementação de dados otimizada e não é o mesmo conjunto que resume os conhecimentos de negócio de nosso cliente. E cada um desses conjuntos segue evoluindo constantemente, em separado. Por exemplo, o HTML e o HTML5, o AJAX e o jQuery, o CSS3/jQuery e o Twiter Boorstrap, a DAO e a atual Microsoft ADO.Net Enntity Framework Code First / Fluent API ou ainda, o MVC e o modelo Domain Driven Design.
Resumindo, não é questão de um código [Ô]ser profissional[Ô], é questão de um código ser criado apenas após a análise do negócio .
Se a aplicação é tão pequena/genérica que pode lidar com DataSets/Datatables/Recordsets especÃficos para cada formulário, não sendo frequente a troca de informações entre os formulários e nem a apresentação de grandes volumes de dados, como por exemplo um cadastro simples, uma agenda simples etc., o uso do DataControl é perfeitamente factÃvel.
Da mesma forma, se a aplicação possui uma pretenção um pouco maior, onde seja interessante manter coerente uma ou mais lógicas de negócio, como um controle de estoques por exemplo, ou mesmo uma agenda mais especializada, nestes casos será interessante separar interface de usuário, DAL, DAC, BLL etc., usando uma das muitas metodologias de desenvolvimento existentes, mas basicamente uma OOP.
Outra [Ô]confusão[Ô] que se costuma fazer, agora especificamente olhando para aqueles que usam OOP, é que [Ô]se eu tiver uma DAL, uma BLL e uma interface, eu tenho uma framework de negócio![Ô] Nada mais [Ô]por fora[Ô] do que isso: O simples fato de separar objetivos não significa que o desenvolvedor está utilizando um [Ô]pattern[Ô] adequado de desenvolvimento, mas pode significar que ele está, isto sim, [Ô]alimentando um dragão[Ô], que no fim vai acabar comendo o desenvolvedor.
Dessa forma, não se baseia apenas em uma linguagem de programação, se alguém pretende trabalhar profissionalmente nessa area.
No caso de gostar de lógica e de estar sempre em busca de novas formas de realizar as mesmas tarefas, buscar, isto sim, conhecimento de metodologias e de formas de aprimorar o tirocÃnio para urilizá-lo durante os processos de análise.
Ou, outra forma, se gosta de desenhar e de ser elogiado por seu bom-gosto, especializar-se na criação de interfaces de usuário, e dividir seus projetos com colaboradores que façam, por sua vez, a [Ô]caixa-preta[Ô] das camadas de lógica e de acesso á dados.
Resumindo, não existe mais a ilusão de que TODOS podem ser PROGRAMADORES. Ainda que essa ilusão não exista mais, o MERCADO disponibiliza ferramentas que proporcionam aos leigos fazerem MUITO MAIS hoje do que há 40 anos atrás, sem precisar pensar (vide o exemplo do WIX e outros). Neste tópico, o post mais objetivo, adequado e sucinto foi o MARCELO-TREZE, ao qual eu, se fosse o GIOGOMES, pontuaria ao encerrar o tópico, hehehe.
O colega GIOGOMES foi claro em seu tópico: Ele não é programador, é um hobbista. Provavelmente gosta de informática, busca conhecimentos relacionados e não tem a pretenção de alçar vôos muito maiores, senão a própria diversificação de conhecimentos, o que é algo excelente para qualquer pessoa.
Dessa forma, não faz sentido olharmos sua codificação com a expectativa de encontrarmos algo mais [Ô]profissional[Ô]. E, para todo e qualquer efeito, é sempre bom lembrar que TODAS as linguagens de programação são tão profissionais quanto quanto a lógica de quem as utiliza, nem mais, nem menos.
E já que enveredei nesse caminho, devo acrescentar alguns dados interessantes.
Segundo algumas pesquisas recentes, o tópico [Ô]programação[Ô] é uma das questões centrais, um [Ô]problema[Ô] que está na evolução das Ciências da Computação e do Processamento de Dados, onde a especialização segue um ritimo mais acelerado do que aquele [Ô]ritimo natural[Ô] de evolução das sociedades. Seguindo a cronologia, temos o seguinte:
- Na primeira metade da década de 80, com o advento da micro-informática e principalmente do PC da IBM, criou-se a idéia de que todos podiam aprender como programar, bastando-lhes o acesso ao conhecimento de uma linguagem de programação. BASIC, BASICA, QuickBasic, Cobol, Clipper, Pascal e tantas outras, foram implementadas para o PC, mas ainda havia um baixo interesse das pessoas em geral em aprender
- Na segunda metade da década de 80, com as plataformas gráficas como o Windows, percebeu-se que o foco em uma linguagem não estava dando os resultados esperados, e apostou-se na criação de ferramentas do tipo [Ô]arrastar-e-colar[Ô], as quais, em teoria, dariam mais liberdade aos desenvolvedores para que focassem mais na lógica e perdessem menos tempo com sintaxes.
- Nos anos 90, com o advento da Intenet de Massa, essas ferramentas se diversificaram e se especializaram, mas se percebeu que mesmo elas não haviam dado o resultado esperado: Não haviam muito mais bons programadores do que antes! O que estava errado? Depois de algum estudo, verificou-se que o problema já não era mais em [Ô]decorar[Ô] linguagens de programação, mas em ser capaz de criar uma lógica de negócio que fosse viável para a automação. Assim, a maioria das linguagens passou á oferecer siporte á OOP, onde então seria possÃvel aos desenvolvedores criarem objetos que se assemelhassem mais à queles aos quais o [Ô]jargão[Ô] do negócio estava acostumado. Em outras palavras, seria possÃvel criar um objeto [Ô]Cliente[Ô], um objeto [Ô]Pedido[Ô], um objeto [Ô]Produto[Ô] e assim por diante.
- Nos anos 2000, viu-se que as mesmas ferramentas gráficas que [Ô]libertavam[Ô] os programadores da sintaxe passavam a falsa impressão de que a OOP era descartável. Ainda nessa década, constatou-se que mesmo com toda a evolução decorrida, o número de bons programadores não havia aumentado, e então as empresas passaram á oferecer ferramentas como as de ORM, á partir das quais os programadores poderiam inferir objetos á partir de bases de dados, simplificando a OOP para aqueles que não conseguiam entender bem esse processo.
- Na década atual, o que ficou constatado é que,independente de quão evoluÃda seja uma ferramenta ou um conjunto de ferramentas, a idéia de que [Ô]todos poderão aprender programação[Ô] é falsa, e que na verdade, apenas 6 em cada 1000 pessoas conseguem efetivamente abstrair lógicas de negócio. Com esse [Ô]novo[Ô] fato, as empresas passaram á focar as ferramentas de abstração, como o NHibernate e a Entity Framework como parte do ferramental, aprofundando a separação entre lógica, dados e aplicativo. Assim, conceitos (ou metodologias, ou modelos) como o MVVM e o MVC vêm se desenvolvedo e evoluindo, e ao mesmo tempo em que [Ô]forçam[Ô] uma parte dos desenvolvedores à pensar nas lógicas de negócio, dão liberdade aos designers para criarem interfaces de usuário sem [Ô]esquentar a cuca[Ô] com bancos de dados e aos DBAs a possibilidade de não se depararem com [Ô]elefantes brancos[Ô]. Agora, portanto, cientes de que uma única pessoa não será aquela que efetivamente cria uma aplicação complete de ponta á ponta: Ela depende de um grupo de trabalho. E com isso, as empresas passaram á difundir os repositorios de códigos e as IDEs de programação colaborativas.
Não se trata de dizer que você, eu, o TUNUSAT ou qualquer outro não vamos conseguir abrir um novo projetinho, criar um cadastro básico ou um site [Ô]completo[Ô] MVC: Vamos, sim. Mas não será uma aplicação corporativa, por mais que tentemos, o que sairá após alguns poucos meses de trabalho. Será uma aplicação pequena, focada e especÃfica. Caso tentemos ir adiante, além desse ponto, nossos prazos terão de ser revistos e nossos conhecimentos técnicos, revisitados com freqüência, até a finalização.
Não é porquê não sejamos capazes ou porquê sejamos incompetentes, mas sim porquê o conjunto de conhecimentos técnicos de uma interface de usuários excelente não é o mesmo conjunto de conhecimentos requeridos para uma implementação de dados otimizada e não é o mesmo conjunto que resume os conhecimentos de negócio de nosso cliente. E cada um desses conjuntos segue evoluindo constantemente, em separado. Por exemplo, o HTML e o HTML5, o AJAX e o jQuery, o CSS3/jQuery e o Twiter Boorstrap, a DAO e a atual Microsoft ADO.Net Enntity Framework Code First / Fluent API ou ainda, o MVC e o modelo Domain Driven Design.
Resumindo, não é questão de um código [Ô]ser profissional[Ô], é questão de um código ser criado apenas após a análise do negócio .
Se a aplicação é tão pequena/genérica que pode lidar com DataSets/Datatables/Recordsets especÃficos para cada formulário, não sendo frequente a troca de informações entre os formulários e nem a apresentação de grandes volumes de dados, como por exemplo um cadastro simples, uma agenda simples etc., o uso do DataControl é perfeitamente factÃvel.
Da mesma forma, se a aplicação possui uma pretenção um pouco maior, onde seja interessante manter coerente uma ou mais lógicas de negócio, como um controle de estoques por exemplo, ou mesmo uma agenda mais especializada, nestes casos será interessante separar interface de usuário, DAL, DAC, BLL etc., usando uma das muitas metodologias de desenvolvimento existentes, mas basicamente uma OOP.
Outra [Ô]confusão[Ô] que se costuma fazer, agora especificamente olhando para aqueles que usam OOP, é que [Ô]se eu tiver uma DAL, uma BLL e uma interface, eu tenho uma framework de negócio![Ô] Nada mais [Ô]por fora[Ô] do que isso: O simples fato de separar objetivos não significa que o desenvolvedor está utilizando um [Ô]pattern[Ô] adequado de desenvolvimento, mas pode significar que ele está, isto sim, [Ô]alimentando um dragão[Ô], que no fim vai acabar comendo o desenvolvedor.
Dessa forma, não se baseia apenas em uma linguagem de programação, se alguém pretende trabalhar profissionalmente nessa area.
No caso de gostar de lógica e de estar sempre em busca de novas formas de realizar as mesmas tarefas, buscar, isto sim, conhecimento de metodologias e de formas de aprimorar o tirocÃnio para urilizá-lo durante os processos de análise.
Ou, outra forma, se gosta de desenhar e de ser elogiado por seu bom-gosto, especializar-se na criação de interfaces de usuário, e dividir seus projetos com colaboradores que façam, por sua vez, a [Ô]caixa-preta[Ô] das camadas de lógica e de acesso á dados.
Resumindo, não existe mais a ilusão de que TODOS podem ser PROGRAMADORES. Ainda que essa ilusão não exista mais, o MERCADO disponibiliza ferramentas que proporcionam aos leigos fazerem MUITO MAIS hoje do que há 40 anos atrás, sem precisar pensar (vide o exemplo do WIX e outros). Neste tópico, o post mais objetivo, adequado e sucinto foi o MARCELO-TREZE, ao qual eu, se fosse o GIOGOMES, pontuaria ao encerrar o tópico, hehehe.
Tópico encerrado , respostas não são mais permitidas