O que seria o historico ? uma tabela ? um relatorio ? o que quer dizer com “detalhes” ? tem que mostrar a nota e os itens ?
T
tombatista
Bem:
O histórico é apenas uma listagem das notas do cliente. O usuário, ao visualizar seus clientes, pode listar as notas fiscais deste. apenas nomenclatura;
Detalhes da nota = itens da nota, ou seja, tenho que mostrar a nota e seus itens.
Obrigado, kra.
pcalcado
Sua dúvida não é sobre arquitetura e sim sobre design.
Antes de mais nada, esqueça “VO”. Você não precisa deste padrão.
Depois, relatione os objetos NotaFiscal e Item e não apenas por IDs. Há menos que seu banco de dados seja legado não é recomendáel que você inicie o desenvolvimento pelo banco e sim pelos objetos.
victorwss
Padrão!? E desde quando VO é padrão? :twisted:
faelcavalcanti
pelo menos já foi, mas diversas pessoas ainda usam, inclusive colegas meus próximos em projetos, mas não consegui argumentos a convencê-los a não usar, isto tudo por conta do problema do lazy load, e preferiram utilizar VO’s para caracterizar os dados que serão por exemplo, visualizados em tela, ao invés de usar fetch eager quando necessario carregar via relacionamento, por exemplo via criteria especificado por Restriction ou Projections.
O que vocês acham deste design?
pcalcado
Você quer dizer algo do tipo criar objetos populados com dados que, na verdade, vêm de vários objetos?
Eu só vejo real necessidade disso em casos muito específicos. Mesmo sem um mapeamento O/R decente (o que, em 2008, é algo muito preocupante) você consegue utilizar objetos fazendo “lazy loading manual” nos seus DAOs (ou equivalente).
adriano_si
sem querer desvirtuar, mas já desvirtuando o assunto do tópico, gostaria de saber o que é
lazy loading manual
pois estou recomeçando com desenvolvimento em Java e lembro que quando saí dele há uns 2 anos atrás, o Top ainda eram os VO’s… vou dar uma pesquisada, mas se puderem dar uma breve explanação aqui…
mas não de forma manual, e sim de forma declarativa. por exemplo utilizando recurso de VO carregando em uma classe separada informações, apenas, importantes que serão visualizadas em um grid por exemplo. outras informações mesmo não sendo lazy, não seriam nem sequer carregadas, pois não estão sendo utilizadas naquele momento.
um lado negativo disto que acho é que um VO não tem identidade, o que no caso para uma transação que necessite iterar entre objetos ou verificar e validar estado e informações, difilcultarão desenvolver a regra de negócio associada ao domínio da aplicação, que me motiva a não utilizá-lo neste caso, caracterizando uma alternativa não muito boa.
o meu maior objetivo aqui é utilizar a menor quantidade de recurso possível, já para este caso de design, o que acho legal no uso do VO, como não possui identidade, carregar informações específicas que estão sendo trabalhadas, e apenas isto!
vocês não acham estranho possuir VO’s na camada de serviços ou intermediária dela? Quem deve ser os únicos(únicas camadas lógicas) a enxergarem, apenas?
