• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

Craftsoul

SQL Server + ??

12 mensagens neste tópico

Viva,

bom eu procuro algumas opinioes/sugestoes sobre qual a linguagem para bater um aplicaçao que trabalhe em conjunto com MS Sql Server. Apartida uma aplicaçao simples com GUI que permita fazer umas pergutnas á bd nda de muito complicado!

Mas queria uma coisa robusta que valesse a pena aprender...

Abraço...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Este não é o forum apropriado. Deverias ter usado Dúvidas de Programação, por exemplo.

No entanto a resposta será no teu caso C# ou VB.Net.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Este não é o forum apropriado. Deverias ter usado Dúvidas de Programação, por exemplo.

No entanto a resposta será no teu caso C# ou VB.Net.

Epah pois de facto tens razao, aqui tou a auto sugerir o c++, sry enganei-me!

Mas dqq forma pq nao Visual C++?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Porque para um projecto como aquele que defines não tens necessidade de usar C++. A curva de aprendizagem é mais longa e o processo de desenvolvimento mais lento.

Assumindo que já soubesses C++ e não soubesses C# ou VB.Net então necessariamente o C++ era a linguagem a utilizar. De outro modo, o C# ou o VB.Net vão-te permitir atingir o objectivo mais rapidamente.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Hmm tou a ver, por acaso sei c++ :D

As linguagens que tou familiarizado sao c c++ java.

Tive a falar tb cmo um entendido e indicou-me java (sabendo que eu ja sabia java) juntamente com Jbuilder para o GUI

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Hmm... realmente não me ocorre aconselhar Java para nenhum tipo de projecto. Honestamente, por várias razões que não penso ser este a thread adequada para discutir. Portanto apresento apenas a minha declaração: Não aconselho java :D

Posto isto, se optares por java, aconselho usares o JDBC da Microsoft e nenhum outro, porque é o único de Tipo 4. A única coisa que te peço é que uses o AWT ou SWT para o GUI. Vamos acabar com as aplicações Java com controles não nativos, por favor.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Ui meu amigo eu pedia-te um pouco de paciencia e explicares melhor isso, principalmente essa siglas e aberviaçoes, porque com todo o respeito e nao leves a mal mas o teu post nao me serviu de nda, e dada a minha ignorancia perante o teu post fiquei curioso!

PS: eu pedia a um moderador o favor de colocar isto no sitio correcto senao se importa-se, gracias!

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Hmm... tu disseste que estavas familiarizado com Java pelo que não me preocupei em entrar em detalhes.

Mas aqui vai:

JDBC - Java Database Connectivity. É uma API para o Java que te permite acederes a bases de dados. A Microsoft lançou a sua JDBC para o SQL Server. http://msdn.microsoft.com/en-us/data/aa937724.aspx

Tipo 4 - Significa que a a API vai converter o código Java directamente para o protocolo da base de dados. É o tipo mais alto de JDBCs; sem entrar em grandes detalhes, o que oferece melhor performance.

AWT e SWT - respectivamente Abstract Window Toolkit e Standard Widget Toolkit. Dois widgets toolkits para o desenvolvimento de aplicação Java que necessitem de um GUI (janelas, botões, etc...). Ambos resultam em aplicações Java com os controles nativos (ao contrário de outros toolkits como o Swing). Ou seja as aplicações parecem e comportam-se como aplicações nativas do sistema operativo em que forem instaladas. No Windows, por exemplo, os botões são os botões normais do windows, as janelas as janelas normais do windows, etc...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Ok sim senhor bom post! Epa eu que tava familiarizado mas com codigo e estruturas de dados e respectivos algoritmos, nao com GUI e conexões BD.

Falta so enunciares algumas razoes pelo que nao aconselhas Java para as circunstancias (abstrai-te la de ser o sitio errado...)

Abraço

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Falta so enunciares algumas razoes pelo que nao aconselhas Java para as circunstancias (abstrai-te la de ser o sitio errado...)

Bom... vai ser um bocado longo. Não te queixes.

Não penses também que vou falar mal do Java. Não acredito em falar mal de linguagens de programação. Estive agora a fazer uma pausa e contei as linguagens de programação que já usei uma vez ou outra ao longo da minha vida. São talvez 22; a saber (sem nenhuma ordem especial) BASIC, Visual Basic, DBASE, Pascal, Summer 87, Clipper, COBOL, C, C++, Erlang, FoxPro, Smalltalk,  LISP, Haskell, PHP, ActionScript, Miranda, Luna, Python, Perl, Ruby, Java. E provavelmente ainda me esqueci de qualquer coisa. Se me pedissem hoje para programar em algumas delas certamente teria que voltar aos manuais, mas durante cerca de 25 anos de experiência em programação todas estas linguagens de uma forma ou de outra ajudaram-me a mim e a quem o meu trabalho foi útil. Como tal, não existe tal coisa como uma má linguagem de programação.

Existem no entanto boas linguagens de programação. E neste contexto, uma boa linguagem de programação pode eclipsar outra que, por não oferecer tantas ou mais vantagens, reduz a sua utilidade se a oportunidade de escolher entre uma e outra se colocar. É assim que posiciono normalmente o Java -- uma linguagem que não oferece o suficiente que justifique a sua adopção se me for permitida a possibilidade de escolha. Claro que se não me for permitida essa escolha, o Java é a melhor solução do mundo... porque não existe outra.

Antes de enunciar as criticas, mais uma nota. Críticas fazem-se a todas as linguagens de programação; O C++ que é a minha linguagem de eleição, aquela a que dediquei o maior número de anos e a responsável por me tornar financeiramente estável, não está isenta também das minhas criticas. Mas vamos lá então...

Âmbito da Linguagem

É minha opinião pessoal que a linguagem de programação Java é mal utilizada pela maioria dos programadores. Esta linguagem foi criada à cerca de 17 anos atrás com um objectivo principal muito específico, o de facilitar o desenvolvimento de aplicações de larga escala. Era a opinião do seu autor que o C++ não facilitava este processo (claro está discordo em absoluto) e era necessário uma linguagem que o fizesse. O ser multi-plataforma com Write-once-run-everywhere veio por adição. Mas o grande objectivo foi desde os tempos do Oak o de proporcionar uma plataforma de desenvolvimento para grandes projectos.

Ora, o Java realmente é uma excelente linguagem nesse sentido... mas as pessoas insistem em usá-lo em pequenos projectos. Existe um desfasamento entre o que a linguagem foi criada para fazer e o que a linguagem acabou por fazer. Este desfasamento teve na minha opinião uma consequência muito importante; Obrigou a um esforço adicional de alteração dos pressupostos do compilador e VM do Java. Do tradicional bytecode e fase de interpretação para object code nativo e técnicas como JIT e Dynamic Compilation. Um esforço que poderia ter sido dispendido noutros aspectos da linguagem uma vez que a compilação tradicional para bytecode não tem um impacto substancial na performance de aplicações de grande escala. Mas a necessidade de fazer do Java uma coisa que ele não era levou a um desenvolvimento mais lento da framework em favor do compilador.

Claro está que hoje o Java, em virtude destas alterações, torna-se uma linguagem capaz de lidar com os aspectos de performance inerentes a projectos de menores dimensões. Mas... também a tornou apenas mais uma linguagem entre muitas outras, quando antes era uma linguagem com características muito próprias.

Anti-Programação

Todas as linguagens de programação oferecem um ou mais paradigmas de programação. As linguagens são por exemplo OO, Procedurais, Funcionais, Imperativas, por aí fora. Algumas linguagens oferecem mais do que um paradigma. "Oficialmente" o Java é uma linguagem imperativa e orientada por objectos. Um paradigma de programação é difícil de definir, mas em termos gerais, define o(s) estilos de programação que uma linguagem oferece; os elementos e etapas necessárias à solução de um problema computacional.

Na minha opinião sempre faltou um paradigma à lista de paradigmas normalmente apresentados; Um paradigma que eu chamo Anti-Programação. E o Java é também uma linguagem anti-programação. Uma linguagem desta natureza procura facilitar as tarefas do programador ou oferecer ferramentas que evitem erros comuns de programação bem como erros que coloquem em causa a integridade da memória. O preço a pagar por este tipo de "vantagens" é alto... ao programador é afastada a possibilidade de comunicar directamente com o hardware. O programador programa portanto para a framework, e não para o computador. Isto afasta o programador do seu alvo e o programa da sua plataforma. Reduz também a capacidade de o programador em "entender a máquina e falar na sua língua".

Os riscos de uma linguagem de programação como o C ou C++ -- que não são Anti-Programação -- são por demais conhecidos. É fácil criar uma aplicação que crashe o computador. É fácil criar código que tenha erros que corrompam a memória e tornem o sistema operativo instável... mas isso acontece exactamente porque o programador tem controle sobre a sua máquina e faz dela o que quer... e a isso eu chamo Computer Programming. O domínio da linguagem de programação, análise cuidada, e disciplina durante o processo de desenvolvimento e depuração reduzem os erros capazes de criar instabilidade no sistema a zero.

Aspectos mais práticos

- Falta ao Java suporte para multi-herança a nível de objectos, não somente a nivel de interfaces.

- Falta ao Java suporte para const. A keyword existe e faz parte do léxico. Está no entanto deprecada e o seu autor é contra a sua implementação. Isto surge, digo-te de boca cheia, porque a keyword const é uma das mais complexas -- senão mesmo a mais complexa -- das keywords em C++ e o James Gosling nunca gostou dela (apesar de ser um dos mais fundamentais conceitos em C++). Curiosamente os programadores Java que se iniciam no C++ é exactamente na const que mais dificuldades têm. O que só reforça a minha opinião que o James é um bocado fascista em relação a esta keyword. No entanto ela tem uma valor inestimável já que permite isolar as potenciais alterações a um objecto a partes mais restritas do código e consequentemente facilitar o testing e debugging das classes.

- Este é puramente pessoal e de natureza politica: O Java é  agora GPL e eu faço boicote a tudo o que é GPL excepto a kernel Linux porque infelizmente não tenho escolha. (tem piada não tem? Kernel Linux <-> não tenho escolha. Quem diria que chegávamos a isto. Mas enfim... não é para aqui chamado.)

- Garbage Collection. Realmente o Java terá que implementar mais do que um modelo de GC. Não pode continuar assim. Para certos tipos de aplicações o modelo que existe não é satisfatório. À semelhança do C# é necessária a criação (urgente na minha opinião) de destructors determinísticos já que também concordo que não se deve impor a dealocação ao GC. No entanto é necessária mais flexibilidade no GC do Java. É presentemente muito restrito.

- Checked Exceptions não podem ser obrigatórias. Das duas uma, ou se assume que o Java agora só serve para o desenvolvimento de pequenos e médios projectos e nesse caso deixe-se ficar como está, ou então mantém-se o suporte para o desenvolvimento de aplicações de larga escala, e nesse caso tem que se eliminar a obrigatoriedade dos throws nas Checked Exceptions. Isto complica sobremaneira o desenvolvimento vertical do código. E cada nova layer lá terá que lidar com a Checked Exception.

...

E prontos... é basicamente isto. Não vale a pena estar a escrever muito mais. Também já estou cansado. Poder-se-ia dizer mais qualquer coisa, mas no fundo conhecendo as duas linguagens não hesitaria nunca na escolha entre C++ ou Java para qualquer tipo de aplicação. Claro está que existe também o factor humano que determina neste caso que pela minha formação (nesta área, claro está), experiência de vida e práticas de programação, o Java tornou-se uma não-opção para mim. Outras pessoas juram a pés juntos que não viveriam sem ele, e só me compete aceitar.

Mas também me compete comentar.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Posto isto, se optares por java, aconselho usares o JDBC da Microsoft e nenhum outro, porque é o único de Tipo 4. A única coisa que te peço é que uses o AWT ou SWT para o GUI. Vamos acabar com as aplicações Java com controles não nativos, por favor.

Devo mencionar que a licença do driver JDBC da Microsoft impõe algumas restrições na utilização do driver, por exemplo, não sendo possível distribuir o driver juntamente com a aplicação.

O driver actual, 1.2, suporta MS SQL server 2000 e 2005, sendo a versão 2008 suportada com limitações. Do que experimentei, a sua robustez deixa algo a desejar, não tem suporte para os tipos de dados mais novos e a sua velocidade podia ser melhor.

Algumas das limitações podem ser removidas na versão 2.0 mas ainda não é definitiva e ainda não a testei, pelo que é indicado pela Microsoft não há garantias de compatibilidade de código e o driver ainda é muito novo.

Se não tens como requisito um sistema multi-plataforma e não pretendes que a tua aplicação cliente execute em SOs que não sejam Microsoft não tens grande razão para escolher Java em detrimento de C#, por exemplo, seria uma opção mais produtiva.

A passagem de Java para C# é relativamente simples, tirando alguns pormenores, as diferenças são pequenas, se te sentes à vontade com Java então passar para C# é fácil.

Já agora, queria apenas acrescentar, porque são coisas que perpetuam erros, Swing também é nativo, e pegando em duas aplicações, uma Swing e outra SWT lado a lado, a SWT salta à vista como não sendo assim tão natural ao SO.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Bom mais uma vez um belo post!

Dos "senaos" que apresentaste do java talvez os mais problematicos sejam mesmo a precária flexibilidade do GC e o raio das throws impreteríveis , até porque foi os unicos, praticamente, com que me deparei. Mas tal como disseste, detalhes destes nao fazem da linguagem ma, fazem a linguagem menos boa. Muitos deles se calhar, acabam por ser afogados apenas pela versatilidade da maquina virtual java, compete agora a cada um, de facto, escolherem ou nao a implementaçao de x linguagem em y projecto!

Relativamente á "anti-programaçao" olha que o Java com o seu GC, apesar de fechado, angaria um pontos extra relativamente ás restantes linguagens imperativas e mesmo OO.  Nao creio q e isso será um senao do Java (nao percebi muito bem se foi isso que tentaste dizer). No entanto ponho seriamente em causa a versatilidade e usabilidade de uma linguagem que respeite os critérios de um dito paradigma "anti-programação" na linha em que o definiste!

Bom acabei por me abstrair um pouco da questao, de facto a inicio tava "virado" a implementar em Visual c++, no entanto, tendo em conta que nunca trabalhei GUI em c++, e por outro lado ter tido um cheirito de java GUI tava com tendencia para Java. Pq o dos meus problemas e factor mais pesado na decisao é´o tempo dispendido na aprendizagem da linguagem a implementar, que tem de ser o menor possível!

Resumindo e tendo em conta as consideraçoes do Marfig e juntamente com restriçao a sql 2008 referida pelo Knitter, a implementação será c++.

A aprendizagem desta forma, resume-se apenas ao salto de c++ para Visual C++.

A plataforma base é Windows, apesar de ter aspiraçoes de implementar isto a multi- plataforma mas nao será possivel assim.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora