Como organizar um projeto Java (com UML ou não) em MVC com NetBeans?

A VIEW chama o controler, que delega a execução pro negócio, que devolve o fluxo pro controler e que repassa (com dados) para a view.

Sacou?

Deixa eu ver se entendi: a View chama o Controller, o controller delega a execução pro model (negócio?), que devolve o fluxo pro controller que repassa com dados para a view.

Onde fica a classe Main?

O tratamento de eventos fica na View ou na Controller? Parece-me lógico que na controller, mas como?

Como uma classe do pacote View chama uma do Controller se os dois são pacotes diferentes?

Tem como criar umas classezinhas bundas só pra eu ver isso em código?

Se a classe Main q vc tá citando é a classe que contém o método public statc void main (String[] args) { //…}, ela fica exatamente no início da sua aplicação, ou seja, vc só usa ela para iniciar a aplicação.

Fox:

O tratamento de eventos fica na View ou na Controller? Parece-me lógico que na controller, mas como?

Fox:

Como a View chama o Controller se os dois ficam em pacotes diferentes?

import seu.pacote.com.SuaClasse

Abraços!
Thiago

Hum… ok! Estou testando aqui e até agora consegui importar as classes necessárias! Parece que está tudo ok! Qualquer coisa posto mais mensagens!

Muito obrigado!

FUNCIONOU!!!

IT LIVES!!!

BWAHAHAHAHAHAHAHAHA!!!

:twisted:

Her… hum hum…

Desculpem, eu emporguei. É que consegui criar um .jar auto-executável com uma GUI feita em NetBeans e que usa o modelo MVC. Acho que estou pegando o jeito!

rsrs…

quando consigo algumas proesas também gosto de sair mostrando pra todo mundo… hihi!

Parabéns!

tambem estou com algumas duvidas a respeito disso:

1º - MVC apenas para J2EE ou Web?? porque eu estou fazendo uma aplicaçãozinha client-server J2SE 1.5 swing(firebird), soh pra aprendizado mesmo, pra catalogar minhas revistas(tipow vou cadastrar revista, edicao, e assunto!! pra quando eu tiver alguma duvida eu faço a busca e sei em qual revista fala sobre o assunto)

2º Eu estou fazendo assim(nem sei se é mesmo MVC): uma classe RevistaDTO(soh com os campos tipow: String Nome int ID e com getters e seters, uma classe RevistaDAO que obtem uma connection e faz os inserts, selects e updates tipo public void create(RevistaDTO revista)…; e a classe visual RevistaView que instancia uma RevistaDTO para obter os campos, e uma RevistaDAO para chamar os metodos create() passando como argumento a RevistaDTO, mais ou menos isso!! Esta certo esta logica que estou fazendo???

fred, Isso não quer dizer que seja MVC ou puramente OO.

Se buscar por discussões (enormes) aqui no GUJ, vai ver que muita gente não gosta desse modelo de DTO + DAO, pois acaba virando uma “biblioteca” de funções mais uma estrutura de dados, já que você poderia se aproveitar da OO a juntar dados + ações sobre eles.

Esta seria só sua parta do M, nada a ver com V ou C.

Olá!

Isso q vc citou tá mais pra arquitetura 2 camadas…

veja bém, MVC é Model View e Controller, que graficamente é mais ou menos isso:

view --> controle --> modelo

E o seu código está assim…

view ------------------> DAO
DTO (vírus)

Minhas sugestões são as seguintes:

1 - O que é DTO? Para que ele serve? Onde ele deve realmente ser usado?

2 - O seu DTO com os atritubutos e getters and setters deveriam ser substituidos por objetos de negócio, criando assim o modelo de sua aplicação. Ou seja, vc teria uma classe chamada Revista, e não RevistaDTO.

3 - Do jeito que vc está implementando, sua view cria um dto e passa ele pro DAO. E onde está o controle? O controle deve receber a solicitação da View, e encaminha esta solicitação para alguém, seja método ou classe, que sabe como tratar esta soclicitação.

Abraços!
Thiago

essa é a questao como organizar as classes para fazer um aplicação swing?? esse modelo que eu expliquei eu meio que inventei(ja que nao li nada a respeito) pensei assim ficaria melhor mais distribuido!!! como seria entao a organização para fazer isso, com OO como vc disse??

Você pode usar uma FMK que te ajuda: X-Work.

hum… ta começando a clarear!!! 8 :?
ta entao eu discarto a DTO, e fico com a DAO e uma apenas Revista?? e nesta revista teria um metodo insertRevista() que chamaria a DAO para inserir??? e eu teria uma instancia da Revista na View?? para carregar os dados??

a questao é? como ficaria a view? quem ela instanciaria(ou nao) e como ela passaria os dados dos fields?? para esse controle como vc citou?

Fox McCloud:

Onde fica a classe Main?

O tratamento de eventos fica na View ou na Controller? Parece-me lógico que na controller, mas como?

No meu entendimento de MVC no desktop, o Controller é o gerenciador da View e do Model. O Controller é a sua classe Main (o “boot” da aplicação), mais os manipuladores de eventos que chamam as regras de negócio (Model).

Resumindo, a GUI gera eventos (View) que são tratados pelos manipuladores de evento (Controller), acessando de alguma forma a lógica da aplicação (Model).

Veja http://www.churchillobjects.com/c/14058.html.

fred:

Revista r = new Revista(). r.setDados( .. ); r.save();

ou

Revista r = new Revista("revista 01");
RevistaDAO dao = new RevistaDAO();
dao.save(r);

A abordagem do daniel é muito mais da hora. Mas por enquanto, se vc estiver iniciando, acho bom vc saber que a abordagem do Daniel é a ideal, mas ai vc acopla seu código sql no seu método save da sua classe de negócio, ou entaum o método save de sua classe revista poderia estar chamado o dao, tipo assim

public void save() {
    RevistaDAO dao = new RevistaDAO();
   dao.save(this);
}

Bom… mas pessoalmente, eu ficaria com a primeiro exemplo que te citei. Em breve, de acordo vc for se familiarizando mais com a linguagem, vc vai naturalmente adotar a abordagem que o Daniel citou!

Pq esperar?

fredferrao:

ta entao eu discarto a DTO, e fico com a DAO e uma apenas Revista?? e nesta revista teria um metodo insertRevista() que chamaria a DAO para inserir??? e eu teria uma instancia da Revista na View?? para carregar os dados??

a questao é? como ficaria a view? quem ela instanciaria(ou nao) e como ela passaria os dados dos fields?? para esse controle como vc citou?

Para adicionar uma revista, eu faria new Revista, depois mandava salvar com revista.save() {dao.save…} ou dao.save(revista) {JDBC.save etc…}. A Revista no caso faz parte do Model e não da View, pois a view é a GUI da aplicação e Revista é uma classe que faz parte do coração da aplicação, que contém sua lógica de funcionamento (regras de negócio). Ao meu ver a View é instanciada pelo Controller. Quem cataria os dados dos controles visuais e passaria para a lógica de negócios seriam os tratadores de eventos que junto com o “main” da aplicação constituem o Controller.

HUAhauhhaua

Bom, pelo entendimento, acho que vou fazer da seguinte forma: juntar as classe DAO e DTO em uma soh: a classe “Revista” esta ja tem os campos, com os devidos setCampos, e essa ja pega um Connection e faz o save(). ai eu ficaria com a view, que instanciaria a Revista setaria os devidos campos chamaria o save(). como o danielDestro exemplificou? Certo??

Sua classe de negócio pode chamar um DAO internamente… na boa!

pelo menos vc abstrai a camada de dados e deixa independente.

eita nao ta dando nem tempo de eu responder, ehhe ai meu retorno fica atrasado em relação as outras respostas, :lol:

mas vamos la: entao farei o seginte: classe RevistaDAO com os SQL’S, classe Revista com os campos e set’s and get’s (memoria nos campos) e os save and updates(que chamam a DAO para gravar e recuperar do Banco) ai os tratadores de evento da view instanciam apenas a classe Revista e chama os get’s and set’s o save(). que por sua vez chama a DAO…!! certo!! 8)

Para desacoplar a Revista dos DAOs, no caso do revista.save, eu usaria herança (RevistaVolatil -> RevistaPersistente - com o método save) ou uma classe abstrata (Revista é abstrata, RevistaFísica implementa save). Essa segunda opção pressupõe que a revista em si tem natureza persistível, já a primeira extende uma revista para torná-la persistível. Acho que depende do caso, mas a segunda alternativa me atrai mais:

class Revista {
    String titulo;
    String edicao;
    Editora editora;
    Map<Materia> materias;
    
    // Métodos de "inteligência"
    public PapelPicado rasgar();
    public Pagina proximaPagina();
    public Fumaca queimar();

    // Natureza persistível
    public abstract void save(); 
    public abstract void load();
}

class RevistaQualSeriaUmBomNome extends Revista{
    public void save() {
        dao.save...
    }; 
    public void load() {
        dao.load...        
    };
}

Dependa de abstrações, nao de implementações.

Faça sua classe de negócio depender de uma interface com métodos save/delete/update e faça seu DAO implementar essa

Pelo menos eu concordo

É isso ai galera, ta muito produtiva essa nossa discussão, creio que muita gente vai se aproveitar dela!!!

pcalcado: como estou iniciando, nao entendi muito bem a sua colocação? como seria isso: minha classe de negocios depender de uma interface? ela estenderia uma interface e ficaria obrigada a implementar tais metodos? ou ela implementaria uma interface(implements)?

pcalcado:

Dependa de abstrações, nao de implementações.

Faça sua classe de negócio depender de uma interface com métodos save/delete/update e faça seu DAO implementar essa

Tava pensando nisso. Talvez um save abstrato não fugiria muito de uma estrutura “daótica” hehehehe. No caso o que falei tornaria o bicho independente até do conceito de DAO, mas se save é persistência, que outra coisa que não um DAO eu usaria no save? Taí! gostei:

class Revista {
    String titulo;
    String edicao;
    Editora editora;
    Map<Materia> materias;
    
    // Métodos de "inteligência"
    public PapelPicado rasgar();
    public Pagina proximaPagina();
    public Fumaca queimar();

    // Natureza persistível
    public void save() {
        abstractDAO.save...
    }; 
    public void load() {
        abstractDAO.load...        
    };
}

Uma dúvida Shoes: normalmente como você fornece a implementação do DAO à classe? Construtor? SetDAO? IoC?

calma la galera, ta aparecendo um monte de ideias e ja to me confundindo!!!

Renato porque abstractDAO??? como seria isto??

fredferrao:

pcalcado: como estou iniciando, nao entendi muito bem a sua colocação? como seria isso: minha classe de negocios depender de uma interface? ela estenderia uma interface e ficaria obrigada a implementar tais metodos? ou ela implementaria uma interface(implements)?

Você tem as classes na camada de negócios, sei lá: Cliente.

A classe Cliente precisa de algo que persista seus dados, no caso era o dao.

class Cliente{
 private DaoCliente meuDao = new DaoCliente();

 public save(){
  meuDao.save(this);
 }

}

Nada demais, exceto pelo fato que qualquer mudança na classe DAO, que está na camada de persistência, afeta diretamente a classe Cliente. Mau, mau, mau!

Vamos fazer o Dao implementar uma interface da classe de negocios:

class DaoCliente implements ClienteRepository{
  //...
}

E fazer o Cliente depender do Repository:

class Cliente{
 private ClienteRepository repositorio = null;
 
 public void setRepository(ClienteRepository rep){this.repositorio=rep;}

 public save(){
  repositorio.save(this);
 }

}

Agora seu cliente depende de uma abstração, um lugar onde clientes são armazenados. Se é um DAO, uma classe que gera HQL, um serializador, tanto faz, desde que ele cumpra o contrato.

Eu adotaria uma abordagem qualquer que não a propria classe instanciar (nesse caso a idéia não vale de nada ).

Uma Factory funciona bem na maioria das vezes, fiz bastante isso já, e IoC para quem puder usar.

Tipo afetaria se os mudasse os nomes de metodos e argumentos certo? pois o resto esta encapsulado!!

e ficou soh uma duvida de como seria essa classe repository? ela teria apenas os metodos abstract save() e etc?

fredferrao:

calma la galera, ta aparecendo um monte de ideias e ja to me confundindo!!!

Renato porque abstractDAO??? como seria isto??

Eu só coloquei para indicar que o DAO que a Revista referencia é uma interface ou classe abstrata, não uma classe concreta. O que importa para a Revista é o DAO.save, não como ele é implementado. Por exemplo, você poderia definir uma interface RevistaDAO e criar implementações dela: RevistaDAOJDBC, RevistaDAOXML, RevistaDAOHibernate etc. No caso Revista não ia saber da existência de nenhuma implementação, apenas a interface. E a instanciação da interface, como o Shoes disse, seria feita externamente e fornecida à Revista, porque se a própria Revista instanciasse, ela ainda estaria acoplada a uma implementação.

“uma classe que gera HQL, um serializador, tanto faz”, me parece apenas um nome diferente do ponto de vista das regras de negócio para um DAO. Ou seja, no fundo ClienteRepository é um DAO sem merchandising

Boa Pergunta…

É que eu fiz isso… estou usando dao.save() no meu projeto de final de curso, e ainda assim estou apanhando que nem um cachorrinho… :mrgreen:

Bom, mas já q vcs estão dando uma aula, retire o q falei. Use a abordagem revista.save().

Olá… deixe-me fazer uma perguntinha…

isso aqui é legal na opinião de vocês?

Revista revista = new Revista();
revista.load(15); // 15 é a id da revista

Eu acho isso meio feio. Vcs acham também??

Renato,

A questão é que DAO é uma implementação, a proposta é você abstrair isso, em um repositório, um lugar onde clientes (ou revistas :P) ficam armazenados.

Não é proque um objeto conhece seu DAO/Repositório, que ele tem as responsabilidades deste.

Você pdoe muito bem fazer

Cliente c = clienteRepository.load(nome);

E manter o objeto Cliente só com um método save() que usa a função no respositório.

show de bola philip!

Eu já tinha engatilhada uma pergunta de como fazer querys… mas deixa pra lá… :mrgreen:

pcalcado:

Renato,

A questão é que DAO é uma implementação, a proposta é você abstrair isso, em um repositório, um lugar onde clientes (ou revistas :P) ficam armazenados.

Mas um “repositório” na prática não define uma interface estilo DAO (métodos de persistência)? Na prática o que uma interface DAO tem que uma interface ClientRepository não tem?

HUmmm… feio! Que tal:

Cliente c = Cliente.load(nome) {ClienteRepository.load...};

Método estático. Acho mais coeso. Seria válido?

Humm… boa…

Mas tenho uma opinião quanto ao assunto.
E se você implementasse o método save da Revista, ex:

public class Revista {

public void save() {
   Statement stmt = conn.createStatement(INSERT_SQL);
   // restante do método
}
}

Se meu método save possui a implementação da persistência, então minha classe de modelo também é DAO?

Eu acho que não é por que temos código de persistência que quer dizer que ele seja um DAO!

Abraços!
Thiago

Mas a idéia é tirar a implementação da persistência da classe de negócio, e não deixar junto.

sim, a idéia é tirar a implementação…!
Mas o q estou questionando é que, e se eu fizesse assim. Não é só por isso que o meu modelo passaria a ser um DAO. Ele ainda assim continuaria a ser o modelo. Ou estou errado?

Isso quer dizer que, se eu chamar o método ClienteRepository.save(this) dentro do método save da classe Revista, pode ser que ClienteRepository apesar de fazer mais ou menos a mesma coisa que um DAO faz, ele ainda assim não seja um DAO!

pessoal li re-li e acho que estou começando a “captar” a ideia do philip.

ta entao no setRepositorio eu passaria como argumento o daoCliente, que “é um” repositorio certo???

fredferrao:

pessoal li re-li e acho que estou começando a “captar” a ideia do philip.

ta entao no setRepositorio eu passaria como argumento o daoCliente, que “é um” repositorio certo???

Como vc criou um setRepositorio, seria mais conveniente vc passar uma classe que implemente repositorio, tipo clienteRepository, e não um daoCliente!

Isso é bobeirinha… Só dê nomes que tenham mais haver um com o outro.

tiago é isso que me deixando com duvida? porque ClientRepository.save(this) e nao dao.save(this)

Uma classe pode desempenhar o papel de vários patterns, porque não?

DAO - http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Se seu objeto se encaixa no padrão, sim, então ele também é um DAO.

Isso. Eu entendo como um DAO como uma classe especializada em persistência apenas.

na verdade meu projeto esta em casa, ainda estou pegando as ideias aqui, pra chegar la e colocar em pratica!!

mas no exemplo do philip o daoCliente implementa ClientRepository!!

isso que ta me deixando com duvidas!!

Bom… é isso que eu entendo também. Isso quer dizer que sua classe pode possuir rotinas de persistência, e mesmo assim não ser um DAO!

mas…

Entaum, agora a dúvida é a seguinte. Com o que o Daniel é disse, agora estou pensando sobre o que é encapsular e abstrair o código de persistência. Seria colocar isso em uma classe, ou pode ser em uma classe que tenha outras responsabilidades???

Vê o diagrama.

Hummm agora entendi. Isso aí o Shoes seria indicado para responder. Qual a diferença, além de nomenclatura, entre ClienteRepository e um DAO?

Thiago Senna:

fredferrao:

pessoal li re-li e acho que estou começando a “captar” a ideia do philip.

ta entao no setRepositorio eu passaria como argumento o daoCliente, que “é um” repositorio certo???

Como vc criou um setRepositorio, seria mais conveniente vc passar uma classe que implemente repositorio, tipo clienteRepository, e não um daoCliente!

Isso é bobeirinha… Só dê nomes que tenham mais haver um com o outro.

Não Thiago! O daoCliente seria uma implementação de clienteRepository, de acordo com o Shoes disse. Dá uma olhada nos posts anteriores. Fred, pelo o que entendi é isso mesmo.

danieldestro:

Uma classe pode desempenhar o papel de vários patterns, porque não?

Se seu objeto se encaixa no padrão, sim, então ele também é um DAO.

Mas acho que o que o Thiago falou não se encaixa não, porque pra mim a idéia do DAO é ser um “provider” para alguma classe separada, não para a própria classe em si:

Cliente -> lógica
ClienteDAO -> só persistência

É uma questão de entender ou interpretar o que é um DAO. Pra mim o DAO é um troço separado e que mexe só com persistência, mas não sei se é absurdo eu pensar dessa forma.

No caso essa classe com outras responsabilidades além da persistência, tipo um multi-uso hehehe, ela funcionaria como um DAO, mas não seria um DAO puro. Mas se o DAO é o próprio objeto o qual ele provê, então ele não é mais um DAO, ele é um objeto que cuida da persistência sozinho. @+ ou seja, é um objeto de lógica de negócio com persistência embutida, o que o DAO propõe-se a desacoplar. No meu entender.

hehe… eu também acho que é isso… cruel viu!

Isto é um Singleton, Proxy ou os dois?

public class Configuracoes {
  private static final INSTANCE = new Configuracoes();

  private Configuracoes() {
  }

  public Configuracoes getInstance() {
    return INSTANCE;
  }

  public String getHost() {
    //atrvés de RMI, HTTP ou Socket ele pega a config
  }

  public String getOutraCoisa() {
    //atrvés de RMI, HTTP ou Socket ele pega a config
  }
}

ClientRepository é a interface. O DAO é uma implementação da interface ClientRepository.

Se você define bem o contrato (métodos) de ClientRepository, você não vai precisar mexer nele e pode mexer à vontade no DAO.

ClientRepository é só um nome diferente para uma interface estilo DAO.

Cara… voces deram uma volta!

É o que o destro falou, o DAO é uma implementação de uma interface. É uma abstração. Faça sua classe depender de abstrações, não de implementações.

Fred, você pegou o espírito da coisa. Para Cliente, não existem DAOs, existem repositorios, e ela recebe um. Se é um DAO implementando um repositório não é problema dela, desde que ele obedeça o contrato da Interface

Consultas feitas diretamnete ao objeto? Pode até ser, mas eu acho isso artificial demais. Não é o tipo de cosia que se tem no mundo físico,a cho que já temos problemas demais em protar abstrações pra um modelo de software e não rpecisamos criar mais coisas sintéticas.

Colcoar uma prepared statement no seu objeto de negócios não faz um DAO, faz uma bela bagunça misturando SQL e código de persistência com regras de negócio, e até a última vez que eu lembre isso é exatamente o que tentamos evitar com DAOs e camadas.

Esse é o meu ponto. A interface Repositorio define a mesma coisa que um DAO define, então é só um nome diferente para um DAO. Do contrário, repetindo minha pergunta: qual a diferença entre uma interface DAO e uma interface Repositorio, além de não dar créditos à sigla “DAO”? Não tô enxergando diferença. ClienteRepository é uma interface estilo DAO, portanto qualquer coisa que a implemente será um DAO. Entendeu a questão Phillip?

Pense na abstração.

Mas uma interface DAO abstrai exatamente da mesma forma. A diferença é que eu a chamo de DAO. Só isso. É disso que vocÊs estão falando né? É isso? Se é, então isso é uma abstração apenas de um nome. Cliente conhece o seu Repositorio, mas nunca ouviu falar sobre DAO. Mas também não sabe que DAO é só outro nome para o seu Repositorio.

Se estamos de acordo, a questão é simplesmente a escolha do nome. ClienteDAO, para os que sabem o que é DAO, dá uma maior clareza para entender a função da classe. Já Repository seria um nome mais limpinho, abstraído.

Ufa! :roll:

Exception in thread "Como organizar um projeto Java (com UML ou não) em MVC com NetBeans?": misunderstanding.

noelrocha:

chamar de Repositorio ou DAO p/ mim não faz diferença … a diferença eh que o pattern tem o nome de DAO, se vc não quer saber qual é o pattern e quer um nome que tenha mais sentido Repositorio é a alternativa…

Isso. Repository não é uma abstração do ponto de vista funcional como um List e ArrayList, por exemplo, mas do ponto de vista simplesmente de nome. É isso que tô tentando dizer.

Renato,

Eu costumo incluir em DAOs JDBC o seguinte:

class XyzDao{
  public XyzDao(Connection conn){this.conn=conn}
  public XyzDao(){}
 //...
}

Por que? Porque quando tenho uma caeia de DAOs chamando DAOs não quero usar todas as conexões disponíveis no pool.

Isso é um detalhe de implementação. O cliente do DAO precisa saber disso? NÃo! Isso é abstrair: se livrar de detalhes inuteis no contexto.

Então faço meu repositório (você pdoeria chamar de deposito, bananeira, jabuticaba, qualquer coisa que te faça sentido, ou melhor ainda: faça sentido no domínio) que tem as funções que o objeto de negocios precisa. Pronto.

Todo DAO oferece acesso a dados mas nem tudo que oferece acesso a dados é DAO. Active Record não é DAO. SQL msiturado no objetod e negócios não é DAO.

Como você sabe qual objeto montar? Quais os atributos correspondem a quais colunas de quais tabelas (uma classe pdoe ser mapeada em menos de ou mais de uma tabela)? Como fazer consultas específicas? O que este seu DAO retorna?

Não. Como disse acima acessar SGBD não faz de uma classe um DAO, do contrário tudo relativo a JDBC seria DAO.

Dê uma relida no padrão:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Por favor leia este topico:
http://www.guj.com.br/posts/list/21687.java

Separar responsabildiades de um objeto, dados de um lado, validação de outro, regras de outro, é quase semrpe praticar desenvolvimento segundo o apradigma procedural. Se seus beans só possuem get e set, você deve refatorar seu projeto para que a lógica de negócio fiqwue onde ela deve estar: nos objetos de dominio.

Não faz diferença porque você não captou a abstração e sua necessidade

Entendi o seu ponto Phillip. Mas nesse caso específico que estamos falando, não vejo muita tragédia em chamar de DAO…De qualquer forma, vou guardar seu conselho na mochila, e me lembrar dele em caso de problemas Valeu!

A questão não é chamar de DAO, Renato, é depender de um DAO. Você deveria depender de uma abstração… to ficando repetitivo

Uma abstração de mais alto nível que um DAO, um DAO pode parecer um nome legal, mas é um padrão documentado e conhecido.

Chame de Repository, Database, Joaninha, sei lá, mas tenha essa abstração e não acomple ela com o DAO, faça A classe cliente e o DAO dependerem desta abstração (uma interface), não faça o cliente depender diretamente do DAO, principalmente se você está usando Active Record.

Acho que já nos entendemos sem nos entender

Bom, Renato.. acho que deu para entender sim!

Veja bém...
Tudo se resumi no seguinte: Dane-se se o nome é DAO, o que importa é que vc sabe que tal classe é responsável pela persistência... Ela pode ser chama joaninha (boa)... gafanhoto... caixa de fósforo..., ou até mesmo..

SuperGuardadorDeDadosInstantâneoDeEstadoDeObjetosTabajara :mrgreen:

Outra coisa que entendi é para tu nunca deixar seu modelo depender de um dao. tipo isso aqui:

public class Aluno {
   public Aluno() {
      AlunoMySQLDAO dao = new AlunoMySQLDAO(); // <-- coisa feia, muito feia mesmo!
    }

    public void save() {
         dao.save(this);
     }
}

talvez fosse mais conveniente algo assim..

public class Aluno {

    private PersistidorDeAluno pa;

    public void setPersistidorDeAluno(PersistidorDeAluno pa) {
        this.pa = pa;  // <<-- que bonitinho.. :)
    }   

    public void save() {
         pa.save(this);
     }
}

Desta forma, vc pode injetar um persistidor de aluno no seu modelo! Seja via IoC ou qualquer outra coisa!

Thiago, foi uma brincadeira

Depois de tanto sacrifício do Shoes, essa idéia de abstrair até o nome das paradas já tá se impregnando na minha cabeça

Olá…
Meu nome é Patricia e estou num grupo de pesquisa onde estamos trabalhando com MVC.
Eu vi o forum e achei legal para trocar informações e gostaria de aporveitar a oportunidade para perguntar se vcs poderiam me ajudar com algumas duvidas… e eu também ajudo no que eu souber…
Gostaria de saber se o main fica mesmo na camada de controle.

patty.cefetsjbv:

Olá…
Meu nome é Patricia e estou num grupo de pesquisa onde estamos trabalhando com MVC.
Eu vi o forum e achei legal para trocar informações e gostaria de aporveitar a oportunidade para perguntar se vcs poderiam me ajudar com algumas duvidas… e eu também ajudo no que eu souber…
Gostaria de saber se o main fica mesmo na camada de controle.

fóm.

renato3110:

Fox McCloud:

Onde fica a classe Main?

O tratamento de eventos fica na View ou na Controller? Parece-me lógico que na controller, mas como?

No meu entendimento de MVC no desktop, o Controller é o gerenciador da View e do Model. O Controller é a sua classe Main (o “boot” da aplicação), mais os manipuladores de eventos que chamam as regras de negócio (Model).

Resumindo, a GUI gera eventos (View) que são tratados pelos manipuladores de evento (Controller), acessando de alguma forma a lógica da aplicação (Model).

Veja http://www.churchillobjects.com/c/14058.html.

http://www.guj.com.br/posts/list/27561.java

DAO = Data Acess Object …

é um objeto que te fornece acesso ao dado(s) …

criar um dao separado é muito mais elegante, legivel a manutenção fica melhor …

ou no meu caso que eu uso um DAO generico p/ qualquer entidade do meu banco eu uso a mesma classe DAO …

se vcs forem pensar, todo dao sempre tem:
save
load
delete
update
listAll

se você cria dentro de cada bean seus métodos para acesso a bacno de dados imagina só …

quando se trabalha em sistemas com 100 tabelas, ateh menos que isso …
criar 15 beans copiando e colando os mesmo métodos:
save
load
delete
update
listAll

e trocando dentro de cada um o nome da tabela do seus selects (caso esteja usando jdbc) não é produtivo…

pensando no pattern DAO se você tem uma classe Revista e dentro dela os métodos p/ acesso ao banco eu não diria que ele é um DAO pois alem de ser o objeto q fornece os métodos de persistencia, ele tambem é um objeto que armazena o dado retornado.

Ja vi objetos serem o DAO, O lugar aonde o dado fica guardado e alem disso fornece métodos para validação dos dados …

minha opinião é de que você tem que separar tudo isso …

criando seu Bean, seu DAO e sua classe p/ validar o seu bean…

quando se separa tudo isso você conseguir enxergar melhor o sistema e
ver aonde pode generalizar.

No caso dos DAOs são todos iguais …

No caso de validação existem as validações padrões …

No caso de beans, todos se resumem a getters e setters mas não achei muitas alternativas …

chamar de Repositorio ou DAO p/ mim não faz diferença … a diferença eh que o pattern tem o nome de DAO, se vc não quer saber qual é o pattern e quer um nome que tenha mais sentido Repositorio é a alternativa…