Fórum de entrega do trabalho 1

- Argumentando sobre o review da Cláudia Abrão:

Uma dúvida surgiu após analizarmos a estrutura de pacotes: Por que separar em pacotes diferentes as classes referentes ao DAO e ao JDBC se estas são responsáveis pela comunicação com o banco de dados? Poderia facilitar o entendimento, se as duas estivessem no mesmo pacote. Ficou um pouco estranho ter uma classe por pacote.

As interfaces DAO estão em pacotes diferentes das classes que as implementam por dois motivos:

• Conceitualmente, faz sentido que as interfaces DAO fiquem na camada de negócio, já que podemos encarar estas como abstrações de Repositórios. O paradigma de design conhecido por Domain-Driven-Design (http://domaindrivendesign.org/), criado por Eric Evans, também compartilha desta mesma idéia.

• Evitar dependência cíclica entre pacotes. Caso as interfaces DAO estivessem na mesma camada das classes que as implementam, existiria uma dependência cíclica entre a camada de business e a camada de infraestrutura. Dependências cíclicas diminuem consideravelmente o grau de reuso de componentes e tornam o sistema mais complicado de ser testado.

Na estrutura definida pelo grupo, não fica claro onde está a classe de acesso ao banco de dados. Pesquisando nas classes, percebemos que a conexão com o banco é aberta em várias classes. Isso deixa o código confuso, uma sugestão seria criar uma única classe para acessar o banco de dados e as demais classes apenas extenderiam essa classe.

As classes de acesso ao banco de dados estão na camada de infraestrutura. Quanto ao código duplicado você tem toda razão (corrigimos isto).

Talvez por falta de tempo, ficou faltando a explicação da estrutura do código. Acreditamos que um documento com esta explicação facilitaria a compreensão do sistema.

Boa sugestão Cláudia. Em breve, disponibilizaremos um README com instruções para instalação da aplicação e um breve documento de arquitetura.

- Argumentando sobre o review do Diogo Vernier:

O Sistema ignora exceções em algumas camadas, devolvendo null ou imprimindo o stacktrace. Sugiro a criação de exceções wrapper do tipo RuntimeException e logar a ocorrência da exceção.

Você tem toda razão Diogo. Contudo, por se tratar de um protótipo, preferimos nos concentrarmos em outros pontos e não implementamos um mecanismo de tratamento de exceções e nem logging. Nesta versão corrigida, implementamos um log simples. Provavelmente implementaremos tratamento de exceções e validações de campo quando utilizarmos Struts.

Apesar da implementação utilizando diretórios JNDI ser interessante, o código de para abrir a conexão (openConnection) se repete nas classes de implementação dos DAO's. Acho interessante a criação de uma superclasse de base para os DAO's incorporando código repetido.

Este foi o mesmo ponto apontado pela Cláudia. Corrigimos isto.

********************************************************************************

Segue anexo a nova versão