Banco de dados, GUI, relatórios e gráficos em aplicativo Java

5 respostas
andferraz

Olá, amigos.

Estou em vias de iniciar um projeto pessoal em Java.

Como sou iniciante na linguagem e nas ferramentas, postarei algumas dúvidas por aqui. Só lembrando que tenho experiência em programação na plataforma Microsoft (Visual Basic 6, SQL Server, ASP clássico e alguma coisa de ASP.NET), além de já ter fuçado PHP e MySQL.

Na faculdade cheguei a estudar Java, mas meus conhecimentos são básicos. Mesmo assim, acho que será um grande desafio que agregará valor ao meu currículo.

Tenho definido o uso do Eclipse, apesar de que se houver argumento forte o suficiente posso optar por outra IDE, como o NetBeans, por exemplo.

Este aplicativo será de um prontuário médico. O aplicativo será desktop rodando inicialmente uma base de dados local, mas sem descartar a possibilidade de rodá-lo com uma base em servidor de rede.

Definidas estas premissas, preciso definir:

1 - um SGBD que possa ser intalado local ou remotamente, e se possível ser portado junto com o programa em um pen drive;

2 - as vantagens e desvantagens de se usar o Hibernate para a persistência de dados;

3 - um plugin ou aplicativo para desenhar a GUI com agilidade;

4 - e um componente ou framework para elaboração de relatórios e gráficos também com agilidade.

Agradeço já a todos!

5 Respostas

Adaylon

1- MySQL ou SQLServer eu indico pq são as que menos tive problemas e são relativamente robustas e futuramente vc não precisará migrar para outro banco.

2- Eu particularmente não indicaria o uso do Hibernate para o seu projeto. Tive uma experiencia um pouco desagradável com ele em um trabalho da empresa, onde o sistema quanto mais crescia, mais lenta ficava a manipulação de dados. O problema do Hibernate para aplicações desktop é que ele carrega as consultas em objeto, ou seja, às vezes não há a necessidade de trazer tudo em um objeto e isso deixa a aplicação muito pesada. Já em outro caso, tenho uma aplicação que só funciona bem por causa do hibernate, mas é uma aplicação que faz atualização de bases que possuem bancos diferentes.

3 - Se vc não possui experiência com Swing, pode utilizar o Netbeans para desenhar suas telas com maior agilidade.

4 - Uma ferramenta simples e rápida para elaboração de gráficos e relatórios é o Ireport.

Espero ter ajudado!

andferraz

Obrigado pelas informações!

Eu pensei no Hibernate para manter o código de manipulação da camada de dados independente do SGBD utilizado para situações em que fosse necessário mudar de um para outro de forma simples. Ao abolir o framework, tenho que pensar em uma nova estratégia.

Há alguma sugestão de abordagem para manter isso simples sem o Hibernate?

Adaylon

O interessante independentemente de qual sgbd vc vai usar, é fazer todas as regras de negócio no seu banco como procedures, triggers, functions. e assim vc pode trabalhar com qualquer banco sem alterar seu código. Dessa forma vc pode dar uma olhada na classe CallableStatement que permite que vc faça chamadas “call” e quem faz as regras é o banco. Se vc acha que seu sistema será pequeno use Hibernate sem problemas, mas se não, é acontecer o que aconteceu comigo, vc quebra a cara depois de tudo pronto.
Uma sugestão também é criar classes que instanciem drivers de diferentes bancos e que vc de a oção de no aplicativo o usuário configurar. A camada DAO será igual para todos os bancos se vc usar:

http://java.sun.com/j2se/1.4.2/docs/api/java/sql/CallableStatement.html

andferraz

Bom, algumas semanas depois deixem-me dar a posição em que anda meu projeto.

Adotei a sugestão do Adaylon quanto ao uso do NetBeans, e este realmente facilitou e muito o desenho das telas.

Estou usando o MySQL também seguindo sua sugestão.

Defini uma parte das tabelas do Banco de Dados que resolvem os primeiros casos de uso do aplicativo, e para o acesso aos dados decidi aderir ao padrão DAO, que é sugerido pelos quatro cantos do mundo Java que pesquisei.

Usei como base a descrição presente em http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html.

Vi que o NetBeans usa um sistema de persistência, mas achei melhor usar o DAO para não ficar escravo de recursos da IDE. Acham que foi uma decisão razoável?

-x-

Decidi adotar o MVC para montar a arquitetura. Estou estudando a forma descrita em http://java.sun.com/developer/technicalArticles/javase/mvc/.

Consegui entender como isso funciona se levarmos em conta um aplicativo mais simples como o que é demonstrado ali, pois há apenas uma classe Main que instancia uma classe com a função do Controller, que por sua vez instancia as classes com as funções de View e de Model.

Mas no meu caso, em que o aplicativo inicia uma janela MDI com um menu, que por sua vez abre janelas SDI para a manipulação dos dados, a coisa emperrou na minha cabeça.

Estou em dúvida como prosseguir daqui, pois consegui enxergar as seguintes hipóteses:

1 - Criar um Controller que instancie e adicione a janela MDI como uma View

Haveria então um Model para a janela MDI? E que dados ele deveria representar? A abertura e fechamento de janelas SDI?

E quando houver um clique em uma opção do menu que chame uma janela SDI, como o Contoller faria para adicionar esta janela ao JDesktop e torná-la visível? Este controller teria acesso a isso?

2 - Chamar a janela MDI diretamente da classe Main

Com isso não haveria um Controller para instanciar a MDI. Isso quebraria o padrão MVC? E se for preciso usar outro tipo de View?

E como ficariam as chamadas aos Controllers das janelas SDI? Elas acabariam sendo instanciadas dentro da MDI, ou há alguma outra maneira?

Grato desde já!

Adaylon

Você está indo muito bem pelo visto.
Você pode utilizar dentro de um JFrame um JDesktopPane que por sua vez recebe JInternalFrames.
Uma sugestão para os InternalFrames é criar jPaineis que conterão os componentes das suas telas. Depois na chamada do menu vc mostra o JInternalFrame, instancia o jPainel e insere ao JInternalFrame com o metodo setContentPane(jPainel) que mostrará sua tela com os componentes. Isso facilita muito na hora de manuntenção. E lembrando que isso na sua camada View.
O fato de vc instanciar a chamada das telas no JFrame principal não foge o padrâo MVC, pois vc só está modelando as telas.

Criado 21 de março de 2010
Ultima resposta 12 de abr. de 2010
Respostas 5
Participantes 2