Gestão de Biblioteca

Gestão de Biblioteca

por Edith Zaida Sonco Mamani -
Número de respostas: 3
Oi pessoal, o projeto de Gestão de Biblioteca com spring.

  • Usamos spring para a integração do nosso projeto. O projeto Web (com Struts 2 e Faces) com a logica do negócio (com hibernate) .
  • A sessão de Hibernate é criada usando Spring
  • Spring cria Beans do negócio que são injetadas com a sessão de Hibernate para o acesso ao banco de dados
  • Os actions de Struts e faces accedem no contexto da aplicação para usar os métodos da lógica do negocio usando spring
Estamos postando apenas o código do projeto Business

Qualquer dúvida, favor entrar em contato.

Abraços.
Em resposta à Edith Zaida Sonco Mamani

Re: Gestão de Biblioteca

por Carlos Eduardo Manssur -
Avaliação do projeto:

- não há implementação de aspecto, pelo que o professor havia falado após a apresentação ele gostaria da implementação de injeção de dependência e aspecto. estou considerando metade da nota para cada um.
- xmls configurados corretamente, mas não vejo necessidade alguma de separar cada bean (5 linhas de configuração) em um novo xml... se você colocar cada bean em um novo arquivo, em um sistema grande terá dezenas de arquivos xml... caso você queira separar ao menos mantenha os DAOs todos juntos...
- não encontrei aonde você carrega o contexto e chama o bean na sua aplicação, creio que não está em lugar algum, caso esteja, me diga aonde por favor.

Nota sugerida até o momento: 2,0
Em resposta à Carlos Eduardo Manssur

Re: Gestão de Biblioteca

por Alvaro Henry Mamani Aliaga -
Por enquanto a parte do ASPECTOs ainda não foi implementada.

Mas o contexto se carrega na parte WEB do projeto, o projeto que foi apresentado, só tem a parte da logica do negocio, mas esta parte já tinha sido feita no projeto apresentado no topico STRUTS, vide na seguinte URL:

Para a parte de :

"não vejo necessidade alguma de separar cada bean (5 linhas de configuração) em um novo xml"

Nós achamos que a modularidade é muito importante, mesmo para a manutenção do codigo e o baixo(muito baixo) acoplamento entre os Caso de Uso, e cada um deles foi implementado assim, não dependem uns de outros. Nós não colocamos cada bean em um arquivo XML, nós fazemos que cada XML seja de um CASO DE USO. Alem disso, num sistema grande é melhor ter baixo acoplamento entre os modulos(CASOS DE USO).

Qualquer duvida entrem em contato. Obrigados
Em resposta à Alvaro Henry Mamani Aliaga

Re: Gestão de Biblioteca

por Carlos Eduardo Manssur -
Agora sim com web.xml e as actions carregando o contexto fica mais fácil... sorriso

Só reparei em mais algumas coisas:

String[] paths = { "appContext-hibernate.xml",
"cu-autenticarusuario-app-context.xml" };

1 - Como você deu import do appContext-hibernate.xml dentro do arquivo cu-autenticarusuario-app-context.xml, acredito que você não precisa indicar os dois para instanciar o ClassPathXmlApplicationContext.

2 - Eu não sei dizer qual é a melhor prática ou se está escrito em algum livro. Mas eu estou acostumado a ver o import dos arquivos com os beans para o seu applicationContext e não o inverso como foi feito. Não sei nem se funciona pois nunca havia feito desta maneira. Com isso, e aliado ao item 1 quando você for carregar o contexto você precisará carregar sempre apenas o arquivo appContext-hibernate.xml e não vai precisar ficar procurando qual era o arquivo xml que é preciso chamar para cada caso. Diminui as chances de erro por chamar arquivo errado.

3 - Tome cuidado com o seu arquivo applicationContext.xml vazio no classpath. Como você não indicou no deployment descriptor o ContextConfigLocation, se não me engano ele utiliza o padrão que é o arquivo vazio no seu caso. É mais seguro declarar o nome do arquivo caso ele não seja "applicationContext.xml" para não acontecer acidentes. E também não deixar um arquivo vazio com nomes perigosos como "applicationContext.xml" ou "struts-config.xml". sorriso

4 - Entendi seu ponto de vista quanto a um arquivo xml para cada caso de uso. Mas eu ainda acho exagero e muito preciosismo. As vezes este "excesso" pode deixar o projeto mais confuso. Que foi o que eu senti ao corrigir ele. Na minha opinião um arquivo "casosDeUso.xml" com todos os casos de uso organizados no arquivo, identados e comentados já seria suficiente. Imagina um programador abrindo um projeto com 40 casos de uso o susto que ele vai tomar quando ver esta quantidade assombrosa de arquivos xml. Eu tenho certeza que ele vai falar "quem foi que criou tudo isso de xml?"

Aí vai a reavaliação então:

- pontos levantados acima.
- xmls configurados corretamente, actions chamando o contexto certinho e web.xml ok.
- não há implementação de aspecto.

Nota sugerida até o momento: 5,5