Você está certa! Na maior parte desses, só muda a nomenclatura, mesmo. Em outra grande parte, a diferença entre uma camada e outra é mínima. O importante é avaliar qual serve para VOCÊ. No MVC, por exemplo (que, aliás, é um pattern por si só, não representa necessariamente camadas), são três as pseudo-camadas (Modelo - M - , View - V -, Controller - C).

O importante, mesmo, é entender o conceito. Uma camada nunca se comunica com a camada acima, só com a que está imediatamente abaixo (já viu Modelo OSI, de redes? Mesma coisa). O resto você vai percebendo por si mesma. Eu, particularmente, sempre gosto de usar uma camada de serviços, uma de negócio, uma de controle e uma de apresentação. Outras são incluídas conforme a necessidade.

[]´s

A graça do padrão Layer é que vc pode ter quantas camadas quiser

É importante destinguir o padrão Layer do conceito de layer em si (camada).

Um sistema estruturado em camadas está usando o padrão layer, mas também a estruturação de andares e plataformas pode obedecer ao padrão layer. Protocolos tb podem obedecer ao padrão Layer como o TCP. Portanto, o padrão layer é mais genérico que apenas camadas de aplicação.

Quando falamos de software temos que falar primeiro em plataformas e andares e entender que dentro dos andares termos camadas de API. Nas traduções se perde muito dos conceitos. Em inglês temos Platform (plataforma), store (andar), tier (nodo) e layer (camada). Cada um representa uma coisa diferente, mas é comum as pessoas chamarem tudo de layer. A culpa é principalmente do padrão Layer que popularizou essa nomenclatura.

Os sistemas são desenhados em andares. Os andares são fatia logicas da aplicação que mediam a interação do usuário com os dados.
O primeiro andar é exatamente o que media com o usuário : andar cliente que cuida do look & feel da interação. Se a interação é via linha de comandos, html, desktop, browser, etc… tudo isso são formas da “aparencia” do andar cliente. Ele é o menino bonito. O segundo é apresentação.
A apresentação cuida das regras de navegação no cliente, controles vários de validação. Só boa aparência não chega, precisa de boa apresentação.
A seguir vem o dominio, também chamado de “negocio”. Aqui estão as regras, as entidades, as “coisas” que são especificas à finalidade da aplicação.
Depois vêm a integração. A integração é uma camada vasta e normalmente relacionada a alguma coisa de I/O. Acesso a banco via jdbc, leitura de páginas com UrlConnection, leitura e escrita de arquivos (xml ou nao), comunicação com outros sistemas através de um protocolo comum, comunicação com hardware, envio de sms, etc…
Finalmente temos os recursos. Os recursos são os arquivos em si, o banco em si mesmo, etc… são aquilo que persiste e existe fora da aplicação, inclusive memória, espaço em disco, etc…

Em relação aos nodos , normalmente , hoje , temos arquiteturas 3-tier (3-nodos) : máquina onde roda o cliente (browser, por exemplo) + servidor aplicação + servidor de banco

Percorrendo a sua lista:

Camada de Apresentação = andar de apresentação
Camada de Aplicação = plataforma de aplicação ou a aplicação em si mesma para distinguir de camada java, por exemplo.
Camada de Negócios = Camada de Domínio = Camada Business (negocio em ingles) = andar de negocios / dominio
Camada de Dados = andar de recursos
Camada de Interface = Camada Cliente = andar cliente
Camada Web = ambiguo pode ser = Camada Cliente = andar cliente no contexto de andares mas pode significa o nodo cliente no contexto de n-tier.
Camada Servidor = nodo servidor (de aplicação ou de banco)
Camada de Integração = andar de integração
Camada de Serviços = ambiguo pode se referir à camada de serviços no andar de dominio, ou no andar de integração ou na plataforma de aplicação.
Camada de Informação Distribuída(EIS) = um dos tipos de integração possivel. quando é a única, ela corresponde ao andar de integração, quando é uma das muitas usada , então é realmente um camada dentro do andar de integração.
Camada de Persistencia = um dos tipos de integração possivel. quando é a única, ela corresponde ao andar de integração, quando é uma das muitas usada , então é realmente um camada dentro do andar de integração.
Camada de Recursos = andar de recursos.

tomando atenção verá que não ha tantas assim. Camadas , camadas mesmo (layers) normalmente t~em nomes relacionados ao que fazem, por exemplo envio de email, configuração, validação , logging, transações, internacionalização/localização, etc… isso normalmente são os nomes dos pacotes onde residem as classes correspondentes. É nivel mais fino do padrão layer.

Imagine vários nodos (cubos) conetados ums aos outros. Isso é o padrão layer aplicado a nodos.
Escolha um nodo desses. Ele é separado em andares e plataformas. Cada uma destas dimensões aplica o padrão layer.
Escolha um andar. Ele é composto de várias camadas de “código”, onde se aplica o padrão layer mais uma vez.

É por isto que o padrão Layer é um padrão arquitetural. Ele está em todas as construções que vc usa num software.

Para desenvolver sistema Desktop existe esse framework:

http://griffon.codehaus.org/

Eu não o usei ainda, mas acredito que seria uma alternativa para a sua aplicação. Não sei como ele monta a estrutura de um projeto, mas talvez haja algo padrão em relação a camadas, que ele utilize.

Teste aí e veja o que acha.

asaudate:

Você está certa! Na maior parte desses, só muda a nomenclatura, mesmo. Em outra grande parte, a diferença entre uma camada e outra é mínima. O importante é avaliar qual serve para VOCÊ. No MVC, por exemplo (que, aliás, é um pattern por si só, não representa necessariamente camadas), são três as pseudo-camadas (Modelo - M - , View - V -, Controller - C).

O importante, mesmo, é entender o conceito. Uma camada nunca se comunica com a camada acima, só com a que está imediatamente abaixo (já viu Modelo OSI, de redes? Mesma coisa). O resto você vai percebendo por si mesma. Eu, particularmente, sempre gosto de usar uma camada de serviços, uma de negócio, uma de controle e uma de apresentação. Outras são incluídas conforme a necessidade.

[]´s

Olá,
Entendi sua explicação.

1 - Pattern MVC, no caso, é mais usado na camada de cliente, não é?
2 - Se na estrutura de camadas uma camada somente se comunica com a camada imediatamente abaixo, como isso vai gerar uma resposta “devolta” a camada solicitante? Assim… camada de apresentação solicita gravar dados lá no banco, na camada de recursos. Como ela vai ficar sabendo se foi gravado ou não?
3 - No caso de uma agendinha em desktop, usando as quatro camadas que disse particularmente gostar de usar, qual será a responsabilidade da camada de controle?

Obrigada

ingridfarabulini:

asaudate:

Você está certa! Na maior parte desses, só muda a nomenclatura, mesmo. Em outra grande parte, a diferença entre uma camada e outra é mínima. O importante é avaliar qual serve para VOCÊ. No MVC, por exemplo (que, aliás, é um pattern por si só, não representa necessariamente camadas), são três as pseudo-camadas (Modelo - M - , View - V -, Controller - C).

O importante, mesmo, é entender o conceito. Uma camada nunca se comunica com a camada acima, só com a que está imediatamente abaixo (já viu Modelo OSI, de redes? Mesma coisa). O resto você vai percebendo por si mesma. Eu, particularmente, sempre gosto de usar uma camada de serviços, uma de negócio, uma de controle e uma de apresentação. Outras são incluídas conforme a necessidade.

[]´s

Olá,
Entendi sua explicação.

1 - Pattern MVC, no caso, é mais usado na camada de cliente, não é?
2 - Se na estrutura de camadas uma camada somente se comunica com a camada imediatamente abaixo, como isso vai gerar uma resposta "devolta" a camada solicitante? Assim.. camada de apresentação solicita gravar dados lá no banco, na camada de recursos. Como ela vai ficar sabendo se foi gravado ou não?
3 - No caso de uma agendinha em desktop, usando as quatro camadas que disse particularmente gostar de usar, qual será a responsabilidade da camada de controle?

Obrigada :D

1 - Sim, normalmente sim.
2 - Ela se comunica apenas devolvendo uma resposta, não invocando diretamente. Seria mais ou menos que ter um código:

class CamadaA() {


public void invoca() {
Object retorno = new CamadaB().invoca();
}
}

class CamadaB() {

public Object invoca() {

Object retorno = new CamadaC().invoca();
return retorno;
}


}

class CamadaC() {

public Object invoca() {
return new Object();
}
}

Neste código, a CamadaA está explicitamente invocando a CamadaB. Implicitamente a CamadaB está se comunicando com a CamadaA ao enviar a resposta para A, mas isto é perfeitamente aceitável, já que B enviaria a resposta para qualquer que fosse a camada que a chamasse. E isto reflete em flexibilidade: poderia ser o Objeto CamadaA ou qualquer outro que chamasse B (sendo desta camada ou simliar). Então, só para deixar claro: o comportamento de enviar a resposta não está contemplado nisso de invocar a próxima camada, OK ?

3 - Desculpe, eu não achei as quatro camadas que vc citou... =/ De qualquer maneira , a responsabilidade da camada de controle no MVC é a de ligar o modelo à View. Para uma agenda em Desktop, então, a camada de controle são os listeners. Num sistema web, são os servlets. E por aí vai.

Bom, espero ter dado uma esclarecida. Qualquer coisa, só chamar. ^^

[]´s

sergiotaborda:

A graça do padrão Layer é que vc pode ter quantas camadas quiser

É importante destinguir o padrão Layer do conceito de layer em si (camada).

Um sistema estruturado em camadas está usando o padrão layer, mas também a estruturação de andares e plataformas pode obedecer ao padrão layer. Protocolos tb podem obedecer ao padrão Layer como o TCP. Portanto, o padrão layer é mais genérico que apenas camadas de aplicação.

Quando falamos de software temos que falar primeiro em plataformas e andares e entender que dentro dos andares termos camadas de API. Nas traduções se perde muito dos conceitos. Em inglês temos Platform (plataforma), store (andar), tier (nodo) e layer (camada). Cada um representa uma coisa diferente, mas é comum as pessoas chamarem tudo de layer. A culpa é principalmente do padrão Layer que popularizou essa nomenclatura.

Os sistemas são desenhados em andares. Os andares são fatia logicas da aplicação que mediam a interação do usuário com os dados.
O primeiro andar é exatamente o que media com o usuário : andar cliente que cuida do look & feel da interação. Se a interação é via linha de comandos, html, desktop, browser, etc… tudo isso são formas da “aparencia” do andar cliente. Ele é o menino bonito. O segundo é apresentação.
A apresentação cuida das regras de navegação no cliente, controles vários de validação. Só boa aparência não chega, precisa de boa apresentação.
A seguir vem o dominio, também chamado de “negocio”. Aqui estão as regras, as entidades, as “coisas” que são especificas à finalidade da aplicação.
Depois vêm a integração. A integração é uma camada vasta e normalmente relacionada a alguma coisa de I/O. Acesso a banco via jdbc, leitura de páginas com UrlConnection, leitura e escrita de arquivos (xml ou nao), comunicação com outros sistemas através de um protocolo comum, comunicação com hardware, envio de sms, etc…
Finalmente temos os recursos. Os recursos são os arquivos em si, o banco em si mesmo, etc… são aquilo que persiste e existe fora da aplicação, inclusive memória, espaço em disco, etc…

Em relação aos nodos , normalmente , hoje , temos arquiteturas 3-tier (3-nodos) : máquina onde roda o cliente (browser, por exemplo) + servidor aplicação + servidor de banco

Percorrendo a sua lista:

Camada de Apresentação = andar de apresentação
Camada de Aplicação = plataforma de aplicação ou a aplicação em si mesma para distinguir de camada java, por exemplo.
Camada de Negócios = Camada de Domínio = Camada Business (negocio em ingles) = andar de negocios / dominio
Camada de Dados = andar de recursos
Camada de Interface = Camada Cliente = andar cliente
Camada Web = ambiguo pode ser = Camada Cliente = andar cliente no contexto de andares mas pode significa o nodo cliente no contexto de n-tier.
Camada Servidor = nodo servidor (de aplicação ou de banco)
Camada de Integração = andar de integração
Camada de Serviços = ambiguo pode se referir à camada de serviços no andar de dominio, ou no andar de integração ou na plataforma de aplicação.
Camada de Informação Distribuída(EIS) = um dos tipos de integração possivel. quando é a única, ela corresponde ao andar de integração, quando é uma das muitas usada , então é realmente um camada dentro do andar de integração.
Camada de Persistencia = um dos tipos de integração possivel. quando é a única, ela corresponde ao andar de integração, quando é uma das muitas usada , então é realmente um camada dentro do andar de integração.
Camada de Recursos = andar de recursos.

tomando atenção verá que não ha tantas assim. Camadas , camadas mesmo (layers) normalmente t~em nomes relacionados ao que fazem, por exemplo envio de email, configuração, validação , logging, transações, internacionalização/localização, etc… isso normalmente são os nomes dos pacotes onde residem as classes correspondentes. É nivel mais fino do padrão layer.

Imagine vários nodos (cubos) conetados ums aos outros. Isso é o padrão layer aplicado a nodos.
Escolha um nodo desses. Ele é separado em andares e plataformas. Cada uma destas dimensões aplica o padrão layer.
Escolha um andar. Ele é composto de várias camadas de “código”, onde se aplica o padrão layer mais uma vez.

É por isto que o padrão Layer é um padrão arquitetural. Ele está em todas as construções que vc usa num software.

Surgiu uma dúvida: Para a minha agenda acredito que a melhor arquitetura é a Standalone, onde existe um só nodo com uma única pliha de plataformas e andares. Mas e se futuramente for necessário desenvolver uma agenda maior e precisar fazer uso da arquitetura 3-tier para isso, será difícil fazer essa transformação de arquitetura? Pelo que li e entendi nas explicações parece ser óbvio que não terei graves problemas porém na pratica é a mesma realidade?

E uma pergunta: Como quero desenvolver minha agenda com Swing, dos cinco andares do meu nodo ( Arq. Standalone ), para minha agenda especificamente, posso dizer que o andar Cliente é o Swing em sí (o ‘menino bonito’, q lindo :P) e o andar Apresentação seria o MVP que me ajudou a fazer no outro tópico?

Obrigada Sergio, você sempre me ajuda de forma técnica e didática ao mesmo tempo, gosto muito da forma na qual ajuda. Obrigada…

Roger75:

Para desenvolver sistema Desktop existe esse framework:

http://griffon.codehaus.org/

Eu não o usei ainda, mas acredito que seria uma alternativa para a sua aplicação. Não sei como ele monta a estrutura de um projeto, mas talvez haja algo padrão em relação a camadas, que ele utilize.

Teste aí e veja o que acha.

Oi… obrigada pela ajuda. Mas realmente quero aprender como funciona a teoria antes de desenvolver ou usar alguma ferramenta para isso. Até…

Olá…

Então dentre os quatro andares que citou (Serviços, Negócio, Controle e Apresentação) qual será a responsabilidade do andar de controle?
E obrigada pela explicação da comunicação explicita e implícita entre andares, não conhecia. Até +

No seu caso você poderia usar um AgendaViewFacade para acessar a sua AgendaView por exemplo…
Neste caso você poderia mudar a camada, agrupar camadas, etc apenas mudando a composição da Fachada

Na verdade se você pensar bem essa é a principal intenção dos patterns, manter alta coesão e baixo acoplamento

André Fonseca:

ingridfarabulini:

Oi… obrigada pela ajuda. Mas realmente quero aprender como funciona a teoria antes de desenvolver ou usar alguma ferramenta para isso. Até…

Oi Ingrid,

Uma das alternativas para você “desacoplar” esta dependência entre camadas é você usar uma Fachada, o que nada mais é do que uma forma uniforme de acessar uma outra camada.

Intent
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use
GOF

No seu caso você poderia usar um AgendaViewFacade para acessar a sua AgendaView por exemplo…
Neste caso você poderia mudar a camada, agrupar camadas, etc apenas mudando a composição da Fachada

Na verdade se você pensar bem essa é a principal intenção dos patterns, manter alta coesão e baixo acoplamento

Obrigada

ingridfarabulini:

André Fonseca:

ingridfarabulini:

Oi.. obrigada pela ajuda. Mas realmente quero aprender como funciona a teoria antes de desenvolver ou usar alguma ferramenta para isso. Até..

Oi Ingrid,

Uma das alternativas para você "desacoplar" esta dependência entre camadas é você usar uma Fachada, o que nada mais é do que uma forma uniforme de acessar uma outra camada.

Intent Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use GOF

No seu caso você poderia usar um AgendaViewFacade para acessar a sua AgendaView por exemplo..
Neste caso você poderia mudar a camada, agrupar camadas, etc apenas mudando a composição da Fachada

Na verdade se você pensar bem essa é a principal intenção dos patterns, manter alta coesão e baixo acoplamento :)

Oi André..
Você está me aconselhando a usar o padrão Façade, estou certa?
Para cada andar, deve existir um Façade? E esse Façade, por exemplo, aplicado a camada de domínio fará o papel de visão para a camada de apresentação?

Obrigada :D

oi

vc não precisa ter uma fachada para cada camada, eu já vi isso em muitos lugares mas acho desnecessário
a idéia do Facade é você uniformizar o acesso entre camadas, ou classes, ou componentes etc

suponha que você tenha uma autenticação de usuário (em um sistema web)
para fazer essa autenticação você precisaria por exemplo
- pegar login/senha do usuário e autenticar em um sistema remoto (um servidor LDAP por exemplo)
- salvar um cookie na sessão com os dados do usuário
- atualizar em um banco de dados os dados do usuário

vc teria alguns objetos com as seguintes responsabilidades

UsuarioAutenticaRemoto {
  public boolean autenticaUsuarioEmUmSistemaRemoto(Usuario usuario) {}
}
  
UsuarioSalvaCookie {
  public void salvaCookie(Usuario usuario) {}
}

UsuarioAtualiza {
  public void atualizaDadosUsuarioBD(Usuario usuario) {}
}

neste caso você poderia uniformizar o acesso usando uma camada de fachada

UsuarioFachada {

  public boolean autenticaUsuario(Usuario usuario) {

     objetoRemoto.autenticaUsuarioEmUmSistemaRemoto(usuario);
     objetoCookie.salvaCookie(usuario);
     objetoBD.atualizaDadosUsuarioBD(usuario);
  }

ai se um dia você precisar mudar um desses passos ou então acrescentar outro você irá mudar apenas a Fachada entendeu?

o que você acha? respondi a sua dúvida ou ajudei a complicar mais ?? :)

se quiser mais informação sobre Design Patterns (GOF) dê uma olhada neste site

André Fonseca:

oi

vc não precisa ter uma fachada para cada camada, eu já vi isso em muitos lugares mas acho desnecessário
a idéia do Facade é você uniformizar o acesso entre camadas, ou classes, ou componentes etc

suponha que você tenha uma autenticação de usuário (em um sistema web)
para fazer essa autenticação você precisaria por exemplo
- pegar login/senha do usuário e autenticar em um sistema remoto (um servidor LDAP por exemplo)
- salvar um cookie na sessão com os dados do usuário
- atualizar em um banco de dados os dados do usuário

vc teria alguns objetos com as seguintes responsabilidades

UsuarioAutenticaRemoto {
  public boolean autenticaUsuarioEmUmSistemaRemoto(Usuario usuario) {}
}
  
UsuarioSalvaCookie {
  public void salvaCookie(Usuario usuario) {}
}

UsuarioAtualiza {
  public void atualizaDadosUsuarioBD(Usuario usuario) {}
}

neste caso você poderia uniformizar o acesso usando uma camada de fachada

UsuarioFachada {

  public boolean autenticaUsuario(Usuario usuario) {

     objetoRemoto.autenticaUsuarioEmUmSistemaRemoto(usuario);
     objetoCookie.salvaCookie(usuario);
     objetoBD.atualizaDadosUsuarioBD(usuario);
  }

ai se um dia você precisar mudar um desses passos ou então acrescentar outro você irá mudar apenas a Fachada entendeu?

o que você acha? respondi a sua dúvida ou ajudei a complicar mais ?? :)

se quiser mais informação sobre Design Patterns (GOF) dê uma olhada neste site

Obrigada por me ajudar :D

sergiotaborda:

Quando falamos de software temos que falar primeiro em plataformas e andares e entender que dentro dos andares termos camadas de API. Nas traduções se perde muito dos conceitos. Em inglês temos Platform (plataforma), store (andar), tier (nodo) e layer (camada). Cada um representa uma coisa diferente, mas é comum as pessoas chamarem tudo de layer. A culpa é principalmente do padrão Layer que popularizou essa nomenclatura.

Achei um tanto quanto desgradavel tuas escolhas na tradução dos termos store e tier. É comum traduzirem node por nodo ou nó, mas de tier para nodo é novidade pra mim. E store remete ao conceito de armazenagem, estocagem, depósito, estas coisas. O que houve com a palavra floor para andar?

Quanto a essa questão de diferenciar os termos Layer e Tier é uma das coisas mais ambiguas e confusas da Engenharia de Software. Para muitos são apenas sinônimos, contudo se você pesquisar na internê ainda vai encontrar inúmerar fontes que apontam uma definição diferencial entre eles bastante simplista baseando-se no argumento que Layer é Lógico e Tier é Físico.
Fonte: http://blog.mhavila.com.br/2008/08/09/tiers-and-layers-camadas-fisicas-e-logicas/

Este ponto já contradiz esta referência apresentada pelo Taborda:

[1] Suntone Architecture Methodology. A 3-Dimensional approach to architectural design
Sun Microsystems
URL: http://www.makeitfly.co.uk/Presentations/suntoneam_wp_5.24.pdf

A Sun parece que possui um dom natural de complicar as coisas, talvez até em um afã inocente de promover o máximo de seriedade e buscar uma uniformidade cientifica a esta nossa área.

Também não sou muito fã de refererências a Frank Buschmann et al. Esses caras podem ser considerados deuses nas PLoP, mas fora de lá ainda são grandes desconhecidos.

FrancoC:

sergiotaborda:

Quando falamos de software temos que falar primeiro em plataformas e andares e entender que dentro dos andares termos camadas de API. Nas traduções se perde muito dos conceitos. Em inglês temos Platform (plataforma), store (andar), tier (nodo) e layer (camada). Cada um representa uma coisa diferente, mas é comum as pessoas chamarem tudo de layer. A culpa é principalmente do padrão Layer que popularizou essa nomenclatura.

Achei um tanto quanto desgradavel tuas escolhas na tradução dos termos store e tier. É comum traduzirem node por nodo ou nó, mas de tier para nodo é novidade pra mim. E store remete ao conceito de armazenagem, estocagem, depósito, estas coisas. O que houve com a palavra floor para andar?

Quanto a essa questão de diferenciar os termos Layer e Tier é uma das coisas mais ambiguas e confusas da Engenharia de Software. Para muitos são apenas sinônimos, contudo se você pesquisar na internê ainda vai encontrar inúmerar fontes que apontam uma definição diferencial entre eles bastante simplista baseando-se no argumento que Layer é Lógico e Tier é Físico.
Fonte: http://blog.mhavila.com.br/2008/08/09/tiers-and-layers-camadas-fisicas-e-logicas/

Este ponto já contradiz esta referência apresentada pelo Taborda:

[1] Suntone Architecture Methodology. A 3-Dimensional approach to architectural design
Sun Microsystems
URL: http://www.makeitfly.co.uk/Presentations/suntoneam_wp_5.24.pdf

A Sun parece que possui um dom natural de complicar as coisas, talvez até em um afã inocente de promover o máximo de seriedade e buscar uma uniformidade cientifica a esta nossa área.

Também não sou muito fã de refererências a Frank Buschmann et al. Esses caras podem ser considerados deuses nas PLoP, mas fora de lá ainda são grandes desconhecidos.

Olá… desculpe intrometer nesta pergunta feita ao Taborda mas o link que ele passou, diferentemente do que foi escrito na postagem, não fala nada a respeito de “store” e trata sim como “andares”. Por isso entendi direitinho o que ele quis passar. Quanto ao Nodo, existe no rodapé do artigo uma referência da Sun que diz a mesma coisa na imagem do cubo. Mas essa é só a minha opinião isolada. Obrigada

Olá…

Então dentre os quatro andares que citou (Serviços, Negócio, Controle e Apresentação) qual será a responsabilidade do andar de controle?
E obrigada pela explicação da comunicação explicita e implícita entre andares, não conhecia. Até +

Controle seria o intermediário entre a apresentação e os serviços (que, por sua vez, se comunica com a camada de negócio). Se ficar mais confortável, pode também adicionar o Façade aí (aí fica a camada de controle entre a apresentação e os façades). Eu não gosto muito do padrão Façade pois trabalho com SOA, e esse padrão tende a complicar mais do que facilitar pra mim.

[]´s

Olá…

Então dentre os quatro andares que citou (Serviços, Negócio, Controle e Apresentação) qual será a responsabilidade do andar de controle?
E obrigada pela explicação da comunicação explicita e implícita entre andares, não conhecia. Até +

Controle seria o intermediário entre a apresentação e os serviços (que, por sua vez, se comunica com a camada de negócio). Se ficar mais confortável, pode também adicionar o Façade aí (aí fica a camada de controle entre a apresentação e os façades). Eu não gosto muito do padrão Façade pois trabalho com SOA, e esse padrão tende a complicar mais do que facilitar pra mim.

[]´s
Olá asaudate…
Legal, não conhecia esse andar que falou. Acreditava que a comunicação do andar de Apresentação com o andar de Negócio/Domínio era direta, ou seja, se o andar de Apresentação está implementado em MVP, os models que lá estão chamarão diretamente os métodos das classes do domínio. Se criar um Façade para as classes de domínio, esse Façade pertencerá ao andar de Domínio, não?

Obrigada

Olá…

Então dentre os quatro andares que citou (Serviços, Negócio, Controle e Apresentação) qual será a responsabilidade do andar de controle?
E obrigada pela explicação da comunicação explicita e implícita entre andares, não conhecia. Até +

Controle seria o intermediário entre a apresentação e os serviços (que, por sua vez, se comunica com a camada de negócio). Se ficar mais confortável, pode também adicionar o Façade aí (aí fica a camada de controle entre a apresentação e os façades). Eu não gosto muito do padrão Façade pois trabalho com SOA, e esse padrão tende a complicar mais do que facilitar pra mim.

[]´s
Olá asaudate…
Legal, não conhecia esse andar que falou. Acreditava que a comunicação do andar de Apresentação com o andar de Negócio/Domínio era direta, ou seja, se o andar de Apresentação está implementado em MVP, os models que lá estão chamarão diretamente os métodos das classes do domínio. Se criar um Façade para as classes de domínio, esse Façade pertencerá ao andar de Domínio, não?

Obrigada :D

Sim , pertence ao domínio. Na verdade, as fachadas são usadas só para facilitar o acesso entre as camadas (veja o post do André Fonseca), ou seja, é como se elas estivessem no topo da camada, mas ainda pertecem a ela.

[]´s

Olá…

Então dentre os quatro andares que citou (Serviços, Negócio, Controle e Apresentação) qual será a responsabilidade do andar de controle?
E obrigada pela explicação da comunicação explicita e implícita entre andares, não conhecia. Até +

Controle seria o intermediário entre a apresentação e os serviços (que, por sua vez, se comunica com a camada de negócio). Se ficar mais confortável, pode também adicionar o Façade aí (aí fica a camada de controle entre a apresentação e os façades). Eu não gosto muito do padrão Façade pois trabalho com SOA, e esse padrão tende a complicar mais do que facilitar pra mim.

[]´s
Olá asaudate…
Legal, não conhecia esse andar que falou. Acreditava que a comunicação do andar de Apresentação com o andar de Negócio/Domínio era direta, ou seja, se o andar de Apresentação está implementado em MVP, os models que lá estão chamarão diretamente os métodos das classes do domínio. Se criar um Façade para as classes de domínio, esse Façade pertencerá ao andar de Domínio, não?

Obrigada :D

Sim , pertence ao domínio. Na verdade, as fachadas são usadas só para facilitar o acesso entre as camadas (veja o post do André Fonseca), ou seja, é como se elas estivessem no topo da camada, mas ainda pertecem a ela.

[]´s
Entendi… mas então qual é a especialidade do andar de controle?
Assim, até o momento estou entendendo assim: Cliente, Apresentação, Negócio/Domínio, Integração e Recursos.

Obrigada mais uma vez

Olá…

Então dentre os quatro andares que citou (Serviços, Negócio, Controle e Apresentação) qual será a responsabilidade do andar de controle?
E obrigada pela explicação da comunicação explicita e implícita entre andares, não conhecia. Até +

Controle seria o intermediário entre a apresentação e os serviços (que, por sua vez, se comunica com a camada de negócio). Se ficar mais confortável, pode também adicionar o Façade aí (aí fica a camada de controle entre a apresentação e os façades). Eu não gosto muito do padrão Façade pois trabalho com SOA, e esse padrão tende a complicar mais do que facilitar pra mim.

[]´s
Olá asaudate…
Legal, não conhecia esse andar que falou. Acreditava que a comunicação do andar de Apresentação com o andar de Negócio/Domínio era direta, ou seja, se o andar de Apresentação está implementado em MVP, os models que lá estão chamarão diretamente os métodos das classes do domínio. Se criar um Façade para as classes de domínio, esse Façade pertencerá ao andar de Domínio, não?

Obrigada :D

Sim , pertence ao domínio. Na verdade, as fachadas são usadas só para facilitar o acesso entre as camadas (veja o post do André Fonseca), ou seja, é como se elas estivessem no topo da camada, mas ainda pertecem a ela.

[]´s
Entendi… mas então qual é a especialidade do andar de controle?
Assim, até o momento estou entendendo assim: Cliente, Apresentação, Negócio/Domínio, Integração e Recursos.

Obrigada mais uma vez :D

Peraí que isso tá virando uma salada =P

Antes de mais nada, cuidado com esse monte de camadas (juro que nunca tinha ouvido alguém falar o termo “andar”). Segundo, o Controle de que estou falando é o C do MVC , e tenho certeza de que isso não pode ser considerado como uma camada por si só. Dito isto, a comunicação, na estrutura que você citou, fica assim:

Desculpe o desenho tosco (fiz no paint, mesmo), mas a idéia é essa.

[]´s

Olá…

Então dentre os quatro andares que citou (Serviços, Negócio, Controle e Apresentação) qual será a responsabilidade do andar de controle?
E obrigada pela explicação da comunicação explicita e implícita entre andares, não conhecia. Até +

Controle seria o intermediário entre a apresentação e os serviços (que, por sua vez, se comunica com a camada de negócio). Se ficar mais confortável, pode também adicionar o Façade aí (aí fica a camada de controle entre a apresentação e os façades). Eu não gosto muito do padrão Façade pois trabalho com SOA, e esse padrão tende a complicar mais do que facilitar pra mim.

[]´s
Olá asaudate…
Legal, não conhecia esse andar que falou. Acreditava que a comunicação do andar de Apresentação com o andar de Negócio/Domínio era direta, ou seja, se o andar de Apresentação está implementado em MVP, os models que lá estão chamarão diretamente os métodos das classes do domínio. Se criar um Façade para as classes de domínio, esse Façade pertencerá ao andar de Domínio, não?

Obrigada :D

Sim , pertence ao domínio. Na verdade, as fachadas são usadas só para facilitar o acesso entre as camadas (veja o post do André Fonseca), ou seja, é como se elas estivessem no topo da camada, mas ainda pertecem a ela.

[]´s
Entendi… mas então qual é a especialidade do andar de controle?
Assim, até o momento estou entendendo assim: Cliente, Apresentação, Negócio/Domínio, Integração e Recursos.

Obrigada mais uma vez :D

Peraí que isso tá virando uma salada =P

Antes de mais nada, cuidado com esse monte de camadas (juro que nunca tinha ouvido alguém falar o termo “andar”). Segundo, o Controle de que estou falando é o C do MVC , e tenho certeza de que isso não pode ser considerado como uma camada por si só. Dito isto, a comunicação, na estrutura que você citou, fica assim:

Desculpe o desenho tosco (fiz no paint, mesmo), mas a idéia é essa.

[]´s

Oi, desculpe pela “salada”. Agora entendi, você está falando de Controle do MVC, desculpe. Já a palavra ‘andar’ define uma camada lógica.
É que eu aprendi diferente. MVC, para mim, está lá no andar Cliente e o MVP está no andar Apresentação.
No MVP, as classes responsáveis pela comunicação com o andar inferior são os modelos, ou melhor, o M do MVP.

E tanto MVC quanto MVP estão no andar, ou seja, M-V-P ‘as três letras’ estão juntas no andar x e não espalhadas pelos andares x,y,z. Foi assim que aprendi, desculpe… eu sei que isso é um assunto muito discutido aqui no fórum como pode conferir neste tópico.

Obrigada pela sua ajuda… Até…

ingridfarabulini:

Oi, desculpe pela “salada”. Agora entendi, você está falando de Controle do MVC, desculpe. Já a palavra ‘andar’ define uma camada lógica.
É que eu aprendi diferente. MVC, para mim, está lá no andar Cliente e o MVP está no andar Apresentação.
No MVP, as classes responsáveis pela comunicação com o andar inferior são os modelos, ou melhor, o M do MVP.

E tanto MVC quanto MVP estão no andar, ou seja, M-V-P ‘as três letras’ estão juntas no andar x e não espalhadas pelos andares x,y,z. Foi assim que aprendi, desculpe… eu sei que isso é um assunto muito discutido aqui no fórum como pode conferir neste tópico.

Obrigada pela sua ajuda… Até…

Que é exatamente o que eu “tentei” desenhar =P (MVP e MVC são praticamente a mesma coisa, caso você tenha notado). No desenho que mandei, o MVC está na camada Cliente. O resto… bom, é o resto.

Espero que esteja fazendo um pouco mais de sentido para você.

[]´s

asaudate:

ingridfarabulini:

Oi, desculpe pela “salada”. Agora entendi, você está falando de Controle do MVC, desculpe. Já a palavra ‘andar’ define uma camada lógica.
É que eu aprendi diferente. MVC, para mim, está lá no andar Cliente e o MVP está no andar Apresentação.
No MVP, as classes responsáveis pela comunicação com o andar inferior são os modelos, ou melhor, o M do MVP.

E tanto MVC quanto MVP estão no andar, ou seja, M-V-P ‘as três letras’ estão juntas no andar x e não espalhadas pelos andares x,y,z. Foi assim que aprendi, desculpe… eu sei que isso é um assunto muito discutido aqui no fórum como pode conferir neste tópico.

Obrigada pela sua ajuda… Até…

Que é exatamente o que eu “tentei” desenhar =P (MVP e MVC são praticamente a mesma coisa, caso você tenha notado). No desenho que mandei, o MVC está na camada Cliente. O resto… bom, é o resto.

Espero que esteja fazendo um pouco mais de sentido para você.

[]´s

Obrigada pela ajuda

Vc entendeu certo.

Parta do modelo standalone. Onde tudo está na mesma máquina, inclusive o banco que é embutido dentro da aplicação. Não ha qq comunicação de rede neste modelo.
Agora vamos colocar o banco na mesma máquina, mas ligado via TCP/IP. O banco não está mais embutido e o andar de recursos do nodo standalone não mais contém o banco. A aplicação não é mais standalone. Porque o banco está ligado À aplicação o andar de integração tem que compensar esse fato, já que, para o resto dos andares superiores as coisas não mudaram.

Agora imagine que colocamos um servidor de aplicação nessa historia. A aplicação que era standalone e 1-tier, e virou 2-tier, agora virou 3-tier. Movemos a logica de negocio (dominio) para o servidor. O andar dominio que tinhamos no standalone foi agora para o servidor de aplicação. Então o andar dominio na aplicação tem que compensar esse fato. Ele irá ser apenas uma fchada para o andar de intergração que se irá comunicar com o servidor de aplicação onde estão o dominio e o SA irá se comunicar com o banco.

Veja que cada nodo continua tendo os mesmo andares, mas a implementação deles muda. Normalmente muda para um esquema de delegação/comunicação remota.
Veja que ao incluir o servidor de aplicação ele é um novo nodo com os 5 andares. Mas a implementação é diferente. O andar cliente, por exemplo, não será swing, nem web, serão webservices, REST ou interfaces RMI. A apresentação será o andar que (como sempre) mapeia o dominio para o cliente. O andar apresentação original não mudou nada e continua controlando o funcionamentoe das telas swing.

Quando os andares estão bem separados, esta explosão para n-tier é natural e simples. (Se não é simples é porque os andares não estão bem separados).

Respondendo À sua outra pergunta sobre comunicação de camadas: o que está em causa não é a comunicação em si, mas o conhecimento da responsabilidade.
A camada ( estou falando genericamente aqui, pode ser nodo, andar,… qq tipo de camda) superior conhece a responsabilidade da camada inferior, mas a inferior não conhece
a responsabilidade da camada superior. A razão para isso é simples: uma camada pode ter N camadas superiores diferentes.Por isso é muito importante separar bem as responsabilidades e nunca usar logicas do tipo “aqui no dominio eu vou fazer assim porque lá na apresentação eu faço assado” A implementação da camada inferior não pode assumir nada sobre as camadas superiores. (Em particular pode nem haver um camada superior).

Repare que eu disse que a camada superior conhece a responsabilidade da inferiro, eu não disse que conhece a implementação. Por exemplo, se apresentação faz uso de um serviço de dominio, ela conhece o que o serviço faz, mas ela não sabe - nem deve saber - se o serviço é local ou remoto, se é EJB ou webservices,se usa List ou Set, etc…

O Swing em si é apenas uma API java. Aquilo que vc constroi com ele, é que é o cliente. Ou seja, o cliente é aquele conjunto de telas, com botões num certo lugar com campos em certo lugar, etc… que vc criou. O cliente é montado em swing, mas não é o swing em si mesmo, é aquilo que vc montou com swing. Se eu usar o swing e montar diferente, terei um cliente diferente.

Olá Sérgio, tudo bem com você moço?
Obrigada + uma vez me ajudar :oops:

sergiotaborda:

Parta do modelo standalone. Onde tudo está na mesma máquina, inclusive o banco que é embutido dentro da aplicação. Não ha qq comunicação de rede neste modelo.
Agora vamos colocar o banco na mesma máquina, mas ligado via TCP/IP. O banco não está mais embutido e o andar de recursos do nodo standalone não mais contém o banco. A aplicação não é mais standalone. Porque o banco está ligado À aplicação o andar de integração tem que compensar esse fato, já que, para o resto dos andares superiores as coisas não mudaram.

Agora imagine que colocamos um servidor de aplicação nessa historia. A aplicação que era standalone e 1-tier, e virou 2-tier, agora virou 3-tier. Movemos a logica de negocio (dominio) para o servidor. O andar dominio que tinhamos no standalone foi agora para o servidor de aplicação. Então o andar dominio na aplicação tem que compensar esse fato. Ele irá ser apenas uma fchada para o andar de intergração que se irá comunicar com o servidor de aplicação onde estão o dominio e o SA irá se comunicar com o banco.

Veja que cada nodo continua tendo os mesmo andares, mas a implementação deles muda. Normalmente muda para um esquema de delegação/comunicação remota.
Veja que ao incluir o servidor de aplicação ele é um novo nodo com os 5 andares. Mas a implementação é diferente. O andar cliente, por exemplo, não será swing, nem web, serão webservices, REST ou interfaces RMI. A apresentação será o andar que (como sempre) mapeia o dominio para o cliente. O andar apresentação original não mudou nada e continua controlando o funcionamentoe das telas swing.

1 - Quando o banco de dados passa a ser ligado via TCP/IP na mesma máquina, transformando Standalone em 2-Tier, passamos a ter dois nodos : nodo cliente e nodo banco. Como o andar Integração do nodo cliente precisa compensar o fato da mudança ‘passa a interagir com o andar Cliente do nodo banco’ o andar Recursos, ainda do nodo cliente, simplesmente vai estar lá porém sem atividade alguma?
2 - Quando passamos do 2-Tier para o 3-Tier entra a existência de pelo menos três nodos : cliente, servidor de aplicação ‘SA’ e dados. Então passamos a ter a seguinte hierarquia : nodo cliente, andar Integração fala com nodo SA, andar Cliente. Nodo SA, andar Integração fala com nodo dados, andar Cliente. Se isso está certo, me resta repetir a mesma pergunta da nº1 : o andar Recursos dos nodos cliente e SA simplesmente vão estar lá, porém sem atividade alguma? Ou estou enganada e existe alguma atividade alí?
3 - O nodo banco pode ser, como exemplo, um SGBD? ‘Postgree, MySQL,…’

sergiotaborda:

ingridfarabulini:

E uma pergunta: Como quero desenvolver minha agenda com Swing, dos cinco andares do meu nodo ( Arq. Standalone ), para minha agenda especificamente, posso dizer que o andar Cliente é o Swing em sí (o ‘menino bonito’, q lindo :P) e o andar Apresentação seria o MVP que me ajudou a fazer no outro tópico?

O Swing em si é apenas uma API java. Aquilo que vc constroi com ele, é que é o cliente. Ou seja, o cliente é aquele conjunto de telas, com botões num certo lugar com campos em certo lugar, etc… que vc criou. O cliente é montado em swing, mas não é o swing em si mesmo, é aquilo que vc montou com swing. Se eu usar o swing e montar diferente, terei um cliente diferente.

Obrigada por me acompanhar Vou aguardar pela resposta…
Por favor, nao quero atrapalhar… Até +

FrancoC:

sergiotaborda:

Quando falamos de software temos que falar primeiro em plataformas e andares e entender que dentro dos andares termos camadas de API. Nas traduções se perde muito dos conceitos. Em inglês temos Platform (plataforma), store (andar), tier (nodo) e layer (camada). Cada um representa uma coisa diferente, mas é comum as pessoas chamarem tudo de layer. A culpa é principalmente do padrão Layer que popularizou essa nomenclatura.

Achei um tanto quanto desgradavel tuas escolhas na tradução dos termos store e tier. É comum traduzirem node por nodo ou nó, mas de tier para nodo é novidade pra mim. E store remete ao conceito de armazenagem, estocagem, depósito, estas coisas. O que houve com a palavra floor para andar?

Desculpem, na realidade é um erro de escrita. A palavra certa é story (andar) (“How high is a three story building ?”)
Floor significa “piso” , o chão. Piso refere-se à area onde se pode andar, story se refere ao volume necessário ao piso e à estrutura do prédio que suporta esse volume.

Por isso que traduzo story por andar.

Essa fonte define tier como

Isso não é tier, é plataforma.

O termo tier realmente normalmente é fisico e pode ser usado para se referir a um conjunto de nodos. Contudo, numa arquiterura cada nodo sempre é um template para muitos nodos. E nessa prespetiva são equivalentes. eu não gosto muito de me referir a tier, mas no texto que citou foi necessário.

como vc mesmo disse é uma area controversa ( a tradução , não tanto os termos originais). A ideia é abolir o uso de layer e tier porque são ambiguos. Desambiguidade é a primeira diretiva para termos termos tecnicos mais , digamos, “cientificos”.

O que importa é que se tenha entendido o conceito.

Se vc identificar andar com camada lógica, vc terá o problema de não ter um conceito para camada de código e ai será forçado a usar o mesmo nome para tudo, que é muito ruim para a comunicação clara.

correto.

É dificil o andar de recurso não estar lá. Arquivos de configuração, e os próprios jar estão neste andar.

O andar do nodo cliente antes usada uma configuração jdbc local. digamos que usava HSQL. Agora ele tem que usar uma configuração remota.
Como o JDBC é bem desenhado ( um dos melhores exemplos de desenho de API) na prática vc muda o url de definição,mas em outras tecnologias e plataformas (delhpi, .net) não é assim tão simples e têm que ser feitas alterações no codigo.

a sua lógica está certa. a unica coisa que vc está esquecendo é que "Recurso’ não é apenas o banco de dados e “Dado” não é apenas que é persistido no banco. Por exemplo, se seu sistema é i18n vc terá um properties com as mesnagems e textos, isso tb é um recurso. E como disse o proprio jar é um recurso. Mesmo se vc tiver apenas um banco remoto, vc tem que configurar os parametros de enderço em algum lugar. isso é um recurso.

A aplicação no nodo banco é um SGDB. O SGDB contém os andares necessários e ele corre sobre uma plataforma.
O SGDB não é o nodo todo, é um item no nodo.

O Swing em si é apenas uma API java. Aquilo que vc constroi com ele, é que é o cliente. Ou seja, o cliente é aquele conjunto de telas, com botões num certo lugar com campos em certo lugar, etc… que vc criou. O cliente é montado em swing, mas não é o swing em si mesmo, é aquilo que vc montou com swing. Se eu usar o swing e montar diferente, terei um cliente diferente.

Então o MVP que me ajudou a criar no outro tópico não está no andar Apresentação e sim no andar Cliente?

Não sei como vc conclui isso. O MVP pertence na apresentação. O V é o elo de conexão ao andar cliente e o M ao andar dominio e inferiores.
O que eu disse é que o que se constroi com swing, telas, janelas, buttões, etc… isso é o cliente. Por exemplo, se vc decidir que quando o cara aperta um botão vc emite um som, isso é apenas responsabilidade do cliente. nenhuma outro andar sabe dessa feature.

sergiotaborda:

sergiotaborda:

ingridfarabulini:

E uma pergunta: Como quero desenvolver minha agenda com Swing, dos cinco andares do meu nodo ( Arq. Standalone ), para minha agenda especificamente, posso dizer que o andar Cliente é o Swing em sí (o ‘menino bonito’, q lindo :P) e o andar Apresentação seria o MVP que me ajudou a fazer no outro tópico?

O Swing em si é apenas uma API java. Aquilo que vc constroi com ele, é que é o cliente. Ou seja, o cliente é aquele conjunto de telas, com botões num certo lugar com campos em certo lugar, etc… que vc criou. O cliente é montado em swing, mas não é o swing em si mesmo, é aquilo que vc montou com swing. Se eu usar o swing e montar diferente, terei um cliente diferente.

Então o MVP que me ajudou a criar no outro tópico não está no andar Apresentação e sim no andar Cliente?

Não sei como vc conclui isso. O MVP pertence na apresentação. O V é o elo de conexão ao andar cliente e o M ao andar dominio e inferiores.
O que eu disse é que o que se constroi com swing, telas, janelas, buttões, etc… isso é o cliente. Por exemplo, se vc decidir que quando o cara aperta um botão vc emite um som, isso é apenas responsabilidade do cliente. nenhuma outro andar sabe dessa feature.

Obrigada

ingridfarabulini:

sergiotaborda:

sergiotaborda:

ingridfarabulini:

E uma pergunta: Como quero desenvolver minha agenda com Swing, dos cinco andares do meu nodo ( Arq. Standalone ), para minha agenda especificamente, posso dizer que o andar Cliente é o Swing em sí (o ‘menino bonito’, q lindo :P) e o andar Apresentação seria o MVP que me ajudou a fazer no outro tópico?

O Swing em si é apenas uma API java. Aquilo que vc constroi com ele, é que é o cliente. Ou seja, o cliente é aquele conjunto de telas, com botões num certo lugar com campos em certo lugar, etc… que vc criou. O cliente é montado em swing, mas não é o swing em si mesmo, é aquilo que vc montou com swing. Se eu usar o swing e montar diferente, terei um cliente diferente.

Então o MVP que me ajudou a criar no outro tópico não está no andar Apresentação e sim no andar Cliente?

Não sei como vc conclui isso. O MVP pertence na apresentação. O V é o elo de conexão ao andar cliente e o M ao andar dominio e inferiores.
O que eu disse é que o que se constroi com swing, telas, janelas, buttões, etc… isso é o cliente. Por exemplo, se vc decidir que quando o cara aperta um botão vc emite um som, isso é apenas responsabilidade do cliente. nenhuma outro andar sabe dessa feature.

Oi Sergio, obrigada pelas respostas. Entendi suas explicações e acho que agora vou saber até perguntar melhor o que realmente procuro entender. No nodo Cliente, andar Apresentação que é onde está o MVP, a porta de entrada desse andar é o V. Mas, o que conterá/estará no V? Telas em Swing é que não será, visto que isso pertence ao andar Cliente. O MVP deve estar mesmo no andar Apresentação ou no andar Cliente?

Do ponto de vista do MVP o V é conjunto pré-definido de classes e interfaces que o presenter pode manipular sem ter que saber o que está além do V.
Na prática, o V comunica diretamente com o cliente swing. Imagine que vc tem o swing implementando essas interfaces e classes do V.
São prespetivas diferentes da mesma coisa. A relação que vc tem com a sua mae é de relação é a mesma que ela tem consigo, mas na sua prespetiva é uma relação filha-mae, mas na dela é mae-filha. mas a relação é uma só.
No OO das camadas sempre existe uma fronteira onde , a partir dali, vc não conhece mais o que acontece , vc tem que confiar nos contratos dos objetos / interfaces. O presenter confiar que o V saberá comunicar com que interessa, o cliente implementa o V para que possa delegar ao presenter algumas decisões.

Acho que agora vai confundir de vez Mas o truque está em entender cada camada por si e depois entender o que acontece na fronteira. Na fronteira vc tem interfaces de uma camada sendo implementada pela outra.

quem aprende design patterns só estudando, se torna péssimo programador; o q complica coisas simples. durante sua experiencia naturalmente vai reconhecer a necessidade.
não precisa ir atrás de design patterns, eles vem até vc

editado:
lógico, estou dizendo isso partindo do principio q vc é inciante.

bobmoe:

ingridfarabulini:

Faz pouquíssimo tempo que estudo Java ‘um ano e meio aprox.’ e sempre escrevi meus programas sem seguir nenhum pattern ou qualquer tipo de arquitetura. Mas de uns meses para cá estou interessada em seguir alguns padrões mínimos para um bom desenvolvimento ‘ou pelo menos que facilite a vida de qualquer programador(a) quando necessário realizar alguma manutenção neste código’. Pensando nisso iniciei meus estudos com o pattern Layers, ou camadas lógicas, como preferir.

quem aprende design patterns só estudando, se torna péssimo programador; o q complica coisas simples. durante sua experiencia naturalmente vai reconhecer a necessidade.
não precisa ir atrás de design patterns, eles vem até vc

editado:
lógico, estou dizendo isso partindo do principio q vc é inciante.

Tenho que discordar. O objetivo de estudar design patterns não é ser um bom programador. é ser um bom designer. E se o design é bom, a programação é trivial. Acontece que muita gente acha que qualquer tipo de design vale. Que se muda depois, KISS essa palermice toda… na realidade não é trivial conseguir um bom design e se a pessoa almeja um dia ser um bom designer, precisa sim aprender patterns.

Saber patterns é saber uma linguagem diferente. Ajuda a pensar. Ajuda a simplificar. Ajuda a se tornar um desenvolvedor melhor e mais eficaz.
Em particular os design patterns o tornam um melhor designer, mas outros tipos de patterns ajudam noutras areas ( arquiteura, requisitos, etc…)

Eu parabenizo a Ingrid e as pessoas que, como ela, entendem que o design é um passo importante para ser um bom desenvolvedor.
Não é possivel ser um bom desenvolvedor de software apenas sabendo programar. E até para programar bem - threads, por exemplo - vc precisa saber desenhar. Não é possível construir uma aplicação multithread usando o debuger e a força bruta…

Em particular, a Ingrid mostrou no outro tópico (neste tb, mas especialmente no outro) que embora com pouca experiência consegue entender conceitos como MVC e MVP e implementá-los. Coisa que muita gente aqui não conseguiu fazer em anos. Tem muitos que nem sabem o que é MVC e não é por falta de pessoas explicando…

Sinceramente esta conversa que padrões é ruim e não ha que se preocupar com eles é coisa de pessoas que não ou não entenderam até hoje o que é um design pattern e sua utilidade, ou que tentam avacalhar com a profissão dos outros. Patterns são importantes sim. Em todos os ramos, não apenas em software. Live with it!

Um péssimo programador só é péssimo exatamente porque nunca estudou. E estudar não significa ler. Significa entender e saber aplicar.
Não vale dizer que porque 90% dos desgraçados não sabem aplicar singleton ou <coloque um padrão aqui> então padrões é algo ruim e não merece a pena aprender.

Design patterns não é sobrengenharia. Parem de dizer que é.

sergiotaborda:

ingridfarabulini:

sergiotaborda:

sergiotaborda:

ingridfarabulini:

E uma pergunta: Como quero desenvolver minha agenda com Swing, dos cinco andares do meu nodo ( Arq. Standalone ), para minha agenda especificamente, posso dizer que o andar Cliente é o Swing em sí (o ‘menino bonito’, q lindo :P) e o andar Apresentação seria o MVP que me ajudou a fazer no outro tópico?

O Swing em si é apenas uma API java. Aquilo que vc constroi com ele, é que é o cliente. Ou seja, o cliente é aquele conjunto de telas, com botões num certo lugar com campos em certo lugar, etc… que vc criou. O cliente é montado em swing, mas não é o swing em si mesmo, é aquilo que vc montou com swing. Se eu usar o swing e montar diferente, terei um cliente diferente.

Então o MVP que me ajudou a criar no outro tópico não está no andar Apresentação e sim no andar Cliente?

Não sei como vc conclui isso. O MVP pertence na apresentação. O V é o elo de conexão ao andar cliente e o M ao andar dominio e inferiores.
O que eu disse é que o que se constroi com swing, telas, janelas, buttões, etc… isso é o cliente. Por exemplo, se vc decidir que quando o cara aperta um botão vc emite um som, isso é apenas responsabilidade do cliente. nenhuma outro andar sabe dessa feature.

Oi Sergio, obrigada pelas respostas. Entendi suas explicações e acho que agora vou saber até perguntar melhor o que realmente procuro entender. No nodo Cliente, andar Apresentação que é onde está o MVP, a porta de entrada desse andar é o V. Mas, o que conterá/estará no V? Telas em Swing é que não será, visto que isso pertence ao andar Cliente. O MVP deve estar mesmo no andar Apresentação ou no andar Cliente?

Do ponto de vista do MVP o V é conjunto pré-definido de classes e interfaces que o presenter pode manipular sem ter que saber o que está além do V.
Na prática, o V comunica diretamente com o cliente swing. Imagine que vc tem o swing implementando essas interfaces e classes do V.
São prespetivas diferentes da mesma coisa. A relação que vc tem com a sua mae é de relação é a mesma que ela tem consigo, mas na sua prespetiva é uma relação filha-mae, mas na dela é mae-filha. mas a relação é uma só.
No OO das camadas sempre existe uma fronteira onde , a partir dali, vc não conhece mais o que acontece , vc tem que confiar nos contratos dos objetos / interfaces. O presenter confiar que o V saberá comunicar com que interessa, o cliente implementa o V para que possa delegar ao presenter algumas decisões.

Acho que agora vai confundir de vez Mas o truque está em entender cada camada por si e depois entender o que acontece na fronteira. Na fronteira vc tem interfaces de uma camada sendo implementada pela outra.

Independentemente do design pattern que vou usar no andar Cliente ele sempre terá uma classe que fará o output de dados para o input dos mesmos no andar Apresentação. Sendo assim…
No caso do andar Cliente estar com o pattern MVC presente, o V ( que pode ser uma Janela Swing ) fará o input dos dados do usuário para este andar e o M ( que é o modelo onde estão os dados que V está apresentando ) fará o output dos dados desse andar para fora. Esse output do andar Cliente é quem fará o input no andar Apresentação. Se no caso do andar Apresentação estar com o pattern MVP presente, o V ( que pode ser uma interface implementada pelo M do andar Cliente ) fará o input dos dados ( dados do output do M do andar Cliente ) para este andar e o M ( que é o modelo onde estão os dados que V recebeu ) fará o output dos dados desse andar para fora. Esse output do andar Apresentação é quem fará o input no andar Domínio… e assim continuando a cadeia de andares.

Se isso estiver certo, o desenho dessa construção é simplesmente perfeita. Poderia executar atividades internas dentro de cada andar independente dele conhecer ou não o próximo andar. Claro que quando necessário ele vai precisar descer para a camada inferior mas caso não precise ele poderá se manter exercendo uma determinada atividade importante somente para aquele andar sem precisar passar pelos demais, não é demaiiisss??

Agora fiquei ansiosa pela resposta… Até +, obrigada

Bom, é isso ai. Não tenho mais nada a acrescentar.

sergiotaborda:

bobmoe:

ingridfarabulini:

Faz pouquíssimo tempo que estudo Java ‘um ano e meio aprox.’ e sempre escrevi meus programas sem seguir nenhum pattern ou qualquer tipo de arquitetura. Mas de uns meses para cá estou interessada em seguir alguns padrões mínimos para um bom desenvolvimento ‘ou pelo menos que facilite a vida de qualquer programador(a) quando necessário realizar alguma manutenção neste código’. Pensando nisso iniciei meus estudos com o pattern Layers, ou camadas lógicas, como preferir.

quem aprende design patterns só estudando, se torna péssimo programador; o q complica coisas simples. durante sua experiencia naturalmente vai reconhecer a necessidade.
não precisa ir atrás de design patterns, eles vem até vc

editado:
lógico, estou dizendo isso partindo do principio q vc é inciante.

Tenho que discordar. O objetivo de estudar design patterns não é ser um bom programador. é ser um bom designer. E se o design é bom, a programação é trivial. Acontece que muita gente acha que qualquer tipo de design vale. Que se muda depois, KISS essa palermice toda… na realidade não é trivial conseguir um bom design e se a pessoa almeja um dia ser um bom designer, precisa sim aprender patterns.

Saber patterns é saber uma linguagem diferente. Ajuda a pensar. Ajuda a simplificar. Ajuda a se tornar um desenvolvedor melhor e mais eficaz.
Em particular os design patterns o tornam um melhor designer, mas outros tipos de patterns ajudam noutras areas ( arquiteura, requisitos, etc…)

Eu parabenizo a Ingrid e as pessoas que, como ela, entendem que o design é um passo importante para ser um bom desenvolvedor.
Não é possivel ser um bom desenvolvedor de software apenas sabendo programar. E até para programar bem - threads, por exemplo - vc precisa saber desenhar. Não é possível construir uma aplicação multithread usando o debuger e a força bruta…

Em particular, a Ingrid mostrou no outro tópico (neste tb, mas especialmente no outro) que embora com pouca experiência consegue entender conceitos como MVC e MVP e implementá-los. Coisa que muita gente aqui não conseguiu fazer em anos. Tem muitos que nem sabem o que é MVC e não é por falta de pessoas explicando…

Sinceramente esta conversa que padrões é ruim e não ha que se preocupar com eles é coisa de pessoas que não ou não entenderam até hoje o que é um design pattern e sua utilidade, ou que tentam avacalhar com a profissão dos outros. Patterns são importantes sim. Em todos os ramos, não apenas em software. Live with it!

Um péssimo programador só é péssimo exatamente porque nunca estudou. E estudar não significa ler. Significa entender e saber aplicar.
Não vale dizer que porque 90% dos desgraçados não sabem aplicar singleton ou <coloque um padrão aqui> então padrões é algo ruim e não merece a pena aprender.

Design patterns não é sobrengenharia. Parem de dizer que é.

Cara, sou obrigado a concordar com tudo que você disse.
No ponto em que você citou MVC e chuto algo em torno de 80% das pessoas que dizem saber MVC não tem a menor idéia do que estão falando e acham que sabem.
Outro ponto:

Perfeito! É o que sempre digo, poxa, ta lá! qualquer um pode ler, estudar, perguntar, quebrar a cabeça, fazer errado e… aprender! Dedicação é a palavra chave!

Lógico que, como citei em outro tópico a pouco, há pessoas que não tem o menor feeling pra coisa, mas principalmente pessoas que não aprendem por que nunca tiveram um bom professor (no caso das não auto-didatas) que lhe desse um bom começo.

Digo isso por que toda vez que vou tentar explicar algo pra alguém parto de um princípio básico:
1- Explico da forma que gostaria que tivessem me ensinado;

Simples!

Ensinei/expliquei algumas coisas de orientação a objetos pra minha sogra que é advogada! Claro que o conhecimento de programação dela é nulo, mas sempre há meios que você possa usar, analogias existem para isso (se bem utilizadas).

Olá rapazes Olá Sérgio, tudo bem? Obrigada por me ajudar!

Hoje comprei uma revista que me fez notar que o MVP é um padrão da Camada/Andar de Apresentação. Ótimo 8)
E também já sei que a Camada/Andar de Apresentação está abaixo da Camada/Andar de Visualização/Cliente.
Hierarquia: [ Visualização/Cliente --> Apresentação --> Domínio/Negócio --> Integração --> Recurso ]
Estou fazendo minha Agenda em Swing…

A primeira pergunta: Qual será o pattern apropriado da Camada/Andar de Visualização/Cliente para trabalhar com o Swing?
A segunda pergunta: Quem é a classe responsável em fazer o output da Camada/Andar de Cliente/Visualização para a Camada/Andar de Apresentação?

Desculpem pelo meu desconhecimento…
Obrigada Ficarei no aguardo…

humm… o swing em si já segue padrão como composite e observer.
Tlv o que vc precisa nesse ponto não são padrões per se mas formas de trabalhar. Coisas como Separation of Concerns , DRY (Dont repeat yoursefl), variáveis polimorficas ( aka Programar para interfaces) encapsulamento, são essenciais práticas OO presentes em qq camada/andar/nodo

Construir telas swing OO é um desafio no incio, mas rápidamente vc entende como.

Lembre-se que o swing será visto pelo presenter através de interfaces e objetos da view. Portanto o swing tem que ser utilizado como uma ferramenta para implementar a view que o presenter espera.

Esta eu não sei se entendi.
Suponho que vc esteja pensando em formulário que tem um botão salvar. Acho que a sua pergunta é :" quem responde a esse save?"
Resposta : O presenter desse formulário.

Entenda que o output do cliente e o input da apresentação se sobrepoem em um unico objeto ( por exemplo, no caso, o event handler do botão).

não sei se respondi…

Tb concordo com vc. Mas eu chamo a esse felling : “Talento”.
Se a pessoa não tem algum talento natural para a área, ela nunca irá compreender. Estudando ela poderá até saber e aplicar,mas nunca poderá compreender o suficiente para inovar e/ou se aproveitar do que aprendeu em um “lado” para aplicar no 'outro".

O bom professor é aquele que o ensina a pensar, não aquele que dita a resposta.

O problema da área é que temos muitas pessoas tem talento. E as que o têm não têm opção para o desenvolver.
É comum que uma pessoa com talento que entra como estagiário ou junior (às vezes até mesmo como sênior) seja barrado pelo resto da equipa.
É o denominador comum que puxa as pessoas para baixo. Um cara assim, normalmente subjuga-se à pressão e aquele pouco talento que tinha se perde… ou o cara se revolta e parte “para cima da equipe”. Existem várias formas de fazer isso. A mais comum é o cara ir para outro lugar, tlv passando pelo mesmo processo de novo. Depois temos o cara que usa o seu talento para fazer a sua parte do trabalho bem feita e ainda corrige a dos outros sem reclamar ( para isto é essencial um ambiente de codigo compartilhado). E temos o lider silencioso. aquele que pelo exemplo força os outros a seguir as mesmas práticas. Finalmente temos o cara que tenta convencer verbalmente os outros … este se dá muito mal porque a primeira reação da equipa é achar que o cara é arrogante ( na minha experiência, arrogante é quem não tem talento - nem razão - mas impõe sua intenção no grito)

Isso implica que vc conheça do assunto o suficiente para saber como gostaria que lhe tivessem ensinado
Ter esse conhecimento é isso que destingue um Professor ( com P) de um cara que dita resultados…

Olá Sergio, nossa mais uma vez obrigada!

Ou seja, a interface do Andar de Apresentação (que será o V do MVP) será implementada no Swing, certo?
Esse objeto da view nada mais é que a classe onde construi a tela do formulário, no caso?

sergiotaborda:

Esta eu não sei se entendi.
Suponho que vc esteja pensando em formulário que tem um botão salvar. Acho que a sua pergunta é :" quem responde a esse save?"
Resposta : O presenter desse formulário.

Entenda que o output do cliente e o input da apresentação se sobrepoem em um unico objeto ( por exemplo, no caso, o event handler do botão).

não sei se respondi…

Essa sobreposição seria isso?

public void addBotaoCadastrar(ActionListener al) {   
      bCadastrar.addActionListener(al);   
   }

Assim Taborda, acho que você vai entender melhor a minha pergunta: no Andar de Apresentação com MVP o ‘M’ se comunica com o Andar de Domínio, certo? ( Apresentação > Domínio )
No Andar de Cliente com Swing qual classe é responsável em se comunicar com o andar de Apresentação? É a mesma classe onde construi o formulário ( onde instancio os JComponents que são mostrados na tela )?

Porque assim: entendi que no Andar de Cliente existe a classe que é essa onde construo a tela e é onde injeto os listeners do Presenter ( da camada abaixo ) que capturam os events dos componentes no Cliente.

Para ficar melhor ainda: No MVP eu sei que o ‘V’ é o input, o ‘P’ realiza algo interessante para este andar e o ‘M’ é o output. Mas, e no andar Cliente com Swing? Quem é o output? O input eu sei que são as interações do usuário com a tela… mas e o output? Como MVP está na apresentação e não no cliente fiquei sem entender…

O problema é ligar o Cliente a Apresentação.
Vou estudar as dicas de OO que solicitou acima…

Obrigada por me aturar… não sei nem mais o que dizer :oops:
Me ajuda demaissss… além de ser um excelente profissional. Até +

ingridfarabulini:

Olá Sergio, nossa mais uma vez obrigada!

Ou seja, a interface do Andar de Apresentação (que será o V do MVP) será implementada no Swing, certo?
Esse objeto da view nada mais é que a classe onde construi a tela do formulário, no caso?

Pode ser. No seu caso é. Para cada applicação é diferente.

Não. Essa classe não faz parte dos andares. Essa classe faz parte da aplicação ,mas não dos andares.

O M comunica com andar de dominio. Sim. E o andar cliente de comunica com o andar de apresentação. sim.
Mas vc precisa entender que cada andar contém muitiplas comunicações. Por exemplo o andar de apresentação contem diversos presenters , e por consequencia está lidado a difernetes modelos e views. A view é um objeto complexo e não ha um objeto unico que chame o presenter.

Por exemplo, vc quer ter um menu de “sair” que quando clicado termina a aplicação. Mas antes de terminar devemos perguntar o usuário se quer mesmo fazer isso, pois ele pode ter-se enganado. Isto implica que o botão swing, irá invocar um listener swing, que irá chamar o método X do presenter que usará um objeto de view para lançar a pergunta ao usuário, e conforme a resposta, procesguir para o termino ou não fazer nada.
Repare nesse “no meio do jogo volto para trás”. Quando o evento vai para o prenester a view corresponde ao listener que captura o evento do botão.
mas quando o presenter usa a view explicitamente, ele o faz através de uma interface e essa interfce é implementada com objetos swing, por exemplo

class PresenterA {

    private ViewA view;

 public   PresenterA (ViewA view){
      this.view = view;
}

    public void doExit(){
 
              if ( view.confirm("Quer mesmo sair?"){

                      // termina aplicação
                        System.exit(0);
               }

    }

}

interface ViewA {

   public boolean confirm(String message);

}

class Tela extends JFrame implements ViewA{

  
      // monta tela e botões e um deles tem o seguinte listener

       public Listener implements ActionListener{
    
                  public void onAction(...){

                             presenter.doExit();
                    }

     }

  @Override
    public boolean confirm(String message){

         // usa JDialog para perguntar ao usuário
   }

}


public class Montadora {

   public void monta(){
      ViewA viewA = new Tela();
      PresenterA presenter = new PresenterA(viewA );

  }

}

Agora imagine que além do botão vc quer que o mesmo aconteça quando aperta o x na tela. vc precisa de um windowlistener para isso.
Vc implementa isso na Tela e chama o doExit() da mesma forma. O presenter não sabe quem ou de onde foi chamado o método e nem interessa.

Repare que a view é a tela , cada tela será uma view, terá um presenter ou mais do que um presenter.
Agora imagine que todas as telas tem um botão de sair, todas elas invocarão o mesmo presenter, mas a view que o presenter vai invocar é diferente ( é uma tela diferente , mas ele não sabe isso,nem importa, porque a interface é a mesma

O MVP não é 1 para 1. Uma view pode chamar vários presenters, cada presenter ser usado por views diferentes. O mesmo para os models e presenters.

O ponto que precisa entender é que não ha correspondencia um para um. Lembre-se que o padrão observer é 1 para muitos, e isso está sempre implicito no MVP.

sergiotaborda:

Não. Essa classe não faz parte dos andares. Essa classe faz parte da aplicação ,mas não dos andares.

O M comunica com andar de dominio. Sim. E o andar cliente de comunica com o andar de apresentação. sim.
Mas vc precisa entender que cada andar contém muitiplas comunicações. Por exemplo o andar de apresentação contem diversos presenters , e por consequencia está lidado a difernetes modelos e views. A view é um objeto complexo e não ha um objeto unico que chame o presenter.

Então poderia dizer que…

1. …a classe Montadora pertence a Camada de Aplicação ( camada mesmo ) e
2. a classe Tela pertence ao andar Cliente e
3. ViewA é uma das ‘n’ Visões do andar Apresentação e
4. PresenterA é um dos Presenters do Andar Apresentação.

É correto dizer isso? :mrgreen:

Se ainda estiver entendendo algo errado, por favor me avise…
Obrigada Sergio Desculpa ficar atrapalhando… Até mais moço…

Não. Ele não precisa. Nós fazemos isso porque estamos usando MVP na apresentação, mas a camada de cima não precisa implementar coisas da camada de baixo.

A função desse andar é cuidar da experiência do usuário, da ergonomia, facilidade de uso, respondabilidade e de certa forma a “imagem” do produto.
Ele é composto de componentes gráficos ( por isso que swing é a ferramenta para ele). Ele deve oferecer a melhor forma de input e output possivel.

Sim.

Oi Sergio, obrigada por continuar a me ajudar

Você entendeu bem a minha pergunta e respondeu ela melhor ainda. Mas ainda preciso saber se entendi corretamente o ‘output’ do andar Cliente.

No andar Cliente, falando de um sistema simples quanto ao de uma Agenda, muito provavelmente teriamos ‘n’ telas/interfaces/objetos que fariam o input neste andar. Seja esse input vindo de um usuário humano ao clicar em um botão ou de um outro nodo ( andar Integração ) querendo se comunicar com este nodo ( andar Cliente ) ou ‘n’ outras possibilidades. Muito bem. Vamos assumir que o Swing é o exemplo mais puro que podemos encontrar de compnentes com uma boa implementação do pattern MVC. Sendo assim, cada componente do Swing é um ( C )ontroller. Ex:

// Andar Cliente, neste momento só tem esta classe que é o input deste andar.
public class Tela extends JFrame {

   public Tela() {
      JPanel painel = new JPanel();
      JButton botao = new JButton("OK");
      botao.setEnable(false);
      painel.add(botao);
      add(painel);
      setVisible(true);
   }
}

// Camada Aplicação
public class TelaOK {
   public static void main(String args[]) {
      Tela t = new Tela();
   }
}

Veja: JFrame, JPanel e JButton são controladores. Até este momento temos um único ‘input’ no sistema que é justamente essa classe Tela recheada de componentes Swing. Perceba que no JButton não existe nenhum Listener adicionado ouvindo os eventos de negócios ( não sei se esse é o nome certo, mas acho que deu para entender ) lançados pelo modelo do botão. A visão muda normalmente ao clicar/soltar o botão, muito provavelmente porque a visão recebe o evento do ‘click’ que é canalizado ao controlador que chama o método responsável no modelo que se altera e lança um evento para a visão via Observer ( não sei se é exatamente isso pois alguns dizem que sim, Swing implementa MVC e outros dizem que não, que Swing implementa outra coisa mas não vem ao caso agora ).

Mas precisamos de um ‘output’ para o andar Cliente certo? Então qual a melhor forma de fazer isso? Horas, vamos começar implementando um Listener nesse JButton que passará agora a escutar os eventos de negócios. Ex:

// Andar Cliente, neste momento só tem esta classe que é o input deste andar.
public class Tela extends JFrame {

   public Tela() {
      JPanel painel = new JPanel();
      JButton botao = new JButton("OK");
      botao.setEnable(false);
      botao.addActionListener(
         new ActionListener {
            public void actionPerformed(ActionEvent e) {
               // PONTO que captura o evento de negócio lançado pelo JButton.
            }
         });
      painel.add(botao);
      add(painel);
      setVisible(true);
   }
}

// Camada Aplicação
public class TelaOK {
   public static void main(String args[]) {
      Tela t = new Tela();
   }
}

Pronto! Temos um dos ‘n pontos’ que a classe Tela poderia conter que é a linha 11 do código acima. Agora, é neste PONTO que surge a pergunta:

1. Nele eu posso continuar no andar Cliente realizando tarefas nele como chamar uma outra Tela (Tela2) ou popular um objeto deste andar?
2. Mas se precisar descer um andar ( ir para o andar de Apresentação ) é nesse ponto que vou fazer isso?
3. É nesse ponto que vou realizar um ‘input’ no andar de Apresentação ou isso cabe a algum objeto especializado somente em conhecer as visões que fazem o ‘input’ do andar abaixo, independentemente desse andar estar com MVP ou não? Até porque se estivesse com MVP aí sim, como reforçou, seria implementado pela classe Tela uma das interfaces com métodos específicos para receberem os ActionListeners dos Presenters.
4. É realidade que todo andar tem que ter input e output, é óbvio. Mas quais outros patterns são conhecidos para se aplicar ao andar Apresentação e existe algum para o Cliente usando Swing?

Porque estou perguntando isso? Para chegar a conclusão da primeira etapa de uma boa estruturação dos Andares Cliente e Apresentação e a forma como eles se comunicam.

E um detalhe que reparei que também preciso definitivamente saber a resposta:
5) No MVC, quem tem a responsabilidade de se comunicar com o andar abaixo é a letra C ( como no exemplo Swing que citei acima ) mas no MVP quem fala com o andar abaixo é a letra M ( como foi explicado naquele famoso gigante tópico de MVP + MVC +… ). Estou certa?

Obrigada

Tópico graande Ingrid, não tenho tempo para ler tudo(tenho uma deadline para terça…), vou deixar que o Sérgio lhe explique os detalhes de implementação.

Sobre esse trecho:

Tenho que discordar. O objetivo de estudar design patterns não é ser um bom programador. é ser um bom designer. E se o design é bom, a programação é trivial. Acontece que muita gente acha que qualquer tipo de design vale. Que se muda depois, KISS essa palermice toda… na realidade não é trivial conseguir um bom design e se a pessoa almeja um dia ser um bom designer, precisa sim aprender patterns.

Concordo em parte, Sérgio.O fundamental de saber design patterns, é saber que cada um tem seus usos(e limitações), e saber aonde aplicar cada um.Se vc realmente sabe a maioria deles, vc acaba sendo mais do que um bom designer, vc se torna um bom arquiteto de software. Design patterns, são, antes de tudo, soluções para problemas recorrentes encontrados em desenvolvimento de software.Vou lhe contar um caso real: num projeto que eu fiz, o cara(novato), só queria saber aonde se colocava o Singleton e o Facade, pouco se lixando para a implementação.Era um sistema prevalente, e o Singleton até servia, mas quando eu vi o código… OMFG! :shock: Era uma classe de 7mil linhas(o que chamo de GOD MODE anti-pattern) que era irrefatorável, tamanho a quantidade de coisa que ela tinha/fazia.Claro, nessa época eu ainda vi coisas, como a tradução de Singleton para Solteirão(!!!) devido a instância única…

++!
Acho mais importante definir formas de trabalhar primeiro, do que se embrenhar pelo mundo dos padrões de projeto.

Destacando novamente isso:

Que se muda depois, KISS essa palermice toda… na realidade não é trivial conseguir um bom design e se a pessoa almeja um dia ser um bom designer, precisa sim aprender patterns.

…apagando algumas mensagens: este tópico é total perda de tempo…

…apagando algumas mensagens: este tópico é total perda de tempo…

Olá…

ceklock:

ingridfarabulini:

Oi Sergio, obrigada por continuar a me ajudar

É uma das três principais partes que constitui uma arquitetura de software: Plataformas, Andares e Qualidades. ( link )
Defina ‘Andares’ como camadas lógicas. Cliente, Apresentação, Domínio, Integração e Recursos. Você deve conhecer isso como camadas, mas para não existir ambiguidade definimos como andares, Ok? Até +…

O que é “Andar” ? Você está projetando um prédio?

Andares é uma das três partes que constitui uma arquitetura de software: Plataformas, Andares e Qualidades. ( link )
Defina ‘Andares’ como camadas lógicas com cuidado: Cliente, Apresentação, Domínio, Integração e Recursos. Você deve conhecer como ‘Camadas’ mas como a palavra é ambigua definimos particularmente como andares. ( Esse detalhe você obtém maiores informações na segunda postagem desse tópico )

Obrigada Continuarei aguardando pela resposta desta postagem. Até +…

…apagando algumas mensagens: este tópico é total perda de tempo…

Sim.

Sim.

Sim

Já lhe tinha dito antes que não ha mais padrões especificos para isso. Apenas boa OO e o uso das API.

Não. todos os listenerns são models do MVC do swing. Mais especificamente o Action é o model de botões e outras coisas “clicáveis” como menus, por exemplo. Ele implementa ActionListener mas ele controla mais coisas, como por exemplo o Enabled. SEMPRE é o model que comunica com o andar de baixo.

Neste momento vc está procurando cabelo em ovo. Já lhe expliquei antes que no listener vc coloca a chamada ao presenter e pronto. Não ha mais truques.

O problema é então com o programador e a pedagogia , não com os padrões ou o fato de que sim, é preciso saber padrões.
Claro que “saber padrões” não é decorar os nomes e implementações exemplo. É realmente saber onde se aplicam e como. Saber implementar o padrão para o caso em mãos e saber quais variantes usar. É como usar um parafuso, o conceito é simples, mas a aplicabilidade se aprende com experiencia.

Como já expliquei antes, andar (do inglês story) é o nome que se dá à camada funcional da aplicação.
é um conceito de arquitetura, e sim é baseado na metáfora do prédio.

O nome Andar é usado para diferenciar de Nodo, Plataforma e Camada (camada é o nome mais abstrato que inclui andar, plataforma. Pesquise pelo padrão Layer). Principalmente para diferenciar camada de código (conjunto de classes , API) de camada de funcionalidade (que é o andar, que é uma orquestração de camadas de codigo)

Concordo plenamente. Usar padrões em excesso é extremamente prejudicial. Se não forem usados de maneira correta, o que vai acontecer é que ao invés de simplificar as coisas, você vai complicar.

sergiotaborda:

O nome Andar é usado para diferenciar de Nodo, Plataforma e Camada (camada é o nome mais abstrato que inclui andar, plataforma. Pesquise pelo padrão Layer). Principalmente para diferenciar camada de código (conjunto de classes , API) de camada de funcionalidade (que é o andar, que é uma orquestração de camadas de codigo)

Provavelmente o padrão layer é pouquíssimo usado em projetos comuns. Eu tenho um livro de padrões de projeto e este padrão não é citado (o livro só cita os padrões mais populares).

Acho que o que vocês precisam é do MVC (Model, View, Controller) ou do Modelo em Três Camadas (Apresentação, Negócio, Dados). Querer usar patterns exóticos é pedir pra complicar tudo ao invés de simplificar. Padrões de projeto só fazem sentido se vão simplificar o projeto.

Concordo plenamente. Usar padrões em excesso é extremamente prejudicial. Se não forem usados de maneira correta, o que vai acontecer é que ao invés de simplificar as coisas, você vai complicar.

Não existe tal coisa como usar padrões em excesso. Se vc usa é porque vc precisa. Toda a API java é feita usando padrões e não foram demais (aliás foram de menos).

Não podemos julgar o uso ou não de padrões por aquilo que os iniciantes ou os inconpetentes fazem. Se o cara insiste em colocar aquilo que ele chama de “singleton” no projeto quando na realidade aquilo é apenas uma variável global, que culpa tem padrão singleton do uso incorreto? Que culpa têm os livros e que culpa têm os defensores do uso de padrões ? Nenhuma, excepto não terem explicado melhor. Mas mesmo quando bem explicado existe muita gente que não entende.

Quando eu comecei a programar java eu usava principios como SoC, encapsulamento, restrição de visibilidade, e outros… eu chegava no mesmo tipo de objeto que os padrões chegam, mas levava mais tempo. quando comecei a estudar padrões ganhei muito tempo. Hoje eu não penso em SoC e restrição de visibilidade quando quero fazer um esquema produtor-consumir, eu penso no padrão.

Padrões são feito para serem uma linguagem, uma melhora da comunicação. Ninguem é culpado se as pessoas não aprendem direito ( poderiamos dizer o mesmo da matemática ou da uml).

Ou vc usa um padrão ou vc não usa. Não tem essa de usar errado. Se está errado, e aquele padrão não se aplica alí, então isso não é usar o padrão. Usar um alicate para martelar não é usar um alicate.

Padrões devem ser aprendidos. Não é simples e não é rápido e nem todos têm capacidade para os entender, mas é uma necessidade em POO tal como saber matemática… (ups!..pensando bem tem muita gente que tb não sabe matemática…)

ceklock:

sergiotaborda:

O nome Andar é usado para diferenciar de Nodo, Plataforma e Camada (camada é o nome mais abstrato que inclui andar, plataforma. Pesquise pelo padrão Layer). Principalmente para diferenciar camada de código (conjunto de classes , API) de camada de funcionalidade (que é o andar, que é uma orquestração de camadas de codigo)

Provavelmente o padrão layer é pouquíssimo usado em projetos comuns. Eu tenho um livro de padrões de projeto e este padrão não é citado (o livro só cita os padrões mais populares).

hummm… obviamente vc não sabe do que está falando. Provavelmente seu livro só fala dos padrões GoF ou dos padrões JEE. Existem muitos mais e muitos bastante uteis como Money e Ratio que vc não encontra nesses livros.

O “Modelo em Três Camadas” que citou é baseado no padrão Layer (three layers model)

Primeiro vc tem que conhecer os padrões que existem para depois estabelecer o que é exótico. Padrões de projeto sempre fazem sentido quando se aplicam. Não ha qualquer proveito em vc identificar o uso de um padrão e resolver não o usar.

Listeners são Models? Sinto muito, mas isso está errado! Todos os Listeners no MVC fazem parte da camada de Controle. Portanto o que ela falou está correto. A camada de controle © é a responsável por se comunicar com outras camadas.

M = Modelo (dados) - Exemplo no Swing: JTable tem um TableModel, que é responsável por gerenciar os dados da tabela. http://java.sun.com/javase/6/docs/api/javax/swing/JTable.html#getModel()

V = View (visualização, interface gráfica) - Exemplo no Swing: a interface gráfica da JTable.

C = Control (controle) - Camada que é responsável por verificar o Model e atualizar a View. Esta camada implementa o necessário para verificar se houveram mudanças nos dados e notificar a View para fazer alterações na visualização. Para isso são usados Listeners (eventos).

sergiotaborda:

ceklock:

sergiotaborda:

O nome Andar é usado para diferenciar de Nodo, Plataforma e Camada (camada é o nome mais abstrato que inclui andar, plataforma. Pesquise pelo padrão Layer). Principalmente para diferenciar camada de código (conjunto de classes , API) de camada de funcionalidade (que é o andar, que é uma orquestração de camadas de codigo)

Provavelmente o padrão layer é pouquíssimo usado em projetos comuns. Eu tenho um livro de padrões de projeto e este padrão não é citado (o livro só cita os padrões mais populares).

hummm… obviamente vc não sabe do que está falando. Provavelmente seu livro só fala dos padrões GoF ou dos padrões JEE. Existem muitos mais e muitos bastante uteis como Money e Ratio que vc não encontra nesses livros.

O “Modelo em Três Camadas” que citou é baseado no padrão Layer (three layers model)

Primeiro vc tem que conhecer os padrões que existem para depois estabelecer o que é exótico. Padrões de projeto sempre fazem sentido quando se aplicam. Não ha qualquer proveito em vc identificar o uso de um padrão e resolver não o usar.

Concordo 100% com o que foi falado nesse artigo:

http://parand.com/say/index.php/2005/07/18/i-hate-patterns/

Eu gosto de Design Patters. Mas quando alguém fica querendo aplicar Patterns em tudo, até aonde não precisa, isso é ruim. Aumenta a complexidade do código.

Vou citar um trecho do artigo:

Let me give you an example. Here?s the real world:

A senior developer, with 2 developers reporting to him, designed and implemented a subsystem. The need arose for what seemed to be a minor modification, and the developer responded with an estimate of two weeks. We were puzzled ? the change had every appearance of being simple. I?d have thought less than a day.

So we dug into the implementation. The developer presented the design of the subsystem. He had used EJBs along with the (name withheld to protect the innocent) pattern. The design hung together fairly well. But there was one glaring problem:

The entire subsystem could?ve been implemented with a fraction of the complexity by using a simple servlet connecting to JDBC. If you wanted to be fancy you could?ve used some abstraction of the database. That?s it. Really quite simple.

We gently pressed the developer on his design choices and why he seemingly favored the complex over the simple in almost every instance. He responded with the usual list of suspects: transactions, scalability, maintainability, ease of understanding.

Good list. Here?s the problem: we didn?t need transactions. Scalability doesn?t hold up: look at the highest scaling systems and you?ll see they?re not EJBs. In any case, servlets would?ve scaled just fine for our purposes. Maintainability and ease of understanding are easy to gauge: it?s easier to understand and maintain less lines of code. Less lines of code good, more lines bad.

Then we looked at the actual code. Good Lord. Copy and paste of major pieces into a several files. Justification? Horrible misuse of the poor, innocent factory pattern. Lines of code? Many. Many. Innocent patterns slaughtered everywhere.

We actually spent quite a bit of time with the developer, attempting to reform him. He was a good, smart guy, worth saving. Unfortunately we were unsuccessful, primarily because he sincerely believed he was right ? he was using EJBs and patterns. How could the simple, lowly servlet be a better path?

At the end one of our other developers rewrote the entire subsystem in his spare time in far less than two weeks. Lines of code? Something like 1/5th to 1/10th of the original. Faster. Understandable. Simple. The original developer moved on to create many many lines of code for some other company.

Existem tantos padrões no mundo que é meio sem sentido chamar alguns de padrões.

Pra mim padrão é o que é mais usado.

Mas como diria alguém que não lembro o nome: “Padrão, cada um tem o seu” :lol:

incrivel que quando chega um cueca e faz alguma pergunta do tipo… se meia duzia responder é muito…
agora com uma menininha gatinha de rostinho angelical pergunta temos 4 paginas so de resposta… interessante não… mas o mais interessante é que dificilmente menininhas bonitinhas se interessam por tecnologia e muito menos por qualquer area de extas e muito menos ainda computação… com algumas exceções como a lina por exemplo… imagino que deve ter muito neguinho aqui fazendo avateres com fotos de menininhas lindinhas para pegar muito otaria no forum… bem não creio que seja o caso da ingrid pois esta fez uma pergunta coerente e não algo como: “porfavor façam meu dever de casa…” dai sim seria meio suspeito…

Concordo plenamente. Usar padrões em excesso é extremamente prejudicial. Se não forem usados de maneira correta, o que vai acontecer é que ao invés de simplificar as coisas, você vai complicar.

Não existe tal coisa como usar padrões em excesso. Se vc usa é porque vc precisa. Toda a API java é feita usando padrões e não foram demais (aliás foram de menos).

Não podemos julgar o uso ou não de padrões por aquilo que os iniciantes ou os inconpetentes fazem. Se o cara insiste em colocar aquilo que ele chama de “singleton” no projeto quando na realidade aquilo é apenas uma variável global, que culpa tem padrão singleton do uso incorreto? Que culpa têm os livros e que culpa têm os defensores do uso de padrões ? Nenhuma, excepto não terem explicado melhor. Mas mesmo quando bem explicado existe muita gente que não entende.

Quando eu comecei a programar java eu usava principios como SoC, encapsulamento, restrição de visibilidade, e outros… eu chegava no mesmo tipo de objeto que os padrões chegam, mas levava mais tempo. quando comecei a estudar padrões ganhei muito tempo. Hoje eu não penso em SoC e restrição de visibilidade quando quero fazer um esquema produtor-consumir, eu penso no padrão.

Padrões são feito para serem uma linguagem, uma melhora da comunicação. Ninguem é culpado se as pessoas não aprendem direito ( poderiamos dizer o mesmo da matemática ou da uml).

Ou vc usa um padrão ou vc não usa. Não tem essa de usar errado. Se está errado, e aquele padrão não se aplica alí, então isso não é usar o padrão. Usar um alicate para martelar não é usar um alicate.

Padrões devem ser aprendidos. Não é simples e não é rápido e nem todos têm capacidade para os entender, mas é uma necessidade em POO tal como saber matemática… (ups!..pensando bem tem muita gente que tb não sabe matemática…)

Concordo com o sergio… não se pode culpar os padrões pelas mas utilizações dos mesmos… eles foram feitos para serem usados para solucionar problemas… se alguem usa-os de forma incorreta gerando problemas invez de soluções a culpa não é do padrão e sim de que o utilizou de forma inadequada…

luistiagos:

Concordo com o sergio… não se pode culpar os padrões pelas mas utilizações dos mesmos… eles foram feitos para serem usados para solucionar problemas… se alguem usa-os de forma incorreta gerando problemas invez de soluções a culpa não é do padrão e sim de que o utilizou de forma inadequada…

Mas isso é óbvio… :roll:

Olá meninos

Primeiro quero agradecer o interesse de vocês em tentar me ajudar. Fico muito feliz Obrigada Sergio em responder minhas dúvidas.
Segundo peço desculpas se minhas perguntas causaram um certo ‘desconforto’ gerando discussão entre os usuários que estão colaborando

Mas no geral estou muito feliz pela ajuda e atenção que estão tendo ao tópico tentando sempre ajudar
Ainda tenho algumas dúvidas que postarei logo após a próxima postagem…

Obrigada

Olá luistiagos… tudo bem com você moço?

luistiagos:

incrivel que quando chega um cueca e faz alguma pergunta do tipo… se meia duzia responder é muito…
agora com uma menininha gatinha de rostinho angelical pergunta temos 4 paginas so de resposta… interessante não… mas o mais interessante é que dificilmente menininhas bonitinhas se interessam por tecnologia e muito menos por qualquer area de extas e muito menos ainda computação… com algumas exceções como a lina por exemplo… imagino que deve ter muito neguinho aqui fazendo avateres com fotos de menininhas lindinhas para pegar muito otaria no forum… bem não creio que seja o caso da ingrid pois esta fez uma pergunta coerente e não algo como: “porfavor façam meu dever de casa…” dai sim seria meio suspeito…

Luis, posso causar uma admiração a você neste momento, mas concordo com a sua forma de enxergar e entender o que falou na citação acima… mas não concordo com você como pessoa.
Eu lí muitas das suas postagens no fórum sempre com a intensão de ajudar o próximo e por aí concluí que como pessoa você é muito mais do que isso que falou na citação acima.

Como mulher, posso dizer que se analizarmos a sociedade atual na qual vivemos sou obrigada a concordar com você quando diz que as mulheres tem preferência sobre os homens na visão masculina. ( Ahh, obrigada pelo elogio da foto, fico feliz em me enxergar assim como citou. :oops: A maioria dos amigos/colegas quando me vêem pela primeira vez me acham ‘orgulhosa/patricinha’ )

Mais uma vez, como mulher, posso te afirmar com toda clara certeza deste mundo que Deus construiu para nossa existência que ‘menininhas bonitinhas’ se interessam sim por tecnologia e pela área de exatas… e olha que basta fazer uma busca simples para encontrá-las. Basta assistir palestras de tecnologia, ler bibliografias de artigos em revistas especializadas, participar de fóruns na Internet como o GUJ, entrar em uma sala de aula na faculdade/universidade/cursos profissionalizantes ou em qualquer curso de exatas e assuntos relacionados a área de tecnologia logo encontrará uma ‘menininha bonitinha’, na sua forma de enxergar ( igual a Lina, como lembrou ) . Mesmo as mulheres sendo a minoria na área nós somos reais e buscamos coisas que qualquer ser humano busca na área independete do sexo.

Não posso afirmar uma coisa que obviamente pode acontecer a qualquer momento mas não acredito ( e nem gostaria de acreditar ) que em um mundo onde todas as pessoas deveriam ser igualmente respeitadas, independentemente de classe, cor, religião, beleza e sexo seja necessário alguém se submeter a tal constrangimento pessoal e mental para conseguir chamar a atenção das outras pessoas. Por isso muitas vezes imaginei que nasci em um planeta errado… Acho que a maldade está mais nos olhos de quem vê.

Ahh eu sei muito bem disso lindo… hihihihihi… Já pensou amanhã ou depois aparece a foto de um rapaz no meu avatar dizendo: “Valew ae mano!” hihihihihihi… Fico só imaginando a carinha dos colegas.
Mas quero continuar acreditando que ainda existe gente muito boa e da melhor qualidade nesse mundo com lindas almas… mesmo sabendo, assim como você, que o mundo não é assim tão lindo… mas vamos continuar lutando para que ele seja, não? Não seria muito melhor ver mulheres nos programas de TV explicando alguma novidade do mundo Java no lugar de ficarem mostrando os seus lindos corpos siliconados produzidos pelos melhores cirurgiões plásticos existentes?

Ah… mulher fala né? :mrgreen: Desculpe mas me chamou atenção a sua postagem que, volto a dizer, é algo que pode ser uma realidade sim e pode estar acontecendo… quem sabe não?
Acho que para que isso nunca aconteça, seria necessário a administração do fórum providenciar um cadastro real e ao vivo de todos aqueles que quiserem participar apresentando documento e coisas do gênero. Mas acho completamente inviável e uma loucura levar algo ‘tão à risca’ assim… :roll: Legal é o fórum ser público como está hoje onde sempre novas pessoas participam e trocam idéias e conhecimentos sem muitas restrições. O objetivo aqui é ajudar, independentemente da fotinho que aparece no avatar de cada um.

Você mesmo se for no desenho da sua foto no avatar uma realidade física, não acha que sua foto chamaria a atenção das usuárias do fórum? Pense nisso.
Tem coisas que são reais e não existe nenhum outro interesse por trás delas, está entendendo? Com certeza no momento que abriu este tópico você tinha somente a intensão de ajudar/ler/opinar ( ainda não tinha visto minha foto ) mas devido a essa sua má interpretação ( que volto a dizer, é uma realidade a qualquer momento ) sem querer deixou desviar o foco. Mas vou fazer o que, meu Deus! Não seria muita falsidade minha colocar uma foto de outra pessoa que na minha visão ( cada um tem a sua ) aparentemente não agradace os demias usuários só para não causar esse tipo de problema que resolveu expor?

Eu só sai mais em defesa de todas as mulheres que precisam ser mais ‘bem vindas’ em áreas as quais não tinhamos tanto acesso ou sofriamos algum tipo de preconceito.
Talvez você nunca mais abra este tópico e nem leia isso que estou falando, mas fica aí a reflexão… Até + Obrigada

Olá Sergio

Aí puxa vida, é verdade… :roll: me desculpe fazê-lo repetitivo, perdão.

sergiotaborda:

ingridfarabulini:

E um detalhe que reparei que também preciso definitivamente saber a resposta:
5) No MVC, quem tem a responsabilidade de se comunicar com o andar abaixo é a letra C ( como no exemplo Swing que citei acima ) mas no MVP quem fala com o andar abaixo é a letra M ( como foi explicado naquele famoso gigante tópico de MVP + MVC +… ). Estou certa?

Não. todos os listenerns são models do MVC do swing. Mais especificamente o Action é o model de botões e outras coisas “clicáveis” como menus, por exemplo. Ele implementa ActionListener mas ele controla mais coisas, como por exemplo o Enabled. SEMPRE é o model que comunica com o andar de baixo.

Neste momento vc está procurando cabelo em ovo. Já lhe expliquei antes que no listener vc coloca a chamada ao presenter e pronto. Não ha mais truques.

Um detalhe que achei interessante é que nesses dois andares (Cliente e Apresentação) não foi necessário em nenhum momento usar aquelas coisas horríveis de TO/DTO para ligar ambos andares :idea: o que é bom, não? Visto que é uma coisa que não é mais usada para coisas novas, estou certa?

Obrigada Até +…

bobmoe:

ingridfarabulini:

Faz pouquíssimo tempo que estudo Java ‘um ano e meio aprox.’ e sempre escrevi meus programas sem seguir nenhum pattern ou qualquer tipo de arquitetura. Mas de uns meses para cá estou interessada em seguir alguns padrões mínimos para um bom desenvolvimento ‘ou pelo menos que facilite a vida de qualquer programador(a) quando necessário realizar alguma manutenção neste código’. Pensando nisso iniciei meus estudos com o pattern Layers, ou camadas lógicas, como preferir.

quem aprende design patterns só estudando, se torna péssimo programador; o q complica coisas simples. durante sua experiencia naturalmente vai reconhecer a necessidade.
não precisa ir atrás de design patterns, eles vem até vc

editado:
lógico, estou dizendo isso partindo do principio q vc é inciante.

Concordo com o bobmoe.

Vantagens e desvantagens do padrão Layers:

Advantages

• Reuse of Layers
• Support for standardization - dependencies are kept local
• Exchangeability

Disadvantages

• Cascades of changing behavior when behavior of a layer changes … e.g. lower layer output increase 100x
• Lower efficiency
• Unnecessary work
• Difficulty of establishing the correct granularity of layers

Quero só ver esse código…

ceklock:

ingridfarabulini:

Nossa mas que legal… vou aplicar essas explicações todas na Agenda para mostrar o código aqui

Quero só ver esse código…

Olá ceklock, tudo bem?

Percebi que você também é iniciante ( assim com eu ) em Java pelas suas postagens anteriores então vai minha dica: não se apegue muito aos códigos. Até entendo quando diz que aprender padrões e mais padrões vai ser prejudicial… mas ficar tentando entender códigos e mais códigos você acabaria caindo naquela frase mesmo que falou “padrão, cada um tem o seu”. No lugar de inovar com os padrões já existentes, você passaria a maior parte do seu tempo aprendendo os padrões de bilhões de pessoas mundo afora, fugindo da sua habilidade de inovar com coisas já existentes. Ok moço? Eu comecei a me interessar por padrões exatamente para não causar mais sustos nas pessoas quando olhavam para o meu código e se assustavam sem entender absolutamente nada com classes super extensas e outros problemas.

Espero que continue sim sempre que puder participando do tópico e mandando suas postagens Até + …

Bem, chegando atrasado, mas vou dar a minha contribuição aqui:

Todos os padrões de projeto (inclusive o MVC) tem a característica de criar soluções reutilizáveis para problemas recorrentes. Mantenha isso sempre em mente.

É importante também aprender princípios de orientação a objetos, que são a base para todos (ou quase todos) os padrões em POO: Encapsulamento, polimorfismo, alta coesão e baixo acoplamento. “Law of Demeter” também é uma importante consequência disso. Um projeto bem feito de verdade deve seguir estes princípios, e os padrões de projeto acabam surgindo mais ou menos como consequência deles.

Só venho relemebrar neste ponto de que muita gente diz que encapsulamento se resume a colocar getters e setters para os atributos. Isso não é encapsumento de verdade. Encapsulamento de verdade é fazer um objeto ser responsável pelo gerenciamento do seu estado interno. E quanto aos padrões de projeto, cada um deles se aplica em uma determinada situação. Aplicar um padrão de projeto em um lugar aonde ele não se aplica ou não deveria ser aplicado acaba criando gambiarras e por isso é importante entender não apenas como aplicá-los, mas também aonde e quando aplicá-los.

No mais, além de aprender padrões de projeto (soluções reutilizáveis que funcionam para problemas recorrentes), também é importante entender os anti-padrões (soluções ruins frequentemente utilizadas que não funcionam direito). Uma ótima referência (embora humorística) é essa: http://desciclo.pedia.ws/wiki/Gambi_Design_Patterns. Afinal, além de saber o que fazer, é preciso saber o que não fazer.

ingridfarabulini:

não se apegue muito aos códigos. Até entendo quando diz que aprender padrões e mais padrões vai ser prejudicial… mas ficar tentando entender códigos e mais códigos você acabaria caindo naquela frase mesmo que falou “padrão, cada um tem o seu”.

Pra mim não faz sentido o que você falou.

victorwss:

Todos os padrões de projeto (inclusive o MVC) tem a característica de criar soluções reutilizáveis para problemas recorrentes. Mantenha isso sempre em mente.

É importante também aprender princípios de orientação a objetos, que são a base para todos (ou quase todos) os padrões em POO: Encapsulamento, polimorfismo, alta coesão e baixo acoplamento. “Law of Demeter” também é uma importante consequência disso. Um projeto bem feito de verdade deve seguir estes princípios, e os padrões de projeto acabam surgindo mais ou menos como consequência deles.

(…)E quanto aos padrões de projeto, cada um deles se aplica em uma determinada situação. Aplicar um padrão de projeto em um lugar aonde ele não se aplica ou não deveria ser aplicado acaba criando gambiarras e por isso é importante entender não apenas como aplicá-los, mas também aonde e quando aplicá-los.

victorwss, sábias palavras. Concordo 100%.

Olá… já escrevi o código daquilo que entendi até o momento.

:arrow: CAMADA APLICAÇÃO

// Esta classe principal está na Camada de Aplicação.

    public class AgendaIngrid {
     
       public static void main(String args[]) { 
       
         AgendaConfig conf = new AgendaConfig();
         conf.config();
         AgendaPresenter presenter = conf.getPresenter();
         presenter.start(); 
      } 
   }

// Esta classe de configuração está na Camada de Aplicação.

    public class AgendaConfig { 
    
      private AgendaPresenter presenter; 
       
       public void config() { 
         AgendaViewA view = new AgendaViewC();
         AgendaModeloA model = new AgendaModelo();
         this.presenter = new AgendaPresenter(model, view);
      }
   	
       public AgendaPresenter getPresenter() {
         return this.presenter;
      }
   }

:arrow: CAMADA FUNCIONAL: ANDAR CLIENTE

// Esta classe é um dos 'n' inputs do Andar Cliente e é uma das 'n' possíveis telas que serão exibidas ao usuário. 
// Também é um dos 'n' outputs deste andar e fará input em um dos 'n' inputs no andar Apresentação.

   import javax.swing.*; 
   import java.awt.event.*;
	 
    public class AgendaViewC extends JFrame implements AgendaViewA {
      private AgendaPresenter ap;
   	
      private JTextField nome, eMail, telefone; 
      private JButton bCadastrar; 
   
       public AgendaViewC() { 
         JPanel p = new JPanel(); 
         p.add(new JLabel("Nome:")); 
         p.add(nome = new JTextField(10)); 
         p.add(new JLabel(" - Telefone:")); 
         p.add(telefone = new JTextField(10)); 
         p.add(new JLabel(" - E-Mail:")); 
         p.add(eMail = new JTextField(10)); 
         p.add(bCadastrar = new JButton("Cadastrar Pessoa >>")); 
         bCadastrar.addActionListener(
                new ActionListener() { 
                   public void actionPerformed(ActionEvent ae) {
                     ap.cadastrarAgenda();
                  }
               });
         add(p); 
         setTitle("Agenda Ingrid vs1.1"); 
         setSize(720,70); 
         setResizable(false); 
         setDefaultCloseOperation(EXIT_ON_CLOSE); 
      } 
   	
       public void setPessoa(Pessoa p) { 
         this.nome.setText(p.getNome()); 
         this.telefone.setText(p.getTelefone()); 
         this.eMail.setText(p.getEMail()); 
      } 
   	
       public Pessoa getPessoa() { 
         Pessoa p = new Pessoa(); 
         p.setNome(this.nome.getText()); 
         p.setTelefone(this.telefone.getText()); 
         p.setEMail(this.eMail.getText()); 
         return p; 
      } 
   	
       public void exibir() {
         this.setVisible(true);
      }   	 
   	
       public void setPresenter(AgendaPresenter ap) {
         this.ap = ap;
      }
   }

:arrow: CAMADA FUNCIONAL: ANDAR APRESENTAÇÃO

// Esta interface é um dos 'n' inputs do Andar Apresentação. 
// E neste caso especifico é uma das 'n' views ( V do MVP ) que estão presentes neste mesmo andar.

    interface AgendaViewA { 
       public void exibir();
       public Pessoa getPessoa();
       public void setPessoa(Pessoa p);
		 public void setPresenter(AgendaPresenter ap);
   }

// Esta classe é um dos 'n' presenters  ( P do MVP ) que estão presentes no Andar Apresentação.

    public class AgendaPresenter { 
   
      private AgendaModeloA m; 
      private AgendaViewA v; 
   
       public AgendaPresenter(AgendaModeloA model, AgendaViewA view) { 
         this.m = model; 
         this.v = view; 
      
         m.addModeloListener( 
                new AgendaModeloListener() { 
                   public void onAtualizar(AgendaModeloEvent me) { 
                     v.setPessoa(me.getPessoa()); 
                  } 
               });
      }
      
       public void cadastrarAgenda() {
         m.cadastrar(v.getPessoa()); 
      }
   	 
       public void start(){
		   v.setPresenter(this); 
         v.exibir(); 
      }
   }

// Esta interface é um dos 'n' outputs do Andar Apresentação. 
// E neste caso especifico é um dos 'n' models ( M do MVP ) que estão presentes neste mesmo andar.

    interface AgendaModeloA {
       public void cadastrar(Pessoa p);
       public void addModeloListener(AgendaModeloListener l);
   }

// Esta classe é uma implementação de uma das 'n' interfaces do M do MVP ( Neste caso específico, de AgendaModeloA ).
// Também é um dos 'n' outputs deste andar e fará input em um dos 'n' inputs no andar Domínio.

   import java.util.*;
   import java.util.concurrent.*;
   
    public class AgendaModelo implements AgendaModeloA {
    
      private Pessoa p;
   	    
      private final Set<AgendaModeloListener> modeloListeners = new CopyOnWriteArraySet<AgendaModeloListener>(); 
   
       public void cadastrar(Pessoa p) {
         this.p = p;
      	// Acessa a camada inferior de domínio...
         this.fireOnAtualizar();
      }
   	
       public void addModeloListener(AgendaModeloListener ml) {
         this.modeloListeners.add(ml);
      }
   	
       public void removeModeloListener(AgendaModeloListener ml) {
         this.modeloListeners.remove(ml);
      }
   	
       private void fireOnAtualizar() {
         AgendaModeloEvent evento = new AgendaModeloEvent(p);
      
         for (AgendaModeloListener ml : modeloListeners) {
            ml.onAtualizar(evento);
         }
      }
   }

public interface AgendaModeloListener {
       void onAtualizar(AgendaModeloEvent e);
   }

public class AgendaModeloEvent {
    
      private Pessoa p;
   	 
       public AgendaModeloEvent(Pessoa p) {
         this.p = p;
      }
   	
       public Pessoa getPessoa(){
         return this.p;
      }
   }

public class Pessoa {
    
      private String nome, eMail, telefone;
   
       public Pessoa() {
         this.nome="N/C";
         this.eMail="N/C";
         this.telefone="N/C";
      }
   	
       public void setNome(String nome) {
         this.nome = nome;
      }
   		
       public String getNome() {
         return this.nome;
      }
   	
       public void setEMail(String eMail) {
         this.eMail = eMail;
      }
   	
       public String getEMail() {
         return this.eMail;
      }
   	
       public void setTelefone(String telefone) {
         this.telefone = telefone;
      }
   	
       public String getTelefone() {
         return this.telefone;
      }
   }

Vejam, eu tenho uma dúvida recorrente. Sei que algumas das pessoas que estão ajudando vão ficar muito nervosas com a minha pergunta mas preciso fazê-la:

O certo seria as ‘n’ classes do andar Cliente conhecer as classes de visão do andar Apresentação e não os seus presenters diferentemente de como está escrito no código acima?
Como exemplo, só reparar na classe AgendaViewC. Ela está trabalhando com o presenter da Apresentação. Isso é completamente errado não? :? Estou ficando maluca !!
O correto será a interface AgendaViewA ser implementada no andar Apresentação e aí sim o andar Cliente fará chamadas aos métodos desse objeto implementado lá na Apresentação certo?
Porque aí Cliente estaria falando com a visão do andar inferior e não com o miolo dele ( o presenter ). Tem que falar com o V, não com o P, no caso de uma implementação de MVP ocorrer dentro do andar Apresentação. Certa eu?

Estou tendo muita dificuldade em entender isso: as camadas devem ser isoladas não? É errado um andar superior implementar uma interface da camada inferior a não ser uma visão deste inferior?

Aí me desculpem muitooo pelo desconforto das minhas perguntas… eu sou muito leiga em arquitetura. Tenham paciência comigo, não desistam…
Obrigada, ficarei aguardando… Até mais.

…apagando algumas mensagens: este tópico é total perda de tempo…

…apagando algumas mensagens: este tópico é total perda de tempo…

…apagando algumas mensagens: este tópico é total perda de tempo…

…apagando algumas mensagens: este tópico é total perda de tempo…

…apagando algumas mensagens: este tópico é total perda de tempo…

ceklock:

ingridfarabulini:

Percebi que você também é iniciante ( assim com eu ) em Java pelas suas postagens anteriores

Iniciante em java? hahahhahahahahha!!! Sou experiente o suficiente se você quer saber.

Realmente me desculpa, expressei mal minha visão de forma errada, estou errada.
Não se preocupe em postar código, não perca o seu tempo com isso.
Obrigada por ajudar Até…

…apagando algumas mensagens: este tópico é total perda de tempo…

Ingrid , o seu código está mais que certo, para o propósito que o fez. Não mude nada, está bom assim.

Quanto aos TO/DTO vc usou sim. A classe pessoa é um TO (Transfer Object).

Errado. O que vc fez está correto é assim mesmo.
Imagine que vc implementava a interface AgendaViewA no andar de apresentação. Como vc teria acesso aos comandos do usuário ?
Sem linkar com a camada de cliente vc nunca teria acesso as esses comandos, mas sem eles, a apresentação é inutil.
Vc precisa linkar a interface da camada com o cliente.

Acho que o problema aqui é o seguinte, vc está pensando que a camada de baixo não pode invocar a camada de cima e por isso, implementar interfaces da camada de baixo na de cima seria algum tipo de violação, mas não é isso. O que está acontecendo aqui é que a interface AgendaViewA atual como um callback. A camada apresentação chama essa interface. E ela continua não sabendo que essas chamadas vão parar no cliente e é isso que é importante. A camada de apresentação não sabe quem implementa a interface e não lhe importa, é por isso que a interface pode ser implementada por outra camada (alias, essa é condição sin qua non para ter um bom desacoplamento).

Sim, mas o que singnifca isolar ? Esse é o ponto aqui. Vc acha que isolar é implementar em camadas diferentes, mas isso não é isolar. Isolar é que nenhuma das camadas sabe que realmente está falando com a outra.
“sabe” significa “depende de classes ou importação de classes da outra camada” ( interfaces pode, classes não). Ou seja, logicamente existe um corte limpo sobre o que é de quem, mas fisicamente, em algum ponto uma classe ou um cojunto delas é simultaneamente das duas camadas. Essas classes formam a “supreficie de contato”. Elas são agentes na fronteira. e na fronteira elas tem que saber que existem os dois lados. O ponto é que : apenas elas conhecem os dois lados. E isso é que é isolar. Se todas as classes de cada camada sabem que existem os dois lados, temos um problema.

Não ha como não ter classes na fronteira. O truque é as ter ( alto isolamento) e terem pouca responsabilidade (baixo acoplamento).
O problema aqui não é sobre patterns ou java. É sobre OO e o conceito de isolamento de camadas vs implementação de codigo.

Pense assim, o interreptor insola vc da rede eletrica, mas permite que vc controle se a luz está acesa ou não. Mas quando vc toca com o dedo no interruptor fisicamente falando vc está entrando em contacto fisico com o circuito eletrico. Então o interruptor a isola logicamente , mas na implementação não como o interruptor não contactar ao mesmo tempo o circuito electrico e o seu dedo.

sergiotaborda:

Não ha como não ter classes na fronteira. O truque é as ter ( alto isolamento) e terem pouca responsabilidade (baixo acoplamento).
O problema aqui não é sobre patterns ou java. É sobre OO e o conceito de isolamento de camadas vs implementação de codigo.

Vocês podem isolar as classes por pacotes. As classes de um pacote que não devem ser vistas por outros pacotes não podem ser públicas. Um façade serviria para expor o que é útil para ser utilizado em outros pacotes.

sergiotaborda:

Pense assim, o interreptor insola vc da rede eletrica, mas permite que vc controle se a luz está acesa ou não. Mas quando vc toca com o dedo no interruptor fisicamente falando vc está entrando em contacto fisico com o circuito eletrico. Então o interruptor a isola logicamente , mas na implementação não como o interruptor não contactar ao mesmo tempo o circuito electrico e o seu dedo.

Este conceito se chama Black Box (pelo menos acho que é isso que você estava querendo dizer):

bem vc resumiu o que eu quiz passar em minha ultima postgem em poucas palavras…

ceklock:

sergiotaborda:

Não ha como não ter classes na fronteira. O truque é as ter ( alto isolamento) e terem pouca responsabilidade (baixo acoplamento).
O problema aqui não é sobre patterns ou java. É sobre OO e o conceito de isolamento de camadas vs implementação de codigo.

Vocês podem isolar as classes por pacotes. As classes de um pacote que não devem ser vistas por outros pacotes não podem ser públicas. Um façade serviria para expor o que é útil para ser utilizado em outros pacotes.

Olá…
Lá no meu código tenho duas camadas ( andares ): Cliente e Apresentação.
Como você faria para isolar essas camadas em pacotes? Onde aplicaria os Façades?

Até +…

ceklock:

sergiotaborda:

Pense assim, o interreptor insola vc da rede eletrica, mas permite que vc controle se a luz está acesa ou não. Mas quando vc toca com o dedo no interruptor fisicamente falando vc está entrando em contacto fisico com o circuito eletrico. Então o interruptor a isola logicamente , mas na implementação não como o interruptor não contactar ao mesmo tempo o circuito electrico e o seu dedo.

Este conceito se chama Black Box (pelo menos acho que é isso que você estava querendo dizer):

Já lí sobre isso mas em Engenharia de Software na área de testes de software. Caixa Preta é para testar se não há códigos sem uso no algoritmo e testar fluxos, algo do gênero.
Acho que aqui houve sim um erro de interpretação em relação ao que o Sergio falou… enfim… Até mais!

voltando ao assunto… isolar significa que a camada n não conhece a camada n-1 a unica ligação entre elas e que a camada n requisita um serviço para a camada n-1. Lembrando que este serviço pode ser retornar um bean por exemplo… a camada n não conhece a camada n-1 apenas sabe que esta tem o serviço a lhe oferecer… mas não sabe como este serviço e implemetado… ou seja so lhe prove uma interface para o serviço utilizado… se usar uma facade por exemplo ambas camadas n e n-1 não conheceram nem a interface e serviço entre elas apenas conheceram o facade e o facade conhecera as interfaces de cmunicação entre elas…

por exemplo se tivermos um sistema de 2 camadas por exemplo…
onde teremos uma camada para a visão e outra para a persistencia

como exemplo temos 3 classes: PessoaView, PessoaCore e Facade
e temos o metodo salvar o nosso amigo PessoaView recebe uma requisição de um usuario para salvar um objeto pessoa, ao receber esta requisição como o pobre coitado do PessoaView não sabe salvar o objeto ele chama o Facade e pede para ele salvar o objeto pessoa… o Facade não sabe fazer isto mas conhece quem sabe o PessoaCore, este pede para o PessoaCore salvar o objeto e o PessoaCore o salva no banco…
mais tarde o SEO não quer mais que as pessoas sejam salvas no banco apartir de agora as pessoas serao salvas em xmls… e este ordena que altere as 500 telas do sisteminha que usam o objeto pessoa e faça isto para ontem… o unico trabalho que teremos e alterar o metodo salvar de nosso PessoaCore para ao invez de salvar no banco salvar em arquivos xml… não vamos precisar alterar nada referente a nossa camada de visao pois esta desconhece mesmo a existencia do PessoaCore…

O mesmo se aplica a visão… se mais tarde o CEO quiser que o sistema seja em desktop, em web ou mesmo em console :shock:
não teremos problema com o backend… apenas com o front…

para devemos ser bem organizado nos pacotes e com nomeclaturas… por exemplo:

com.meusistema.pessoa.view
PessoaView.java
com.meusistema.facade
Facade.java
com.meusistema.pessoa.core
PessoaCore.java

Particularmente gosto de utilizar 3 camadas nos sistemas que desenvolvo, Web (Apresentação), Negócio e DAO (Ou integração, ou como queiram).

Até hoje não tive a necessidade de utilizar mais que isso pois desenvolvemos aqui na empresa sistemas com uma finalidade específica então varia pouca coisa entre os projetos, mas é sempre bom estar antenado nessas discussões enriquecedoras que rolam aqui no GUJ.

Eu acho que todos que participam dessas discussões, até mesmo os que atuam apenas como leitores, devem ser parabenizados pois isso demonstra busca de conhecimento. Eu fico pasmo com a quantidade de “analistas” e “programadores” que tem no mercado que não estudam porra nenhuma, quando precisam de alguma coisa dão uma googlada e colam o primeiro código que vêem pela frente no projeto que estão atuando.

Olá Sergio

Sim entendi a explicação. Realmente você ‘captou’ bem aquilo que tentei perguntar. Minha dúvida era mesmo se a implementação de uma interface da camada inferior poderia ser realizada na camada superior. E entendi o porque do uso de interfaces. Obrigada pelo elogio do código… :oops:

Algumas perguntas básicas:

1. Como a visão do andar Cliente ( AgendaViewC ) possui um AgendaPresenter que não é uma interface e sim uma classe… seria interessante AgendaPresenter ser uma interface?
2. TO pertence a qual camada ou andar já que ele está sendo utilizado por dois andares, até este momento? ( Cliente e Apresentação )
3. O andar Apresentação não deve conhecer nada do Swing ( import’s ou componentes ) porque se um dia eu mudar a visão no andar Cliente ( Ex: trocar do Swing para o JFace ou do Swing para o SWT :lol: hihihi… fanfarrona ) eu não vou precisar mudar nada no andar de Apresentação, como está no código que fiz aqui.
4. Neste mesmo link acima, perceba que AgendaViewC tem uma dependencia de AgendaPresenter e este se auto-repassa ( this, linha 25 ) para a AgendaViewC através do método para que este possa usá-lo. É certo isso ou correto seria fazer isso no AgendaConfig?

Algumas perguntas ‘procurando cabelo em ovo’:
4) Um andar possui outros andares dentro dele? ( Ex: Andar Cliente tem outros três, quatro ou ‘n’ andares? ou ‘DAO pertence ao andar Integração do andar Domínio?’)
5) Na verdade, o MVP é formado por ‘interface de visão + interface do presenter + interface do modelo’ mas no Andar de Apresentação ( que é onde as três interfaces devem estar ) só serão implementados o ‘P’ e o ‘M’, visto que o ‘V’ quem implementará será sempre o andar Cliente? Ou estou enganada? Como já foi dito o andar de cima não é obrigado a implementar nada do andar de baixo mas se isso não acontecer, também como já foi dito, a apresentação seria inútil. Ou seja, podemos definir o MVP como:
‘V’ está implementado no andar Cliente.
‘P’ e ‘M’ estão implementados no andar Apresentação.
Ahh e isso que é chamado de callback? Entendi direito?

Obrigada Sergio… muito obrigada pela paciência e pelo respeito que trata as minhas perguntas e a mim mesma, é simplesmente lindo e admirável…
Espero que suas respostas sejam sempre respeitadas igualmente pelos colegas. :-o
Vou aguardar, até + moço…

Olá Luis…

luistiagos:

voltando ao assunto… isolar significa que a camada n não conhece a camada n-1 a unica ligação entre elas e que a camada n requisita um serviço para a camada n-1. Lembrando que este serviço pode ser retornar um bean por exemplo… a camada n não conhece a camada n-1 apenas sabe que esta tem o serviço a lhe oferecer… mas não sabe como este serviço e implemetado… ou seja so lhe prove uma interface para o serviço utilizado… se usar uma facade por exemplo ambas camadas n e n-1 não conheceram nem a interface e serviço entre elas apenas conheceram o facade e o facade conhecera as interfaces de cmunicação entre elas…

por exemplo se tivermos um sistema de 2 camadas por exemplo…
onde teremos uma camada para a visão e outra para a persistencia

como exemplo temos 3 classes: PessoaView, PessoaCore e Facade
e temos o metodo salvar o nosso amigo PessoaView recebe uma requisição de um usuario para salvar um objeto pessoa, ao receber esta requisição como o pobre coitado do PessoaView não sabe salvar o objeto ele chama o Facade e pede para ele salvar o objeto pessoa… o Facade não sabe fazer isto mas conhece quem sabe o PessoaCore, este pede para o PessoaCore salvar o objeto e o PessoaCore o salva no banco…
mais tarde o SEO não quer mais que as pessoas sejam salvas no banco apartir de agora as pessoas serao salvas em xmls… e este ordena que altere as 500 telas do sisteminha que usam o objeto pessoa e faça isto para ontem… o unico trabalho que teremos e alterar o metodo salvar de nosso PessoaCore para ao invez de salvar no banco salvar em arquivos xml… não vamos precisar alterar nada referente a nossa camada de visao pois esta desconhece mesmo a existencia do PessoaCore…

O mesmo se aplica a visão… se mais tarde o CEO quiser que o sistema seja em desktop, em web ou mesmo em console :shock:
não teremos problema com o backend… apenas com o front…

Uma perguntinha: Bean == TO ?

Até +… Obrigada.

Em Tese tudo deve começar por ser uma interface. Isso permite um desing melhor. Na prática isso nem sempre é necessário. contudo, de vc quiser aumentar o desacoplamento e ter classes mais simples de testar vc usa uma interface. Assim, quando vc estiver testando, vc pode passar uma implementação “falsa” apenas para teste.

Portanto, seria interessante se o seu sistema tivesse intenção profissional. Para um sistema faz de conta não precisa. Contudo, se seu objetivo é simular que está fazendo um projeto profissional, então sim. Seria quase que obrigatório devido ao desacoplamento.

Eu já respondi isso em algum lugar. Não pertence em nenhum dos dois. Os objetos que transitam andares pertencem na camada de aplicação.
Contudo, podemos pensar neles como pertencendo ao dominio e erradiando para os outros andares. (normalmente eles ficam no pacote algumacoisa.domain)

Exatamente.

Seria melhor fazer no AgendaConfig todas as configurações de dependencia.

Não. Como diria o Spock “isso é ilógico”.

Dentro de um andar podes ter camadas de api, mas não outros andares.

Antes do MVP serem objetos eles são responsabilidades e contratos. O como são implementados é um detalhes do processo de construir o software e não pertence no padrão em si. Não ha problema que o contrato seja implementado em outra camada desde que seja por um objeto de fronteira ( se for por outro tipo de objeto é um erro conceptual). O mecanismo de callback ou de “mexer sem saber onde” é muito importante porque diminui o acoplamento.

Olá… quero agradecer a todos que me ajudaram neste tópico
E agradecer ao Sergio Taborda por todo esforço que destinou a ele também em tentar entender o melhor possível minhas perguntas para responde-las também o melhor possível…

Eu estou fazendo uma revisão geral de tudo que aprendi quanto as camadas ( andares ) de Visualização e Apresentação.
Porém esses dias lendo um artigo publicado em uma revista fiquei assustada com uma afirmação… :shock:

A afirmação é a seguinte: “A camada de Apresentação é responsável pela interação entre sistema e usuário. Como exemplo dos componentes dessa camada, podemos citar: menus de seleção, telas para entrada e apresentação de dados, caixas de diálogo e componentes que indicam a ocorrência de algum processamento, como cursores de mouse em forma de empulheta e barras indicadoras de progresso” … “existem duas bibliotecas de componentes gráficos que disputam a preferência dos desenvolvedores de sistemas desktop: SWT e Swing” …

A perguntinha é simples rapazes e meninas: Vocês também se assustaram com a afirmação que a descrição acima é da camada de Apresentação? :shock:
Porque até agora meus estudos indicam que isso é da camada de Visualização e esta sim, poderá conhecer as API SWT ou Swing, como desejar. Estou certa?

Obrigada

…

Então nos meus estudos aprendi que a camada/andar de visualização/cliente é quem recebe o input do usuário e onde também é mostrado ao usuário o resultado de suas ações. Esse usuário pode ser humano ou não. Já a camanda/andar de apresentação é quem torna os comandos do usuário coerentes com o propósito do sistema, ou seja, é ela quem toma a decisão do que acontecerá de fato. É nessa idéia que deposito minha confiança. Veja que ‘contraste’ existe naquilo dito na revista e no que está sendo dito agora… Não é assustador? :shock: Chega a causar pesadelos !! É muito óbvio que o que está escrito no artigo da revista se refere a Camada/Andar de Cliente/Visualização.

E realmente é a teoria até este momento mais realista e convencedora. É o conceito mostrado, e pacientemente explicado, pelo Sergio a quem gostaria de agradecer mais uma vez. É nisso que acredito até provarem o contrário. Ainda gostaria de saber a opinião dos demais… :idea:
Até +… Obrigada

Então nos meus estudos aprendi que a camada/andar de visualização/cliente é quem recebe o input do usuário e onde também é mostrado ao usuário o resultado de suas ações. Esse usuário pode ser humano ou não. Já a camanda/andar de apresentação é quem torna os comandos do usuário coerentes com o propósito do sistema, ou seja, é ela quem toma a decisão do que acontecerá de fato. É nessa idéia que deposito minha confiança. Veja que ‘contraste’ existe naquilo dito na revista e no que está sendo dito agora… Não é assustador? :shock: Chega a causar pesadelos !! É muito óbvio que o que está escrito no artigo da revista se refere a Camada/Andar de Cliente/Visualização.

E realmente é a teoria até este momento mais realista e convencedora. É o conceito mostrado, e pacientemente explicado, pelo Sergio a quem gostaria de agradecer mais uma vez. É nisso que acredito até provarem o contrário. Ainda gostaria de saber a opinião dos demais… :idea:
Até +… Obrigada :D

Ok. Cada um com suas teorias. Eu estou me retirando deste tópico. Boa sorte a quem fica.

ué, pelo padão MVC Model ,View, Control. a visão éo mesmo que apresentacao usa awt ou swing para fazer as telas de cada funcionalidade do programa.se vc tem um funcionalidade manter Cliente vai ter uma visão para o cadastro do cliente, nome cpf etc…
que é uma telinha para os dados do cliente ser persistido em algum lugar , cada tela de cada funcionalidade tem um Control que controla os eventos de clicar botao arrastar etc…, quando determinado evento ocorrer um objeto listener da sua tela JButton ou etc escuta que ocorrer algum evento nele e transfere a execucao pro controle fazer algo, eu acho q apresentacao é a Visao msm das 3 camadas ou no caso 4 se for usar persistencia

ingridfarabulini:

Olá… quero agradecer a todos que me ajudaram neste tópico
E agradecer ao Sergio Taborda por todo esforço que destinou a ele também em tentar entender o melhor possível minhas perguntas para responde-las também o melhor possível…

Eu estou fazendo uma revisão geral de tudo que aprendi quanto as camadas ( andares ) de Visualização e Apresentação.
Porém esses dias lendo um artigo publicado em uma revista fiquei assustada com uma afirmação… :shock:

A afirmação é a seguinte: “A camada de Apresentação é responsável pela interação entre sistema e usuário. Como exemplo dos componentes dessa camada, podemos citar: menus de seleção, telas para entrada e apresentação de dados, caixas de diálogo e componentes que indicam a ocorrência de algum processamento, como cursores de mouse em forma de empulheta e barras indicadoras de progresso” … “existem duas bibliotecas de componentes gráficos que disputam a preferência dos desenvolvedores de sistemas desktop: SWT e Swing” …

A perguntinha é simples rapazes e meninas: Vocês também se assustaram com a afirmação que a descrição acima é da camada de Apresentação? :shock:
Porque até agora meus estudos indicam que isso é da camada de Visualização e esta sim, poderá conhecer as API SWT ou Swing, como desejar. Estou certa?

Obrigada :D

Pra mim, acho que o mais certo a se dizer é : depende do ponto de vista. O Sergio, por exemplo, é extremamente detalhista com tudo. Isso faz com que ele veja diferenças entre camada de apresentação e de visualização. (o que, a certo ponto, é correto, dada a explicação no tópico).

No entanto, a maioria das pessoas não se atém a esse tipo de detalhe e, portanto, camada de visualização == camada de apresentação para essas pessoas (e, confesso, para mim mesmo não há muita diferença, porque os sistemas que desenvolvo profissionalmente têm camadas de serviços e ponto. Tanto o usuário quanto outros sistemas devem interagir com essa camada de serviços.).

Então, não precisa se espantar com esse artigo, porque provavelmente ele estava apenas se referindo ao V do MVC - e não se atendo a nomenclaturas de andares, camadas, etc.

[]´s

bdias1990:

ué, pelo padão MVC Model ,View, Control. a visão éo mesmo que apresentacao usa awt ou swing para fazer as telas de cada funcionalidade do programa.se vc tem um funcionalidade manter Cliente vai ter uma visão para o cadastro do cliente, nome cpf etc…
que é uma telinha para os dados do cliente ser persistido em algum lugar , cada tela de cada funcionalidade tem um Control que controla os eventos de clicar botao arrastar etc…, quando determinado evento ocorrer um objeto listener da sua tela JButton ou etc escuta que ocorrer algum evento nele e transfere a execucao pro controle fazer algo, eu acho q apresentacao é a Visao msm das 3 camadas ou no caso 4 se for usar persistencia

Obrigada pela sua opinião
Ela é importante para todos. Até +…

asaudate:

Pra mim, acho que o mais certo a se dizer é : depende do ponto de vista. O Sergio, por exemplo, é extremamente detalhista com tudo. Isso faz com que ele veja diferenças entre camada de apresentação e de visualização. (o que, a certo ponto, é correto, dada a explicação no tópico).

No entanto, a maioria das pessoas não se atém a esse tipo de detalhe e, portanto, camada de visualização == camada de apresentação para essas pessoas (e, confesso, para mim mesmo não há muita diferença, porque os sistemas que desenvolvo profissionalmente têm camadas de serviços e ponto. Tanto o usuário quanto outros sistemas devem interagir com essa camada de serviços.).

Então, não precisa se espantar com esse artigo, porque provavelmente ele estava apenas se referindo ao V do MVC - e não se atendo a nomenclaturas de andares, camadas, etc.

============================================================================
Camada de Aplicação --> Usuario
Camada de Apresentação --> Representação da informação (codificação e decodificação)
Camada de Sessão --> Multiplexação da Transmissão (portas e socktes)
Camada de Transporte --> Garantia de entrega e sequencia
Camada de Rede --> Roteamento e envio do datagrama
Camada de Enlace --> Enquadramento e envio de loop-local
Camada Fisica --> Hardware

Ps: Cada camada opera, realiza mais funçoes, mas isso ta bom para um resumão.

Eis a minha contribuição ingridfarabulini

Deixo esta informação adicional para vc ingrid.Não é bem o que vc pediu, mas OK

Olá pessoal…

Dei uma lida rápida sobre os posts e acho que a colega está bem servida de explicações…

Vou colocar aqui apenas algumas observações sobre o que eu penso de todas essas camadas…

Desenvolvo sistemas web, e como nosso colega Daniel mencionou, 3 camadas são suficientes para a maioria das situações em que trabalho (web, serviço e dao)
Na minha camada web, tenho ainda um controller (uma classe Controller) e a visão (JSP) (Provavelmente o colega também terá)
Minha camada de serviços (Service), geralmente contém regras de negócios, e não integram com camadas externas como banco de dados, ou servlets, http.
Minha camada DAO fará acesso ao banco de dados, então conterá código de persistencia e integração com JDBC, etc.
Ainda tenho as entidades que são qualquer coisa entre os DTO, VO, TO… (uma classe com atributos, getters e setters apenas, que mapeio em tabelas do banco de dados)
Essas entidades trafegam em todas as camandas.

Uma dica simples para você observar sobre sua arquitetura, é verificar os imports que você está usando na sua classe.
Se numa classe de apresentação você está dando import de java.sql, está errado.
Se numa classe de persistencia ou negócios você está dando import de javax.swing também está errado.
O import não é uma medida perfeita de separação de camandas mas já dá alguma diretiva básica.
Com o tempo e experiencia você vai começar a separar também os pacotes da sua própria aplicação.
Cada vez mais refinando o código e melhorando a arquitetura.

Sobre os design patterns, as 3 diretivas básicas são:
1 - Favorecer a composição ao invés da herança
2 - Programe para interfaces
3 - Alta coesão e baixo acoplamento

Você pode começar com a diretiva 3, que significa: Mantenha códigos relacionados próximos (alta coesão), ou seja, se tem uma função de excluir e outra de incluir um funcionário, elas devem estar próximas. Na mesma classe por exemplo. Faça sua classe conhecer o mínimo possível de outras classes (baixo acoplamento), siga a dica dos imports, quanto menos melhor. E também quanto menos variados (menos pacotes diferentes) melhor.

Espero ter adicionado algo útil a discussão…

Até mais

Olá… na verdade essas camadas do título é referente a camadas lógicas ( andares ) de um sistema. Mas acabou sendo interessante porque nessas camadas de rede, visto que analizou a citação do artigo que fala de camadas lógicas, você discorda e também acredita que o que nele está escrito pertence a Camada/Andar de Visualização. Isso é exatamente o que aprendi e fico feliz que é assim também em uma estrutura de redes.

Muito obrigada
Ficarei aguardando por mais opiniões…

rogelgarcia:

Olá pessoal…

Dei uma lida rápida sobre os posts e acho que a colega está bem servida de explicações…

Vou colocar aqui apenas algumas observações sobre o que eu penso de todas essas camadas…

Eu, ao contrário de ti, sempre programei Desktop mas sem seguir nenhum padrão. Chega uma hora que você acaba percebendo que há uma necessidade de começar a programar as coisas de uma forma universal ou próximo daquilo que as outras pessoas conseguem entender. Por isso quando aprendo uma coisa e leio outra fico indignada… faço o esforço possível para aprender aquilo que é certo e de repente me deparo com um artigo em uma boa revista dizendo outra coisa e até mesmo invalidando aquilo que foi aprendido. Fico confusa… :? Mas o caso do artigo é um dos casos de exemplo à parte… O que gostaria de saber da comunidade que utiliza ou conhece essas duas camadas/andares de Visualização e Apresentação é realmente quais são as suas reais diferenças. Muitos dizem que não há diferenças, são iguais. Outros poucos dizem que sim, existem diferenças sim. E alguns dizem: Não existe uma e outra, as duas é uma :shock:

Ao meu entender, sim, existe diferença e a principal delas é justamente deixar a Visualização completamente independente da Apresentação, como no caso de substituir uma SWT por SWING ou JavaFX. Até mesmo como citou o Rogel em relação aos imports. A apresentação não deve ter nenhum import do Swing, ou melhor, nada. Mas a visualização pode ter e muito é para isso que essa camada/andar serve.

Mas precisaria muito da opinião de vocês. O conceito foi a mim explicado pelo Sergio Taborda e essa idéia é até este momento a melhor, a certa… mas se existe algum problema/desentendimento com relação a ela preciso conhecer… porque as pessoas teimam em rejeitar tanto esse conceito? O que há de errado nele?

Obrigada
Ficarei aguardando mais opiniões

condordo com meu colega não vejo diferença !

ingridfarabulini:

asaudate:

Pra mim, acho que o mais certo a se dizer é : depende do ponto de vista. O Sergio, por exemplo, é extremamente detalhista com tudo. Isso faz com que ele veja diferenças entre camada de apresentação e de visualização. (o que, a certo ponto, é correto, dada a explicação no tópico).

No entanto, a maioria das pessoas não se atém a esse tipo de detalhe e, portanto, camada de visualização == camada de apresentação para essas pessoas (e, confesso, para mim mesmo não há muita diferença, porque os sistemas que desenvolvo profissionalmente têm camadas de serviços e ponto. Tanto o usuário quanto outros sistemas devem interagir com essa camada de serviços.).

Então, não precisa se espantar com esse artigo, porque provavelmente ele estava apenas se referindo ao V do MVC - e não se atendo a nomenclaturas de andares, camadas, etc.

Olá… não entendi muito bem essa Camada de Serviços… Não existe uma UI para o usuário? :roll:
Poderia explicar melhor? Obrigada

Existe sim! É que eu trabalho com SOA, então, todos os métodos “de negócio” são expostos como web services. Então, a camada cliente sempre tem que consumir esses serviços. Nós fazemos a interface (que pode ser feita em qualquer coisa - de Swing a J2EE a outras linguagens) e essa interface tem que consumir os web services, sempre.

Espero que tenha entendido… se quiser , eu dou uma explicação mais clara sobre SOA…

[]´s

asaudate:

ingridfarabulini:

asaudate:

Pra mim, acho que o mais certo a se dizer é : depende do ponto de vista. O Sergio, por exemplo, é extremamente detalhista com tudo. Isso faz com que ele veja diferenças entre camada de apresentação e de visualização. (o que, a certo ponto, é correto, dada a explicação no tópico).

No entanto, a maioria das pessoas não se atém a esse tipo de detalhe e, portanto, camada de visualização == camada de apresentação para essas pessoas (e, confesso, para mim mesmo não há muita diferença, porque os sistemas que desenvolvo profissionalmente têm camadas de serviços e ponto. Tanto o usuário quanto outros sistemas devem interagir com essa camada de serviços.).

Então, não precisa se espantar com esse artigo, porque provavelmente ele estava apenas se referindo ao V do MVC - e não se atendo a nomenclaturas de andares, camadas, etc.

Olá… não entendi muito bem essa Camada de Serviços… Não existe uma UI para o usuário? :roll:
Poderia explicar melhor? Obrigada

Existe sim! É que eu trabalho com SOA, então, todos os métodos “de negócio” são expostos como web services. Então, a camada cliente sempre tem que consumir esses serviços. Nós fazemos a interface (que pode ser feita em qualquer coisa - de Swing a J2EE a outras linguagens) e essa interface tem que consumir os web services, sempre.

Espero que tenha entendido… se quiser , eu dou uma explicação mais clara sobre SOA…

• Camada/Andar de Visualização/Cliente com Swing conhece a Camada/Andar de Apresentação e implementa ( não obrigatoriamente ) uma interface.
• Camada/Andar de Apresentação é quem define qual objeto de negócio deve ser utilizado na interação do usuário com a Visualização. Este andar usa MVP ( não obrigatoriamente ). O V é a interface implementada no andar acima e quem disponibiliza a forma de mostrar o resultado da interação do usuário com o sistema.

Realmente é o que entendi… e ao meu ver você também no caso do SOA. Veja: Aqui já são três pessoas dizendo a mesma coisa. E já são três exemplos em situaçãoes diferentes que refletem a mesma coisa (Uma em Desktop, uma em SOA e até em Redes). Mas porque a maioria diz: É TUDO IGUAL sem muito justificar? Será que não vai causar nenhum problema lá na frente essa afirmação mesmo sabendo que não é certo?

Obrigada a todos que estão ajudando…
Continuarei super atenta a novas opiniões… Até+…

ingridfarabulini:

asaudate:

ingridfarabulini:

asaudate:

Pra mim, acho que o mais certo a se dizer é : depende do ponto de vista. O Sergio, por exemplo, é extremamente detalhista com tudo. Isso faz com que ele veja diferenças entre camada de apresentação e de visualização. (o que, a certo ponto, é correto, dada a explicação no tópico).

No entanto, a maioria das pessoas não se atém a esse tipo de detalhe e, portanto, camada de visualização == camada de apresentação para essas pessoas (e, confesso, para mim mesmo não há muita diferença, porque os sistemas que desenvolvo profissionalmente têm camadas de serviços e ponto. Tanto o usuário quanto outros sistemas devem interagir com essa camada de serviços.).

Então, não precisa se espantar com esse artigo, porque provavelmente ele estava apenas se referindo ao V do MVC - e não se atendo a nomenclaturas de andares, camadas, etc.

Olá… não entendi muito bem essa Camada de Serviços… Não existe uma UI para o usuário? :roll:
Poderia explicar melhor? Obrigada

Existe sim! É que eu trabalho com SOA, então, todos os métodos “de negócio” são expostos como web services. Então, a camada cliente sempre tem que consumir esses serviços. Nós fazemos a interface (que pode ser feita em qualquer coisa - de Swing a J2EE a outras linguagens) e essa interface tem que consumir os web services, sempre.

Espero que tenha entendido… se quiser , eu dou uma explicação mais clara sobre SOA…

Olá novamente… então ‘casa’ direitinho a sua explicação com o que aprendi. Olha só comparar:

• Camada/Andar de Visualização/Cliente com Swing conhece a Camada/Andar de Apresentação e implementa ( não obrigatoriamente ) uma interface.
• Camada/Andar de Apresentação é quem define qual objeto de negócio deve ser utilizado na interação do usuário com a Visualização. Este andar usa MVP ( não obrigatoriamente ). O V é a interface implementada no andar acima e quem disponibiliza a forma de mostrar o resultado da interação do usuário com o sistema.

Realmente é o que entendi… e ao meu ver você também no caso do SOA. Veja: Aqui já são três pessoas dizendo a mesma coisa. E já são três exemplos em situaçãoes diferentes que refletem a mesma coisa (Uma em Desktop, uma em SOA e até em Redes). Mas porque a maioria diz: É TUDO IGUAL sem muito justificar? Será que não vai causar nenhum problema lá na frente essa afirmação mesmo sabendo que não é certo?

Obrigada a todos que estão ajudando…
Continuarei super atenta a novas opiniões… Até+…

Sim, o modelo em camadas é igual para todo mundo (que nem, aliás, eu te disse no começo do tópico: a camada de cima se comunica com a imediatamente abaixo mas não tem conhecimento das demais). Só o conceito de “andar”, mesmo, parece um pouco obscuro e, na verdade, até irrelevante, por dois motivos:

1. O modelo de camadas já é auto-suficiente, não precisa de um modelo “complementar”;
2. Como você viu, muita gente não conhece, o que, pela prática empírica, leva a crer que é um conceito desnecessário.

[]´s

ceklock:

ingridfarabulini:

… A afirmação é a seguinte: “A camada de Apresentação é responsável pela interação entre sistema e usuário. Como exemplo dos componentes dessa camada, podemos citar: menus de seleção, telas para entrada e apresentação de dados, caixas de diálogo e componentes que indicam a ocorrência de algum processamento, como cursores de mouse em forma de empulheta e barras indicadoras de progresso” … “existem duas bibliotecas de componentes gráficos que disputam a preferência dos desenvolvedores de sistemas desktop: SWT e Swing” …

A perguntinha é simples rapazes e meninas: Vocês também se assustaram com a afirmação que a descrição acima é da camada de Apresentação? :shock:
Porque até agora meus estudos indicam que isso é da camada de Visualização e esta sim, poderá conhecer as API SWT ou Swing, como desejar. Estou certa?..

Não me assustei e achei correta a afirmação. Aliás, qual a diferença entre camada de apresentação e camada de visualização? Pra mim não tem nenhuma diferença, só o nome.

gpd38:

============================================================================
Camada de Aplicação --> Usuario
Camada de Apresentação --> Representação da informação (codificação e decodificação)
Camada de Sessão --> Multiplexação da Transmissão (portas e socktes)
Camada de Transporte --> Garantia de entrega e sequencia
Camada de Rede --> Roteamento e envio do datagrama
Camada de Enlace --> Enquadramento e envio de loop-local
Camada Fisica --> Hardware

Ps: Cada camada opera, realiza mais funçoes, mas isso ta bom para um resumão.

Eis a minha contribuição ingridfarabulini

Deixo esta informação adicional para vc ingrid.Não é bem o que vc pediu, mas OK
=============================================================================

Ta no forum errado… guarde isto para um forum de redes… pois não é isto que o topico se refere…

gpd38, (in)felizmente vou ter q concordar c/ o colega luistiagos! =P

Olá… Obrigada pelas respostas.

Desde que aprendi a programar sempre saí fazendo códigos com a arquitetura “de qualquer jeito :P” mas chega um momento que é necessário fazer as coisas no mínimo legíveis as outras pessoas. Minha forma de programar é péssima por isso quero aprender novos conceitos, teorias, padrões, arquiteturas, engenharia, etc… que tivessem compreensão universal entre os programadores para melhorar essa forma de ver o sistema afim que a codificação também sofresse uma melhora. Mas já percebi que da mesma forma que as pessoas não entendem os meus códigos essas mesmas pessoas não entendem a arquitetura das outras pessoas ou tentam ao máximo evitar entender ou até entendem, mas evitam falar dela mesmo sendo muito boa. :roll:
Outros então preferem alegar o seguinte: ‘Continue fazendo do jeito que está fazendo sem se preocupar com a arquitetura’. Mas são os mesmos que depois olham o código e dizem: ‘Nossa, tá tudo misturado… não está padronizado… fora dos seus corretos lugares… sem condições de manutenção, expansão, etc…’ :shock:

Acredito que para defender ou condenar um determinado estudo, conceito, teoria ou prática deve-se primeiro cercar-se de ‘razões e motivos’ para que aquilo seja entendido como uma coisa boa ou não. Não quero distinguir nenhum usuário mas sempre que precisei postar ( neste pouco tempo de fórum ) alguma dúvida, coincidência ou não, quem sempre respondeu as perguntas com muita atenção e preocupação de entender a dúvida e responder de uma forma mais compreensível, didática e detalhada possível sempre baseado em fortes estudos foi o Sergio Taborda até o momento. Quando criei o tópico este fica no fórum sempre disponível a todos que queiram responde-lo mas o que percebi mesmo são constantes críticas a qualquer ideia que aparece como ajuda, seja do Sergio ou de qualquer outro usuário.

Mas se alguém ( não importa quem ) enxergou em um sistema STANDALONE ( DESKTOP ) que existem duas importantes camadas lógicas ( aka Andares ) que são VISUALIZAÇÃO/CLIENTE e APRESENTAÇÃO não consigo entender como ainda tem gente batendo na mesma tecla dizendo: ‘É tudo a mesma coisa!’. Está mais que óbvio que tendo a visualização solta da apresentação tenho uma flexibilidade enorme para alterar entre APIs diferentes ( As telas com Swing, SWT, JavaFX,… ) sem precisar mexer sequer uma linha na minha apresentação ( que dá vida as telas ). Sem falar que ‘estamos olhando o futuro’ no caso de um sistema pequeno se tornar uma coisa maior, tornando extensível.

Agora livros e artigos não foram escritos por Deuses. A ‘maioria nos fóruns’ juntos também não formam um Deus… e Taborda não é de outra galaxia :lol: Mas porque as pessoas simplesmente chegam e falam: ‘Não faça isso, vá pela maioria’ mas não mostram o PORQUE de realmente seguir com a maioria e desprezar a minoria. Será que a maioria está errada mas como o erro está dando certo vamos continuar errando ou será que a minoria está errada e vamos continuar criticando? Mas se está errado, QUAL É O ERRO? Porque não assumir as duas camadas ao invés de misturar o que está claramente divizível em uma só camada? :shock:

Vejam o asaudate falou que discordava, explicou e colocou seu ponto de vista. Olha que legal, fez entender o porque !!
O Rogel, o Derlon… explicaram o porque !! Isso que é importante. Por isso voltarei a deixar mais uma vez em aberto a pergunta desta POSTAGEM. Quero saber de vocês: Não seria melhor existirem duas camadas lógicas ( aka Andares ) uma de Visualização/Cliente ( Sistema STANDALONE/DESKTOP ) e uma de Apresentação sendo que os motivos estão sendo explicados aqui neste artigo?

Obrigada, desculpem mas isto não é uma postagem para ofender ninguém. Não entendam minhas palavras como uma ofença por favor… mulher fala demais… estaria eu me tornando uma prolixa !! :shock: :lol:
Até mais aguardarei pelas respostas…

Ingrid, aí é que está a grande questão…

Não acho que tenhamos conceitos divergentes, apenas uma nomenclatura diferente. Até aqui, o que eu entendí é o que o que eu chamo de camada de serviços / barramento, você (e o Sergio) chamam de andar de apresentação.

Veja que não é só com a gente que isso acontece, os Design Patterns VO/DTO/BO ilustram bem o que eu estou querendo dizer…

Então, só pra concluir: não temos conceitos diferentes. Como você disse na postagem anterior, você queria ser entendida por todos, correto? Acontece que POUCOS se entendem!

[]´s

Calma. não existe camada de visualização. Os nomes são “apresentação” e “cliente”. O andar de cliente , chamado também “O cliente” é quem interage diretamente com o usuário. Para humanos é algum tipo de GUI, para sistemas é webservices, ou algo assim.

Esta camada é burra e serve para o mesmo que a camada de integração , mas ao contrário.

A camada de apresentação que tem as regras. Faz validações ,etc…

O texto citado está falando do cliente, mas chamado de “apresentação”. Cliente e apresentação não são a mesma coisa. A mesma apresentação pode ser usada para cliente diferentes ( exemplo, Swing e SWT)

Não é uma questão de detalhes, é uma questão tecnica da definição de andares. não faz sentido dizer que cliente e apresentação são a mesma coisa, seria como dizer que negocio e banco são a mesma coisa.

Aquilo que vc chama de “camada se serviços” é a apresentação do seu sistema. Se forem webservices, então o mecanismo de lê e escreve SOAP e recebe e envia mensagens é o seu cliente.

Nomenclatura cada um usa a que quiser, é mais importante entender do que a pessoa está falando quando ela não usa a mesma nomenclatura. O problema é que os novatos tem uma ânsia muito grande em achar que tudo é a mesma coisa… e acabando perdendo partes importantes. Por exemplo, achar que o V do MVC é uma camada, e outros disparates assim apenas porque o V é de View e a tradução de view é “Visualização” que é a mesma coisa que “Apresentação”… asneira!

rogelgarcia:

Olá pessoal…

Dei uma lida rápida sobre os posts e acho que a colega está bem servida de explicações…

Vou colocar aqui apenas algumas observações sobre o que eu penso de todas essas camadas…

Desenvolvo sistemas web, e como nosso colega Daniel mencionou, 3 camadas são suficientes para a maioria das situações em que trabalho (web, serviço e dao)

Isso é o que vc pensa, mas não é o que vc usa.

O cliente de uma aplicação web é o browser. É com ele que o usuario interage. O browser é uma aplicação que roda num nodo diferente do servidor, e eles se comunicam via HTTP. Dentro do browser, existem as várias camadas/andares. Vc tem controle de duas. Apresentação e Integração. A camada cliente do browser vc não controla (vc não pode disparar eventos, o browser é que os dispara e informa vc). A camada apresentação pode ser manipulada com javascript ( regras) e css (estilos) A integração pode ser controlada por html, javascript e o compoenente ajax do browser.

No servidor a view não é o JSP. Isto é um erro. A JSP é apenas um renderizador especial do protocolo HTML/HTTP o que o torna membro da camada de recursos. O servlet controlador é o cliente. A apresentação é definida nos actions, as regras de negocio nos serviços e entidades ( camada de negocio) e o acesso ao banco nos dao ( camada de integração). O servlet que gera o JSP é da camada de integração tb. Quando vc usa outro mecanismo,como Freemarker ou Velocity ou qq coisa não jsp, os renderizadores desses caras estão no andar de integração. Não na view. O cliente do servidor é o proprio servidor em si, é o cara que abre as portas, trabalha o HTTP, etc… é o “cavalo” que suporta toda a interação com o browser.

É bom pensar num modelo 3 camadas. Por alguma razão 3 é um numero mágico. Mas isso não faz com que seja verdade que existam apenas 3 camadas. Faz com que seja real que só 3 camadas sejam enxergadas. Se vc pensar que existem 5, vc enxerga 5. É uma questão de prespetiva.
Como 5 camadas é mais desacoplado que 3, obviamente é mais vantajoso pensar assim. Porquê ? porque as camadas são “plug and play” e quando mais elas forem assim, mais fácil é de criar e manter o sistema. (eu disse fácil, não necessáriamente simples. Desacoplamento limpo exige muito esforço - qualquer um pode corta um pepino com uma faca, mas apenas uma espada samurai milenar forgada com aco do meteorito garante o corte mais limpo. )

às vezes as pessoas confundem muito as coisas por causa do numero 3.
3 nodos : cliente, servidor de aplicação, servidor de banco
3 componentes MVC
3 camadas (apresentação, negocio, dao)

Deixem de pensar em triangulos… não evolui nada …

asaudate:

Ingrid, aí é que está a grande questão…

Não acho que tenhamos conceitos divergentes, apenas uma nomenclatura diferente. Até aqui, o que eu entendí é o que o que eu chamo de camada de serviços / barramento, você (e o Sergio) chamam de andar de apresentação.

Veja que não é só com a gente que isso acontece, os Design Patterns VO/DTO/BO ilustram bem o que eu estou querendo dizer…

Então, só pra concluir: não temos conceitos diferentes. Como você disse na postagem anterior, você queria ser entendida por todos, correto? Acontece que POUCOS se entendem!

[]´s

Na verdade, me gerou uma dúvida: A sua Camada de Serviços acessa os métodos da Camada de Negócios, certo? E nessa camada também estão as classes responsáveis em exibir a tela ao usuário?

Obrigada…

Olá Sergio

Desculpa mas essas regras se referem a que? Seriam somente as regras de segurança e as que definem o comportamento do sistema ( no caso, qual método chamar no negócio/domínio )?
E as validações? Validações do tipo ‘Pessoa não existe’ ou ‘Telefone inválido’… não né? Essas validações são de negócios/domínio não?

Entendi que a Apresentação deve ser o andar que organiza/direciona as chamadas aos métodos do andar abaixo e que responde ao andar acima o comportamento ocorrido abaixo de forma que o usuário entenda o que aconteceu. Entendi dessa forma… ainda mais quando neste andar aplica-se o padrão MVP. Validações, para mim, eram responsabilidade do modelo… Assim:

Obrigada

ingridfarabulini:

Olá Sergio

Desculpa mas essas regras se referem a que? Seriam somente as regras de segurança e as que definem o comportamento do sistema ( no caso, qual método chamar no negócio/domínio )?
E as validações? Validações do tipo ‘Pessoa não existe’ ou ‘Telefone inválido’… não né? Essas validações são de negócios/domínio não?

Esse assunto é complexo. Já foi discutido outras vezes no guj. O fato de um objeto ter responsabilidades de dominio, não significa que ele é executado no andar de dominio. É por isso que andar não é a mesma coisa que camada. As entidades que usamos são o “coracao” do dominio , mas contudo elas ficam viajando por todas as camadas. Nas aplicações modernas isto é comum.

A validação pode ser invocada pela apresentação, por exemplo, para saber que uma data inputada existe ( 30 de fevereiro não existe) e depois a mesma data ser validada de novo na camada de negocio para saber que ela está dentro de um intervalo especial que é estipulado pelas regras do dominio. Todas as regras de validação são dominio, mas nem todas são do mesmo dominio.No caso aqui, a primeira validação é uma validação do dominio de datas ( datas tem regras especiais que sempre são verdade), e o segundo é do dominio de negocio. É por isto que eu não gosto do nome “regras de negocio” porque 80% das regras não são realmente definidas pelo dono do negocio. As pessoas tendem a apresentar este assunto de forma simplista.

O exemplo da segurança é apenas uma das n coisas possiveis que propositalmente não foi um exemplo de negocio. (mas é um exemplo de dominio. dominio de segurança)

O conceito que vc tem que de o andar A chama o andar B etc… como se fosse numa corrente ou numa cascata não é exato. Serve como primeira aproximação, mas não serve para o que realmente acontece num sistema. Veja, se o validador pertence ao andar de negocio - e pertence, isso é fato - então quando o andar de apresentação o invoca não está ele invocando o andar “abaixo” ? Está. Mas ele está passando o contole ? Não.

É aqui que está o ponto pivot. Nem todas as invocações de um andar ao outro são passagens de controle. Os andares não se definem por “regiões de controle” como as camadas comuns. Eles se definem como “regiões” de responsabilidade onde vc coloca as classes. Isso é para poder melhor separar a responsabilidade de cada uma e chegar num melhor design.

Sim, mas agora que vc aprendeu isso, vc ficou limitada a pensar assim. Isso é o conceito geral, mas nem sempre essa chamada dos métodos do andar de baixo significa “continua ai que eu lavo minhas mãos” significa particularmente “me ajuda a tomar uma decisão”. Sobretudo na camada de apresentação isto é o que mais acontece. Um sistema de cadastro apresenta um formulário ao usuário, e antes do usuário apertar save, já foram verificadas uma serie de regras , validações, consistencias, etc… tudo isso pela camada de apresentação, sem ter persistido nada. Como a apresentação sabe? ela não sabe, ela pergunta. Ela aciona que sabe.

Cabe à apresentação decidir o fluxo, saber o que o usuário está comanando ( se é save , se é delete, etc…) mas cabe a ela tb controlar esses comandos e os interromper quando não são válidos. O exemplo classico é que quando vc não preenche os campos a obrigatórios vc recebe a mensagem “preencha os campos obrigatórios” quem lhe está dizendo isto ? quem o está impedindo de continuar ? a camada de apresentação. Mas quais regras estão impedindo ? as de negocio.

Separar as coisas em camadas, andares, etc… é interessante para podermos trabalhar e escrever classes e codigo, mas não podemos esquecer nunca que o sistema é uno. Todas essas classes, andares, etc… só existem na nossa cabeça, no final o software é o resultado da simbiose de tudo isso e está tudo ligado.

ingridfarabulini:

asaudate:

Ingrid, aí é que está a grande questão…

Não acho que tenhamos conceitos divergentes, apenas uma nomenclatura diferente. Até aqui, o que eu entendí é o que o que eu chamo de camada de serviços / barramento, você (e o Sergio) chamam de andar de apresentação.

Veja que não é só com a gente que isso acontece, os Design Patterns VO/DTO/BO ilustram bem o que eu estou querendo dizer…

Então, só pra concluir: não temos conceitos diferentes. Como você disse na postagem anterior, você queria ser entendida por todos, correto? Acontece que POUCOS se entendem!

[]´s

Entendi sim… legal. Você explicou bem a sua visão, desculpe se usei o verbo discordar no sentido geral da questão… realmente o discordar estava em relação a nomenclatura.

Na verdade, me gerou uma dúvida: A sua Camada de Serviços acessa os métodos da Camada de Negócios, certo? E nessa camada também estão as classes responsáveis em exibir a tela ao usuário?

Obrigada… :D

Não, de jeito nenhum! A idéia é que a camada de serviços seja responsável somente pelo negócio (ou seja, corresponde ao "andar de apresentação). Ela não pode ter conhecimento algum sobre a visualização (até porque, como eu disse, essa apresentação pode ser feita em qualquer coisa, incluindo aí outras linguagens).

Lembra do que eu disse sobre o modelo de camadas? O modelo é mais ou menos esse:

-> Visualização
-> Serviços
-> Recursos

A camada de visualização tem conhecimento sobre a camada de serviços, mas não sobre a de recursos. E a de serviços tem conhecimento sobre a de recursos, mas não sobre a de visualização. E a de recursos não tem conhecimento sobre nenhuma das duas. Resumindo: num modelo em camadas, uma camada tem conhecimento apenas sobre a camada imediatamente subjacente, e mais nenhuma.

[]´s

Pra mim, por exemplo, funciona assim: a validação está presente tanto na visualização, quanto nos serviços, quanto na persistência. Na visualização, para evitar chamadas desnecessárias aos serviços. Nos serviços, para validar de acordo com regras de negócio. Na persistência, para checar a integridade dos dados.

[]´s

Olá… continuando meus estudos fiquei com uma dúvida: ‘Camada de Aplicação’ e ‘Camada de API’ são ambos a mesma coisa, só muda a palavra? Podemos definir ambas como ‘Camadas de Código’ que vão estar presentes dentro dos andares?

Editado: Só para completar a pergunta acima, uma API também é um framework? Digo, Swing é uma camada API java e também é um framework?

Obrigada

ingridfarabulini:

Olá… continuando meus estudos fiquei com uma dúvida: ‘Camada de Aplicação’ e ‘Camada de API’ são ambos a mesma coisa, só muda a palavra? Podemos definir ambas como ‘Camadas de Código’ que vão estar presentes dentro dos andares?

Não. Quando se usa a nomenclatura de andar / nodo / plataforma a palavra “camada” significa apenas “conjunto de classes que colaboram para um fim único” , mas “conjunto de classes que colaboram para um fim único” é uma API, portanto “Camada de API” é um pleonasmo para deixar claro que estamos referindo a um conjunto de classes e não ao “nivel” que elas ocupam no sistema.

Todo o framework é uma API, mas nem toda a API é um framework. O Swing é ambos.
Um framework é uma API “imcompleta” ou seja, que para funcionar , quem a for usar tem que implementa algumas coisas.

sergiotaborda:

ingridfarabulini:

Olá… continuando meus estudos fiquei com uma dúvida: ‘Camada de Aplicação’ e ‘Camada de API’ são ambos a mesma coisa, só muda a palavra? Podemos definir ambas como ‘Camadas de Código’ que vão estar presentes dentro dos andares?

Não. Quando se usa a nomenclatura de andar / nodo / plataforma a palavra “camada” significa apenas “conjunto de classes que colaboram para um fim único” , mas “conjunto de classes que colaboram para um fim único” é uma API, portanto “Camada de API” é um pleonasmo para deixar claro que estamos referindo a um conjunto de classes e não ao “nivel” que elas ocupam no sistema.

O que seria, então, uma “Camada de Código”?

Obrigada por me ajudar mais uma vez

.