condordo com meu colega não vejo diferença !
[quote=ingridfarabulini][quote=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.[/quote]
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 
[/quote]
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
[quote=asaudate][quote=ingridfarabulini][quote=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.[/quote]
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
[/quote]
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…[/quote]
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é+…
[quote=ingridfarabulini][quote=asaudate][quote=ingridfarabulini][quote=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.[/quote]
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
[/quote]
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…[/quote]
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é+…[/quote]
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:
- O modelo de camadas já é auto-suficiente, não precisa de um modelo “complementar”;
- Como você viu, muita gente não conhece, o que, pela prática empírica, leva a crer que é um conceito desnecessário.
[]´s
[quote=ceklock][quote=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?..[/quote]
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.
[/quote]@ingrid (e os caros colegas q ainda acompanham a thread)
Antes de qq coisa, gostaria de mencionar q “a minha praia” é + Java EE/Web (a pesar de eu ter 1 background “vindo do Delphi”).
Se vc tiver em mente a filosofia do MVC, então vou ter q discordar 1 pouco do colega ceklock, pois a “camada de apresentação” engloba toda a Aplicação Cliente (Front-End), por ex. numa App Web MVC: a View é definida p/ JSPs e o Control (atendimento das "action"s da request e navegabilidade pode ser facilitada por 1 framework WebFrontController; enfim, tanto a Visão, como o FrontController fazem parte da ‘Camada de Apresentação’ (se vc tiver em mente a filosofia MVC).
(Obs.: claro q o q eu falei “Aplicação Cliente” se aplica a sistemas c/ Estilo Arquitetural Distribuido: Client-Server “n” camadas, onde o Business-Core é “empacotado” em 1 Servidor de Aplicações, o qual poder “servir” a Aplicações Cliente de varios tipos diferente de Visão: GUI, RIA, MicroAparelhos, etc., etc., etc.)
O lance é q a maioria das ferramentas e APIs GUI utiliza o ‘Archtetural Pattern’ SMA (em vez do MVC). No SMA, a View e FrontController se concentram em 1 única camada. (A pesar de ser possível sim adotar e implementar MVC em Apps Desktop: SWING/AWT.)
Ah, ingrid, concordo plenamente c/ a afimação citada e acrescento q coisas, como “barras indicadoras de progresso”, tb podem ser implementadas em Apps RIA/AJAX/Web (e, convenhamos, isto é (bem) + fácil fazer em aplicações Desktop/GUI)!
[quote=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
=============================================================================[/quote]
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!
[quote=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)
[/quote]
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 …
[quote=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[/quote]
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
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
[quote=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?
[/quote]
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.
[quote=ingridfarabulini][quote=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[/quote]
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[/quote]
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
[quote=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?
[/quote]
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.
[quote=sergiotaborda][quote=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?
[/quote]
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.
[/quote]
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
.