Artigo Java Magazine 66 - Desenvolvimento para desktop com Java – Parte 2

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (3)  (0)

Artigo da Revista Java Magazine Edição 66.

Esse artigo faz parte da revista Java Magazine edição 66. Clique aqui para ler todos os artigos desta edição

Desenvolvimento para desktop com Java – Parte 2

Desenvolvimento das camadas de Lógica de Domínio e Acesso a Dados

Um guia com os primeiros passos no desenvolvimento de aplicativos Java para desktop

 

De que se trata o artigo:

Desenvolvimento de aplicações Java SE utilizando divisão em camadas e padrões de projeto. É apresentado um guia com exemplos para implementação das camadas Lógica de Domínio e Acesso a Dados.

 

Para que serve:

Apresentar os primeiros passos para quem está iniciando no desenvolvimento de aplicações em Java. Nesse artigo são abordados temas como: modelagem de classes, mapeamento objeto-relacional e persistência de dados através da JPA e Hibernate.

 

Em que situação o tema é útil:

Os conceitos apresentados no artigo são úteis e facilmente aplicáveis no desenvolvimento de aplicativos empresariais desenvolvidos em Java, que se propõem a automatizar processos de negócio e que se conectam a bancos de dados.

 

Desenvolvimento para desktop com Java – Parte 2:

O desenvolvimento de aplicações para desktop em Java é menos frequente do que para web ou dispositivos móveis. Hoje é possível implantar sistemas escritos em Java em ambientes antes dominados por linguagens nativas, mas, além da concorrência com ambientes RAD e linguagens nativas, o universo Java com suas APIs e jargões muitas vezes espanta quem quer trabalhar com Java nesse segmento.

No artigo são apresentados conceitos e primeiras decisões que devem ser levadas em consideração para que o desenvolvimento desktop seja bem sucedido. Ele será continuado em partes adicionais, com o objetivo de apresentar a criação de uma aplicação exemplo. 

 

No primeiro artigo da série apresentamos o modelo de programação em três camadas e uma breve introdução aos padrões de projeto. Foi também proposto o desenvolvimento de uma funcionalidade para registro de cobranças bancárias, para praticar os conceitos apresentados.

No segundo artigo, vamos colocar a mão na massa e começar a codificar o registro de cobranças bancárias. Nesse artigo será abordada uma questão que muitas vezes surge quando começamos ou fazemos manutenção em um sistema desenvolvido em Java: como persistir os dados gerenciados pelo sistema? JDBC? JPA? Hibernate? Aliás, o que significam mesmo essas siglas?

Começaremos a implementação pela camada de Lógica de Domínio, pois nela representaremos, em um modelo orientado a objetos (OO), as informações e regras da funcionalidade que nos propomos a automatizar. Começando por essa camada, fica mais fácil entender e definir com clareza o escopo da funcionalidade.

Antes de iniciarmos o desenvolvimento propriamente dito, vamos criar um projeto no Eclipse. A versão utilizada para a construção do exemplo é a 3.4 (Ganymede). Os detalhes da criação e configuração do projeto são apresentados no quadro “Criando e configurando o projeto no Eclipse”. Novas configurações serão necessárias e explicadas à medida que avançarmos no desenvolvimento.

Lógica de Domínio

A camada Lógica de Domínio possui a representação das entidades tratadas pelo sistema, com suas informações, regras e operações.

Vamos supor que foi feito um levantamento preliminar com os futuros usuários do sistema, que informaram ao analista que:

1.      O sistema deve ter uma tela na qual será possível digitar os dados de uma cobrança bancária, dessas que os bancos disponibilizam para seus clientes em forma de boleto (Figura 1);

2.      O sistema deverá validar os dados de cada cobrança, para evitar que sejam armazenados sem data de vencimento, valor do documento e os dados do sacado;

3.      Após a confirmação dos dados, o sistema deverá armazená-los em um banco de dados, para controle posterior do departamento financeiro.

Modelagem: Criando um modelo orientado a objetos que represente a situação do mundo real

Através desses requisitos e do documento de exemplo, poderemos começar a transformar o modelo de negócio em um modelo orientado a objetos.

 

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?