Infalíveis 'n' Camadas ;)

GUJ Expert Membro desde: 10/07/2006 10:37:23 Mensagens: 3161 Offline

gpd38 wrote:============================================================================
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...

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

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

This message was edited 1 time. Last update was at 16/06/2010 22:50:16

Olá..

Obrigada pelas respostas.

Desde que aprendi a programar sempre saí fazendo códigos com a arquitetura "de qualquer jeito

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

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

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

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?

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 !!

Até mais aguardarei pelas respostas..

This message was edited 2 times. Last update was at 17/06/2010 12:10:36

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

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

asaudate wrote:

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

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.

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

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!

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

rogelgarcia wrote: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 wrote: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..

Olá Sergio

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

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:

Apresentação - cuida de interpretar e responder aos comandos do usuário de uma forma coerente com o propósito do software. Apertar um botão é um comando comum que a visualização irá receber, mas o que acontecerá pode ser muito diversificado. Cabe à apresentação decidir. A apresentação pode conter regras de segurança que detectam comandos não autorizados dos usuários. ( fonte: JavaBuilding )

Obrigada

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

ingridfarabulini wrote:Olá Sergio

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

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.

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

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

asaudate wrote: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..

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

This message was edited 1 time. Last update was at 18/06/2010 10:38:59

sergiotaborda wrote:
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.

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

This message was edited 1 time. Last update was at 11/07/2010 22:13:24

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

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

ingridfarabulini wrote: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.

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

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

ingridfarabulini wrote: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.

Olá Sergio,
Entendi perfeitamente a sua explicação sobre "Camada de API".

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

Obrigada por me ajudar mais uma vez

This message was edited 2 times. Last update was at 17/04/2012 12:28:21

.

Notícias, artigos e o maior fórum brasileiro sobre Java