• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Camadas
 

Camadas

on

  • 471 views

mvc não representa exatamente as camadas e sim a maneira como elas interagem.

mvc não representa exatamente as camadas e sim a maneira como elas interagem.

Statistics

Views

Total Views
471
Views on SlideShare
471
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Camadas Camadas Document Transcript

    • CAMADAS - Dizem como se agrupar os compoentes,,(objetos, classes etc). MVC - Diz como interagem as camadas. Em java nos separamos as Camadas da seguinte forma Apresentação Negocio Persistencia<br />No caso do struts e JSF por exemplo, o controller sao o ActionServlet e o FacesServlet respectivamente (alguns desenvolvedores consideram tambem como parte do controller os actions e os managed beans, outros nao. Confesso que isso nunca me tirou muito o sono). As paginas jsp, jsf, etc... sao o View e o resto é o Model.<br />Ja a separacao apresentacao - negocio - persistencia, é feita procurando isolar as regras de negocio das regras de apresentacao e das regras de acesso a banco. MVC é uma das formas de isolar a apresentacao das regras de negocio, assim como DAO é uma das formas de separar acesso a banco das regras de negocio. Perguntar se MVC e divisao em camadas sao a mesma coisa é como perguntar se DAO e divisao em camadas sao a mesma coisa. -------<br />A Arquitetura de Camadas é muito utilizada para separar responsabilidades em uma aplicação moderna. Apesar de a idéia da divisão de uma aplicação em Camadas ter se popularizado nos anos 90, muitos desenvolvedores ainda não conhecem a técnica a fundo, boa parte por documentação ineficiente sobre este Padrão Arquitetural.<br />Junto com a popularização da Arquitetura de Camadas, ressurgiu o modelo MVC de desenvolvimento. Este modelo foi criado em Smalltalk e traz simplicidade e coerência à interfaces.<br />Um problema com a popularização simultânea destes dois Padrões Arquiteturais é que estes passaram a ser eternamente confundidos. O objetivo deste breve artigo é mostrar como MVC e Camadas são conceitos diferentes, que podem ser aplicados em conjunto ou não.<br />Nota: O termo ‘componente’ é utilizado aqui para significar qualquer artefato de software. Pode ser substituído por classe, camada, objeto ou mesmo um componente no sentido dado por Component-Based Design (CBD).<br />CAMADAS: Separação Entre Componentes<br />MVC: Interação Entre Componentes<br />Camadas dizem como agrupar os componentes.<br />MVC diz como interagem os componentes.<br />Entity Beans representam os dados em uma base de dados (quase sempre relacional). A tecnologia de mapeamento entre objetos e tabelas (Mapeamento Objeto-Relacional) do framework EJB até a versão 2.1 era precária e basicamente você teria um Entity Bean por tabela no banco de dados. <br />Os Session Beans são os responsáveis por manipular os dados, sejam representados por Entity Beans ou não.<br />Model-view-controller (MVC) é um padrão de arquitetura de software que visa a separar a lógica de negócio da lógica de apresentação, permitindo o desenvolvimento, teste e manutenção isolado de ambos.<br />O modelo (model) é usado para definir e gerenciar o domínio da informação e notificar observadores sobre mudanças nos dados. Ele é uma representação detalhada da informação que a aplicação opera. A lógica de negócio adiciona valor semântico aos dados, e quando há mudança de estado o modelo notifica seus observadores. Por exemplo, aluno, professor e turma fazem parte do domínio de um sistema acadêmico. Operações como calcular a média final do aluno ou o índice de faltas da turma fazem parte da lógica de domínio. A forma como o dado é armazenado ou acessado não é de interesse do MVC, assume-se que é de responsabilidade do modelo.<br />A visão (view) apresenta o modelo num formato adequado ao utilizador, na saída de dados, e diferentes visões podem existir para um mesmo modelo, para diferentes propósitos.<br />O controlador (controller) recebe a entrada de dados e inicia a resposta ao utilizador ao invocar objetos do modelo, e por fim uma visão baseada na entrada. Ele também é responsável pela validação e filtragem da entrada de dados.<br />Um caso prático é uma aplicação web em que a visão é um documento HTML (ou derivado) gerado pela aplicação. O controlador recebe uma entrada GET ou POST após um estímulo do utilizador e decide como processá-la, invocando objetos do domínio para tratar a lógica de negócio, e por fim invocando uma visão para apresentar a saída.<br />Com o aumento da complexidade das aplicações desenvolvidas, torna-se relevante a separação entre os dados e a apresentação das aplicações. Desta forma, alterações feitas no layout não afetam a manipulação de dados, e estes poderão ser reorganizados sem alterar o layout.<br />Esse padrão resolve este problema através da separação das tarefas de acesso aos dados e lógica de negócio, lógica de apresentação e de interação com o utilizador, introduzindo um componente entre os dois, o controlador.<br />Um diagrama simples exemplificando a relação entre Model, View e Controller. As linhas sólidas indicam associação direta e as tracejadas indicam associação indireta.<br />Plataformas de desenvolvimento mvc<br />Java<br />Apache Struts<br />Struts é um framework de desenvolvimento da camada controladora, numa estrutura seguindo o padrão Model 2 (uma variante do MVC oficializada pela Sun), de aplicações web (principalmente) construído em Java para ser utilizado em um container web em um servidor J2EE[1].<br />JavaServer Faces<br />JavaServer Faces é um framework MVC para o desenvolvimento de aplicações Web, que permite o desenvolvimento de aplicações para a internet de forma visual, ou seja, arrastando e soltando os componentes na tela (JSP), definindo propriedades dos mesmos.<br />O JavaServer Faces teve sua expressão na versão 1.1 quando implementado pela comunidade utilizando a especificação 127 [1] do Java Community Process [2], evidenciando maturidade e segurança.<br />Hoje ele está na versão 1.2 da especificação 252 [3] do JCP. A fundação Apache vem realizando esforços na implementação da especificação através do projeto MyFaces. O reconhecimento do trabalho é visto por diversas empresas, tanto é que a Oracle doou os fontes do ADF Faces, conjunto de mais de 100 componentes JSF, para o projeto MyFaces que o denominará de Trinidad.<br />O JSF é atualmente considerado pela comunidade Java como a última palavra em termos de desenvolvimento de aplicações Web utilizando Java, resultado da experiência e maturidade adquiridas com o JSP/Servlet (Model1), Model2 (MVC) e Struts.<br />