Caras me surgiu uma dúvida.
Ficaria descente ter uma classe de negócio para unidade e outra para coletividade do mesmo objeto de dominio.
ex:
Isso é descente ou não. Gostaria de sugestões de melhorias.
NMO parece-me melhor que os métodos façam parte de uma outra classse que possui funcionários mas com sua identidade própria, mais ou menos mudar o nome da classe, tipo Empresa, que possui funcionarios, e tipo:
Depois daquele tópico sobre classes de dados (que aliás o último post o Shoes não respondeu 
), eu fico pensando em colocar lógicas de coleção como métodos estáticos da classe Funcionario:
Mas não sei se seria cooool…
Link, please?
Já pensei nisso, colocar lógica de coleção como método estático.
O problema é com a herança.
Legal a ideia da indentidade própria, mas o problema é que eu posso ter muitos métodos na classe Empresa.
Estava pensando na seguinte arquitetura.
Gostaria de críticas e sugestões.
// definição
package business;
public interface Venda
{
public void efetuar();
}
public interface Estoque
{
public void processarBaixa(int codigoProduto, int qtd);
}
public abstract class BusinessFactory
{
public static final obterInstancia() {
return new JDBCBusinessFactory();
}
public abstract Venda obterVenda();
public abstract Estoque obterEstoque();
}
// implementação
package businessImp;
public abstract class VendaImp implements Venda
{
protected abstract void implementarProcessoVenda();
public void efetuar()
{
// regra de negocio
implementarProcessoVenda();
BusinessFactory b = BusinessFactory.obterInstancia();
Estoque e = b.obterEstoque();
e.processarBaixa(1,2);
}
}
public abstract class EstoqueImp implements Estoque
{
protected abstract void implementarProcessoBaixa(int codigoProduto, int qtd);
public void processarBaixa(int codigoProduto, int qtd)
{
// regra de negocio
implementarProcessoBaixa(codigoProduto,qtd);
}
}
package jdbc;
public class JDBCBusinessFactory extends BusinessFactory
{
public Venda obterVenda()
{
return new VendaJDBC(getConnection()):
}
public Estoque obterEstoque()
{
return new EstoqueJDBC(getConnection()):
}
}
class VendaJDBC extends VendaImp
{
VendaJDBC(Connection conn)
{
}
protected void implementarProcessoVenda()
{
insert into venda ...
}
}
class EstoqueJDBC extends EstoqueImp
{
EstoqueJDBC(Connection conn)
{
}
protected void implementarProcessoBaixa(int codigoProduto, int qtd)
{
update estoque set qtd = qtd ...
}
}
BusinessFactory b = BusinessFactory.obterInstancia();
Venda v = b.obterVenda();
v.efetuar();
Baseado em algumas conclusões minhas baseadas nos foruns estava pensando em tirar os DAOs fora.
Por que se pensarmos, o termo classe de persistencia é estranho.
Pois o que existe são operações e implementações de operações.
ex:
o processo de efetuar uma venda tem como ação gravar na tabela do banco.
Mas se o processo fosse gravar no mainframe, ou etc, ou emitir uma mensagem.
Fiquem a vontade !
Me parece que você está falando do caso onde a aplicação é só tira e bota no banco, acho que chamam isso de CRUD.
Eu queria fazer ou achar um framework (agh) que você conseguisse criar aplicações assim só fazendo configurações, sem nenhum código :mrgreen: Ia ser massa!
E não gostei disso heheheheheh feio! :evil:
Não so to falando de CRUD não.
Esse exemplo de JDBC é apenas uma ilustração.
Pode ta esquisito mesmo, mas tem bastante fundamento.
Observe bem. estou separando implementação tecnológica (persistencia) de lógica de negócios , não tem nada de CRUD aí.
EDITADO
O grande problema é usar o OO com os DAOs expondo atributos desnecessários.
Agora se a própria classe se “persiste”.
Porque pesisteir é estranho. O que existe é a operação
cadastrar, registrar,etc.
Gostaria de sugestões…
Eu acho que utilizar DAO´s tem mais uma significância tecnológica, que diz respeito a tecnologia que se usa e como se usa.
Por exemplo se você vai ter uma forma de pesistência imutável, não vejo problemas em retirar o DAO e delegar a responsabilidade para o próprio objeto do domínio.
É verdade Rafael.
Se vc tem uma forma de persistencia única delega-la para os objetos de domínio é bem mais fácil.
O grande desafio é quando vc tem formas de persistencias mutáveis.
É nessas horas que eu vejo a diferença entre a teoria e prática.
Falar de domain model, OO , sei lá o que é muito bonito.
O problema é quando temos obstáculos tecnólogicos.
Gostaria de mais sugestões… (de preferencia com argumentos concretos e de quem realmente entendeu a proposta do tópico)
Qual eh o grande desafio? Nao deixe a gente salivando de expectativa desse jeito! :mrgreen:
Meu, to meio que viajando quanto à este assunto de vocês!
Quando estou fazendo meu modelo de negócio, eu mando tudo quanto é assunto referente a persistência para a casa do caralh…!!! :shock: :shock:
É… é isso mesmo!
Eu me limito em criar um modelo de negócios independente da persistência. Daí, eu crio os daos de forma que eles sejam capazes nada mais nada menos de recuperar ou salvar no banco de dados os dados que estão dentro da camada de negócio. Ou popular meu modelo só com os dados que me interessam!
Na faculdade aprendi a criar o modelo junto com as classes de persitência. Agora na prática, simplemente eliminei a persistência do modelo de negócio completamente! Fica muito mais fácil modelar o sistema. É muito prazeroso saber que seu modelo resolve o problema. e que no fim de tudo, o dao ou qualquer outra coisa que persiste só esta lá para recuperar pra mim dados de um iteração que aconteceu outro dia!
Confesso que é muito bonito o modelo contendo os métodos salvar, update, create e delete. Então optem por criar uma interface com as operações básicas, crie um DAO que implemente esta interface, e coloque ela na sua classe de negócio usando IOC… ou algum pattern de criação de objetos!
Crie no seu modelo os métodos save, delete e companhia delegando a tarefa para o dao!
Abraços!
Thiago
Ué, caso for mutável, então utilize os DAO. Seu domínio continuará tal como está, porém os objetos aos invés de chamar a ‘engine’(caraleo, não me veio palavra melhor pra dizer isso) de persistência diretamente, delegariam a responsabilidade para os DAO´s.
Só não sei dizer se os DAOs fariam parte do teu domínio ou não, ajuda dos universitários.
[quote=jprogrammer]Gostaria de mais sugestões… (de preferencia com argumentos concretos e de quem realmente entendeu a proposta do tópico)
[/quote]
Sinto, mas o JForum ainda não tem a feature: ‘Só receber mensagens de…’
É isso que eu quero saber também !
Como delegar o mecanismo de persistencia para os objetos de dominio e ainda ter várias maneiras de fazer isso ?
class Funcionario
{
private int atributoQueNaoPodeSerVisto;
public void cadastrar()
{
// pode ser JBDC, hibernate, XML, mainframe, etc.
}
}
Como poderiamos implementar isso da maneira menos… TOSCA.
EDITADO:
Como o Thiago falou a modelagem inicial não teria qualquer mecanismo de persistencia. Para isso achei legal usar a ideia do shoes, usando interfaces com os métodos de negócio.
A implementação de como isso vai ser feito aí é outra historia.
Também acho que os métodos como salvar, excluir não devem fazer parte dos métodos de negócio somente como implementação.
[quote=jprogrammer]É isso que eu quero saber também !
Como delegar o mecanismo de persistencia para os objetos de dominio e ainda ter várias maneiras de fazer isso ?
class Funcionario
{
private int atributoQueNaoPodeSerVisto;
public void cadastrar()
{
// pode ser JBDC, hibernate, XML, mainframe, etc.
}
}
Como poderiamos implementar isso da maneira menos… TOSCA.
[/quote]
hahaha!!! Abstract Factory!! Ou Factory Method???
É um desses dois, ou os dois juntos!!!
IMHO:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
[code] class Funcionario
{
private int atributoQueNaoPodeSerVisto;
public void cadastrar()
{
FuncionarioDAO.cadastrar(funcionario);
}
}
[/code]
class FuncionarioDAO{
void cadastrar(Funcionario){
stmt.executeUpdate("INSERT INTO...") ;//JDBC
funcionario.save();//Hibernate
...
}
JProgrammer…
Imagine que vc configurou qual é o banco ou mecanismo de persistência em um properties, certo.
Sua abstract factory ia ser este propertie e definir qual é o mecanismo de persistência que está sendo utilizado!
quando seu modelo chamasse o método cadastrar,
class Aluno {
public void cadastrar() {
AlunoDAO = DAOFActory().getAlunoDAO();
}
Mais ou menos isso:
Assim, vc pode usar o mecanismo de persistência que vc quiser… deve ter algumas limitações… mas em geral, dá sim…
Acredito que se usar JTa para as transações fica ainda mais tranquilo!
(obs: não conheço JTA!!) Se eu tiver falado merda, tenham compaixão de mim!
Thiago
Mas foi isso que eu coloquei aí em cima:
1 - interface com definicção dos métodos de negócio.
2 - Classe abstrata com implementação dos métodos de negocio
3 - Classe concreta com implementação dos processos de persistencia.
O item 2-3 que é foda !
Como fazer isso sem misturar lógica de negócio e dados.
o DAO é maravilhoso, o problema é expor atributos desnecessários para o DAO.
class Funcionario
{
private int atributoQueNaoPodeSerVisto;
public void cadastrar()
{
FuncionarioDao.salvar(this);
}
}
class FuncionarioDAO
{
public void salvar(Funcionario f)
{
f.atributoQueNaoPodeSerVisto // opa;
}
}
OBS:
Já sei que o hibernate pode fazer isso.
O problema é com outro tipo de persistencia.
É… CGLIB talvez resolva seu problema… ué???
Ou quem sabe, Reflection!
Ou… hummm é gambiarra… mas… crie uma … interfac…e (ai…) para… o… funcionario… e passe ele para …o…oo…o…o DAO!!! Nossa… dá até medo falar isso!
Ou use hibernate!
Não to falando que é foda.
É por isso que vou usar ainda por muito tempo os POJOs burros e passa-los daqui-pra-la e de lá pra cá arregabhando tudo que tem dentro deles para todo mundo saber inclusive os DAOs
OBS:
Em um projeto não me aventuraria hoje em fazer isso.
Apenas é uma discussão filosófica…