Essa é uma dúvida pequena se comparando ao escopo desse forum. Considere uma operação de importação de dois arquivos textos, um de cliente e outro de produto. Esse arquivo deve ser lido e gravado em um BD. Minha dúvida é de quem é a responsabilidade de processar cada linha desse txt? Minha classe CLIENTE teria um método importa onde receberia uma linha do TXT, separaria os valores, colocaria esses valores em seus fields ou teria uma classe IMPORTACAO com métodos ImportaCliente e ImportaProduto?
pensando so no caso de cliente e fornecedor, colocaria isso no DAO de cada um, agora pensando no caso de importacao generica ou serviços de importações, onde existe algumas regras especificas, criaria uma classe de processo, importacao qualquer coisa do tipo e criaria metodos staticos para processar os camaradas… para nem precisar instanciar a classe.
[]'s
Mas considere que minha aplicação possa gravar seus dados em 2 ou mais bds, de acordo com a configuração. Eu não teria que ter um DAO para cada BD? Se sim, não teria que ter essa importação em cada DAO?
Num modelo de de domínio OO redondinho, cada classe precisa ter uma responsabilidade bem definida. A classe Cliente deve representar somente o comportamento de um Cliente (anos de estudos para chegar nessa brilhante conclusão…). Incluir a lógica para fazer o parsing do arquivo de entrada pode poluir esta classe. Tendo isso em mente, se o parsing for muito simples, eu não vejo problema em criar um método estático Cliente.criaDaString(String dadosCliente). O trabalho braçal de lidar com a entrada pode ser delegado para classes auxiliares.
Fugindo ainda mais de uma solução OO canônica, você deveria se perguntar se precisa de tudo isso para fazer uma importação no banco de dados. Não é crime implementar um transaction script lendo a entrada e falando direto com o banco de dados em situações descomplicadas. Uma boa rule of thumb é avaliar se o processo envolve lógica de negócios (cálculos de valores, tomadas de decisão, validações não-triviais, …). Em caso positivo, vale a pena investir na criação de um domain model bem organizado. Do contrário, frequentemente um script simples cai bem.
[quote=AllMighty]Num modelo de de domínio OO redondinho, cada classe precisa ter uma responsabilidade bem definida. A classe Cliente deve representar somente o comportamento de um Cliente (anos de estudos para chegar nessa brilhante conclusão…). Incluir a lógica para fazer o parsing do arquivo de entrada pode poluir esta classe. Tendo isso em mente, se o parsing for muito simples, eu não vejo problema em criar um método estático Cliente.criaDaString(String dadosCliente). O trabalho braçal de lidar com a entrada pode ser delegado para classes auxiliares.
Fugindo ainda mais de uma solução OO canônica, você deveria se perguntar se precisa de tudo isso para fazer uma importação no banco de dados. Não é crime implementar um transaction script lendo a entrada e falando direto com o banco de dados em situações descomplicadas. Uma boa rule of thumb é avaliar se o processo envolve lógica de negócios (cálculos de valores, tomadas de decisão, validações não-triviais, …). Em caso positivo, vale a pena investir na criação de um domain model bem organizado. Do contrário, frequentemente um script simples cai bem.[/quote]
Boa resposta! Boa utilização de bom senso!
Hoje em dia eu ainda tendo a eXagerar! Deve ser pq ainda to aprendendo! heheh
a partir da classe de negocio, por exemplo, voce resgata esse arquivo de texto, processa ele como desejado e, quando for inserir o conteudo no BD1, voce pede à Factory correspondente ao DAO relativo ao BD que voce vai inserir esta informacao, depois pede a Factory do segundo BD o DAO do mesmo tipo, e assim segue para quantos bancos voce desejar utilizar… (padrao Abstract Method Factory)