Infalíveis 'n' Camadas ;)

Programação Arquitetura
#1

Olá rapazes e moças do fórum… tudo bem com vocês??
Obrigada por se interessar em abrir este tópico para me ajudar :smiley:

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.

Mas, nesse meio todo, encontrei os mais diversificados nomes para essas camadas lógicas, o que acabou no lugar de facilitar, me atrapalhando. Veja:

Camada de Apresentação
Camada de Aplicação
Camada de Negócios
Camada de Dados
Camada de Interface
Camada Web
Camada Cliente
Camada Servidor
Camada de Domínio
Camada Business
Camada de Integração
Camada de Serviços
Camada de Informação Distribuída(EIS)
Camada de Persistencia
Camada de Recursos

  • infalíveis ‘n’ camadas…

Bom, lendo sobre cada uma cheguei a conclusão que muitas delas só tem a nomenclatura diferente, pois sua especialidade é a mesma.
Então, minha perguntinha é simples aos olhos daqueles com vaga experiência em desenvolvimento de software: Quais são as nomenclaturas básicas e mais conhecidas/populares das camadas citadas acima e se existe alguma outra na qual não conheci? Quais delas devo estudar para desenvolver um sistema desktop com swing que rodará em uma única máquina com banco de dados?

Em outro tópico, mais especificamente este estava discutindo com os colegas o uso do pattern MVC aplicado em um sistema que seria uma simples agenda de pessoas. Até para facilitar a você que está tentando me ajudar, como exemplo, quais seriam as camadas lógicas necessárias para um sistema de uma agenda pessoal, na sua opinião? Ao meu entender, são três: Camadas de Apresentação, Domínio e Recursos. Será que estou certa? Algo que esteja esquecendo…? :roll:

Obrigada por me ajudar ou tentar… é a segunda vez que inicio um tópico novo, estou muito feliz. :smiley:
Aguardarei, até +.

#2

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

#3

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

É 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.

#4

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.

#5

[quote=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[/quote]

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 :smiley:

#6

[quote=ingridfarabulini][quote=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[/quote]

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 :smiley: [/quote]

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:

[code] 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();
}
}
[/code]

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

#7

[quote=sergiotaborda]A graça do padrão Layer é que vc pode ter quantas camadas quiser :slight_smile:

É 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.[/quote]
Oi Sergio, que bom estar aqui :smiley: :smiley:
Nossa adorei a sua explicação + a explicação no link do Java Building.
Agora está muito claro para mim o que é o padrão Layer e onde ele está aplicado e onde se aplica. :wink:

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… :smiley:

#8

[quote=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.[/quote]

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

#9

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. :smiley: Até +

#10

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 :slight_smile:

#11

[quote=André Fonseca][quote=ingridfarabulini]

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

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.

[quote]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
[/quote]

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 :slight_smile: [/quote]
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 :smiley:

#12

[quote=ingridfarabulini][quote=André Fonseca][quote=ingridfarabulini]

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

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.

[quote]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
[/quote]

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 :slight_smile: [/quote]
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 :smiley:
[/quote]

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

[code]UsuarioAutenticaRemoto {
public boolean autenticaUsuarioEmUmSistemaRemoto(Usuario usuario) {}
}

UsuarioSalvaCookie {
public void salvaCookie(Usuario usuario) {}
}

UsuarioAtualiza {
public void atualizaDadosUsuarioBD(Usuario usuario) {}
}[/code]

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

[code]UsuarioFachada {

public boolean autenticaUsuario(Usuario usuario) {

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

}[/code]

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 ?? :slight_smile:

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

#13

[quote=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

[code]UsuarioAutenticaRemoto {
public boolean autenticaUsuarioEmUmSistemaRemoto(Usuario usuario) {}
}

UsuarioSalvaCookie {
public void salvaCookie(Usuario usuario) {}
}

UsuarioAtualiza {
public void atualizaDadosUsuarioBD(Usuario usuario) {}
}[/code]

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

[code]UsuarioFachada {

public boolean autenticaUsuario(Usuario usuario) {

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

}[/code]

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 ?? :slight_smile:

se quiser mais informação sobre Design Patterns (GOF) dê uma olhada neste site[/quote]
Oi…
Eu entendi isso como um caso de uso aplicado hihihi… desculpe meu desconhecimento. :stuck_out_tongue:
Mas entendi sua idéia sim e gostei muito. Por exemplo, o Facade irá cair muito bem no andar de negócios/domínio. Até porque pretendo fazer minha apresentação usando o MVP que aprendi.
Nesse caso, os modelos da apresentação chamariam os métodos desse Facade, certo?

Obrigada por me ajudar :smiley:

#14

[quote=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. [/quote]

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.

#15

[quote=FrancoC][quote=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. [/quote]

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.[/quote]

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 :smiley:

#16

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. :smiley: Até +[/quote]

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

#17

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. :smiley: Até +[/quote]

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[/quote]
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 :smiley:

#18

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. :smiley: Até +[/quote]

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[/quote]
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[/quote]

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

#19

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. :smiley: Até +[/quote]

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[/quote]
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[/quote]

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[/quote]
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 :smiley:

#20

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. :smiley: Até +[/quote]

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[/quote]
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[/quote]

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[/quote]
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[/quote]

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