Dao

Bem, quanto as suas perguntas:

1. Na minha opinião, não vejo motivos para desenvolver para Web sem frameworks de mapeamento Objeto-Relacional (O/R) como o hibernate etc. Só em casos muito especiais se justifica a não utilização do mapeamento O/R, mas geralmente estes casos fogem do escopo da Web.

2. DAO é pattern e, como qualquer pattern, só existe uma maneira pré-estabelecida e largamente testada de ser implementada.

3. Tabelas com mais de 40 campos? Será que a modelagem destas tabelas nao teria que ser repensada? Vocês estão seguindo todas as regras de normalização?

Espero ter ajudado.

Nadilson

Concordo com o Nadilson mas gostaria de complementar uma informacao que pode ser util:

Existem plugins para o Eclipse que fazem o mapeamento da tabela para o hibernate. Ou seja, vc nao precisa fazer na “mao”.

Eu utilizo o hibernate synchronizer… Sugiro que vc utilize algum.

Existem outros… eu citei este pois é o que eu uso

Olá afsrj,
O idel seria vc. estudar alguns mecanismos de “persistencia”, hoje temos alguns frameworks ORM que acredito possa atende-lo muito bem.:

E quem sabe os POJOS não atenderia as suas necessidades de persistencia, ou um outro framework como iBATIS que é muito bom e possui muitos recursos. Mais a sua necessidade somente vc. conhece o ideal é analizar algums ferramentas e ver qual será melhor para a sua produtividade e desempenho.

Uma tabela na base de dados com mais de 40 campos? Você tem liberdade para alterá-la?

Não acho que seu problema será resolvido usando apenas um framework de persistência.

IMHO, você deveria se aprofundar na modelagem do sistema e separar as responsabilidades. A tabela pode até ter 40 campos, mas suas classes deveriam ser quebradas em mais entidades, obviamente, com menos atributos. Daí ficaria mais simples fazer os DAO’s, e ao mesmo tempo, mais interessante.

Para melhorar ainda mais sua interatividade com o Banco de Dados, tente fazer um DAO Generico que pode ser utilizado com qualquer Classe.

Dê uma olhada na ultima edição da revista MundoJava.

Eu prefiro usar DAO do que camadas OR…

tem um bom projeto para gerar os VO e os DAO para você.
http://javalee.sourceforge.net/index.htm

Ops, eu prefiro alterar o modelo que tem na pasta conf.

fw

Thiago Senna…:

IMHO, você deveria se aprofundar na modelagem do sistema e separar as responsabilidades. A tabela pode até ter 40 campos, mas suas classes deveriam ser quebradas em mais entidades, obviamente, com menos atributos. Daí ficaria mais simples fazer os DAO’s, e ao mesmo tempo, mais interessante

[quote=Dieval Guizelini]
tem um bom projeto para gerar os VO e os DAO para você.

Mas por que você precisaria de VOs em primeiro lugar?

Eu chamei de VO (Value Object) mas alguns chamam de POJO ou DTO…
no fim é uma classe que possui os atributos da base de dados e os métodos get/sets… normalmente para as “tabelas independentes” do banco não necessito de nenhuma alteração… mas para as “dependentes” eu prefiro criar as instâncias e popular seu conteudo “on-demand”.

fw

Problemas com este seu conceito, Dieval.

Antes de mais nada, você provavelmente chama de VO pelo padrão antes chamado Value Object, agora chamado Transfer Object. Ocorre que este é um padrão de programação com uso de EJBs, que não é o caso.

Data transfer Objects são outro padrão, utilizado apra computação distribuída, e aprecido no conceito com TOs.

Já POJO é algo completamente diferente, não é um padrão. É só um nome bonitinho para uma classe que não está vinculada à infra-estrutura de frameworks e etc. Um ‘VO’ (na verdade um Transfer Object) pode ou não ser um POJO.

Por isso perguntei por que usar 'VO’s.

Note que nenhum destes possui vínculo com ‘atributos do banco de dados’ sequer com tabelas de um banco de dados. lembre-se que num sistema OO você deve pensar em objetos, depois em como persistí-los. Não há porque mapear objetos em função de como as tabelas se organizam, para isso existe mapeamento objeto-relacional.

Phillip,

mas relendo as suas definições elas coincidem com a minha compreensão sobre este tema, o fato é que o javalee "produz" as classes baseado nas estruturas (tabelas) do banco de dados.

The Javalee DB2Java is a tool designed to help developers to make 
their ?dirt job' a little easier. Javalee DB2Java helps developers with 
automatic code generation based on metadata information retrieved from 
a relational database. 

For many people who want to extract information from existing 
databases, the Javalee DB2Java will be a perfect tool to fit this need. With 
Javalee DB2Java you can also generate any kind of code or information, 
based upon the relational database metadata, such as: XML files, Java 
Bean classes, DAO Java classes and whatever you want to.

De certa modo, estes são os objetos iniciais de sistemas simples... e dependendo do padrão que você quiser seguir é fácil reaproveitar este código sem ter que trabalhar muito para produzir os VO, os DTO, os TO e qualquer outra coisa que você queira chamar.

Tenho clareza que se pudesse utilizar um banco de dados OO puro, seria muito mais fácil modelar os sistema sem ter que se preocupar em ter que criar uma camada de "persistência" que decompoe os objetos em dados "primitivos" e depois tem que remontá-los...

Mas valeu, não tive a intenção de gerar polemica neste tópico... apenas indicar um bom atalho...

falou.

Dieval

Não é polêmica, é troca de idéias sobre um tema

Por que você precisaria dos tais VO/TO/DTOs ao trabalhar com uma base de dados relacional?

Ainda que gerando classes de tabelas, que na maioria das vezes é uma idéia muito ruim, você pdoe gerar classes de negócio, não rpecisa de VO/TO/DTO para isso.

http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs

Leio amanha!