Você está na página 1de 9

2.

457 seguidores

2.377

Log In / Cadastre-se

Desenvolvimento - Java

Abordando a arquitetura MVC, e Design Patterns: Observer, Composite, Strategy


por Adriano Jos Baptistella
6 3 0 Email 22 0

Publicidade

Resumo: Ao depararmos com um projeto podemos usufruir de abordagens sistemticas e disciplinadas, e encontramos na engenharia de software usando design patterns. Em busca de software de qualidade e segurana e em prazos cada vez menores, cada vez mais percebemos a suma importncia de utilizar design patterns, neste artigo abordamos a arquitetura MVC (Model, View, Controller) explicando-a com a ajuda de um conjunto de padres de projetos trabalhando juntos numa mesma estrutura, e sua participao para atender os mais variados requisitos na construo de projeto que possa ser escalvel e que possveis alteraes em quaisquer das camadas seja feita sem interferncia nas outras camadas, o MVC baseia-se na separao de dados (modelo), da interface com o usurio (view) e da lgica de negocio (controller), tambm descreveremos uma noo de anti-padres que por sua vez se parece com um padro de projeto que possui suas vantagem e desvantagens. Palavras chave: Design patterns, Padres de Projeto, Engenharia de Software, MVC (Modelo, Viso, Controle), Antipadres. 1. Introduo Em dcadas anteriores, um software era desenvolvido para rodar em uma nica mquina este aplicativo possua apenas uma camada, nestas aplicaes era gerada uma grande quantidade de cdigos fonte, os eventos dos usurios, lgica de negcios e os acessos dados estavam presentes nesta camada, dificultando e muito a programao e a manuteno deste software. Estas aplicaes receberam o nome de aplicao monoltica. A partir deste modelo, surgiu necessidade de criar outra camada especial para o acesso dados estas passaram a ser chamada de aplicaes em duas camadas, onde a camada de acesso a dados ficava em uma mquina especifica e o software era instalado do lado cliente contendo a lgica de negcio e a interface com o usurio. Logo aps surgiu a aplicao em n camadas, como o objetivo de separar a interface com o usurio, a lgica de negcios e o acesso ao banco de dados, possibilitando que vrios usurios interajam com o sistema sem ter necessidade de instal-las em suas maquinas, tornando o software mais flexvel, possibilitando que cada camada seja acessada e modificada individualmente sem ter que modificar outras partes do software. Inmeros problemas podem surgir na construo de sistemas que contiverem mistura de cdigo de acesso a dados junto com lgica de negcios e a apresentao, essas aplicaes so difceis de manter, pois qualquer alterao que se faa preciso ter cuidado para no afetar outras partes do sistema. Diante desse motivo surgiu na dcada de 70 segundo Gamma et al., uma arquitetura que foi desenvolvida para ser usada em projetos de interface visual na linguagem de programao Smalltalk, esta arquitetura recebeu o nome de MVC (Model, View, Controller), que um padro arquitetural, o MVC ajuda na tarefa de separar as responsabilidades promovendo um baixo acoplamento e alta coeso, tornando o sistema escalvel. Um ponto muito importante aqui no confundir o MVC com desenvolvimento em camadas, desenvolvimento em trs camadas uma arquitetura para software cliente-servidor e as camadas representam sistemas distintos fundamental que a camada de apresentao nunca acesse os dados
VER TODOS

easy .net mag 23

.net Magazine 97
VER TODAS ASSINE

Curso Refatorao com C# .NET Curso ASP.NET MVC Sistema de Vestibular Curso Visual Studio LightSwitch Curso Novidades Entity Framework 4.1 Curso ASP.NET Bsico com MySQL: Sistema de Concessionria Curso Conhecendo a Toolbox do Visual Studio 2010

diretamente, isto , deve passar pela camada intermediria ou pelas camadas intermedirias, pois pode haver n camadas. Projetos em multicamadas resolvem vrios problemas, mas tambm podem criar alguns outros, separar a interface do usurio, os dados da aplicao e a lgica de negcios tornam a aplicao como um todo mais fcil de ser compreendida, e permite que diferentes equipes trabalhem de forma paralela em diferentes componentes, mas, possui o seu lado negativo, pois, aumenta o processamento ou armazenamento em excesso, seja de tempo de computao, de memria, de largura de banda, ou qualquer outro recurso que seja requerido para ser utilizado, ou gasto para executar uma determinada tarefa, como consequncia pode prejudicar o desempenho do objeto que sofreu o overhead (processamento ou armazenamento em excesso)Obtido em "http://pt.wikipedia.org/wiki/Overhead" , porm, se voc no tomar certos cuidados com as regras da arquitetura acabar com um sistema mais lento e menos confivel que um sistema em duas camadas, ou uma aplicao monoltica. Ao iniciar um projeto, em uma maioria, os projetistas e desenvolvedores ficam preocupados com a interface, banco de dados e a linguagem de programao, e ignora a importncia que engenharia de software representa na construo de aplicaes, e no se importam em adotar um padro, ou de elaborar uma documentao de suas aplicaes. Descrevemos a arquitetura MVC, e os padres que so adotados em cada camada, retratando o benefcio de utilizar um padro arquitetnico, no planejamento e desenvolvimento de um software dinmico, bem como, o ganho com essa adoo, quanto organizao do projeto, e ao reuso de cdigos fonte, na facilidade de efetuar mudanas. 2. Engenharia de Software A engenharia de software uma disciplina da engenharia que se ocupa de todos os aspectos da produo de software [...] (SOMMERVILLE, 2003, p.5). Atualmente em nosso cotidiano percebemos algumas empresas de desenvolvimento de software entregando aos seus clientes softwares gigantescos, e de alta complexidade, e dessa maneira alguns sistemas apresentam fracas estruturas, deixando de atender as expectativas dos seus clientes, h ainda outros casos de empresas que atrasam a entrega do software tendo que renegociar os prazos pagando pelo no comprimento da entrega do produto, parte destas empresas desenvolvedoras de software no utiliza nenhum tipo de padres ou arquitetura no planejamento e execuo do software.
TOP 10 - ARTIGOS TOP 10 - AUTORES

ERROR: Forbidden

While trying to retrieve the URL http://www.facebook.com/plugins/likebox.php? href=http%3A%2F% 2Fwww.facebook.com% 2Flinhadecodigo&width=300&height=258&colors 23cccccc&stream=false&header=false&appId=26 Access Denied Your cache administrator is webmaster

1 2 3 4 5 6 7 8 9 10

Configurando o IIS para rodar php 5 Windows XP SP2 HTML Bsico JavaScript - Objetos e Propriedades Comandos bsicos em SQL - insert, update, delete e select Strings em C# - Coisas que nem todos sabem HTML Avanado Introduo a Design Patterns ASP.NET 2.0 - Herana visual com Master Page Tutorial Adobe Photoshop CS 2 Real Imagem P & B Materiais para TCC de Virtualizao Microsoft
VER TODOS

Figura 1.1

A evoluo do software. (PRESSMAN, 1995, p.5).

A Figura 1.1 representa a evoluo do software, que durante os primeiros anos de desenvolvimento, parte de hardware sofria inmeras mudanas, enquanto o software era visto por muitos como uma segunda opo, o desenvolvimento de software era feito sem administrao, e por conter poucos mtodos, os prazos de entregas eram curtos e na maioria das vezes se esgotavam com essas dificuldades o custo do software aumentava significativamente. Evoluo do software de acordo com PRESSMAN: 1950 1960: orientao em lote, distribuio limitada e software customizado. 1970 1980: multiusurio, tempo real, banco de dados e produtos de software. 1980 1990: sistemas distribudos, inteligncia embutida, hardware de baixo custo. 1990 2000: sistemas de desktop poderosos, tecnologias orientadas a objeto, sistemas especialistas, redes neurais e artificiais, computao paralela. (PRESSMAN, 1995, p.5). Atualmente em desenvolvimento de projetos principalmente projetos web, no temos dvidas sobre a vantagem que obtemos ao usarmos uma arquitetura ou padres que sejam orientados a objetos, as inmeras vantagens deste progresso j refletiram no barateamento de software e de hardware e na busca do software ideal, onde possamos diminuir as falhas e antecipar os fatores de risco de nossos projetos. 3. Padres de Projeto

A constante luta pela qualidade de software vem a anos construindo padres e tcnicas diferentes que auxiliam na construo de sistemas, mas que visam os mesmos objetivos: desenvolver software livre de defeitos, disponibilizarem uma manuteno mais fcil e organizada, um software livre de defeitos aquele que atendente exatamente com suas especificaes, mas no significa necessariamente que o software sempre se comportar como o esperado pelos usurios, razo talvez de algum engano do usurio referente m utilizao do software. muito difcil construirmos um software livre de defeitos, mas podemos utilizar tcnicas de engenharia de software que so fundamentais na organizao para construo de aplicaes, adotar padres de projeto ou arquitetura que so padres de alto nvel e so recomendados para grandes aplicaes e que nos permite reuso de cdigo fonte, e expansibilidade do software. Nas palavras de Metsker Um padro uma maneira de fazer algo, ou de buscar um objetivo. Tal idia se aplica a cozinhar fazer fogos de artifcio, desenvolver software e qualquer outro ofcio. (METSKER, 2004, p.17). Um padro pode ser aplicado em diversas reas para resolver os mais variados problemas que podemos encontrar em nossos ofcios. Christopher Alexander foi um dos primeiros escritores a encapsular as melhores prticas de um ofcio por meio da documentao de seus padres. Seus trabalhos esto relacionados arquitetura de edifcios, no de software. (METSKER, 2004, p.17). De acordo com Metsker, os padres de projetos comearam com Alexander, um professor de arquitetura em Berkeley, isso mesmo, Alexander um arquiteto, ele inventou os padres para construes reais como (casas, prdios, bairros e cidades). Seus relatos sobre padres tiveram influncia na comunidade de software, embora, o que Alexander relatava eram padres para construo, o que ele descreveu serve como base em relao a os padres de projetos orientados a objetos. Os padres de projetos no comearam com a GoF (Gang of Four) gangue dos quatro, segundo Metsker, foram eles que comearam com Christopher Alexander. A GoF refere-se ao primeiro catlogo sobre padres de projetos cuja formada pelos membros Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Aps a publicao deste livro, os padres de projetos tiveram um maior foco, expandiu-se o nmero de livros relatando padres e paradigmas de construo e desenvolvimento de software, mas, o livro de GoF um dos primeiros, e mais definitivo sobre padres de projetos. [...] Alexander deixa claro que seus padres o ajudam a servir e inspirar as pessoas que iro ocupar as devidas construes.(METSKER, 2004, p.18). Seguindo o mesmo pensamento de ChristopherAlexander, podemos comparar suas idias e relaciona-las quando projetamos um software, nele procuramos atingir um objetivo: que o software seja de suma importncia para nossos clientes, cumprindo com nossos prazos e objetivos para conseguir a aprovao em um nvel mais satisfatrio possvel. A comunidade de software fez ressoar a abordagem de Alexander e criou muitos livros que documentam padres de desenvolvimento de software. Estes livros registram as melhores praticas para processo de software, analise de software e projetos de alto nvel e no nvel de classe. Um padro de projeto um padro uma maneira de alcanar um objetivo o que utiliza classes e seus mtodos em uma linguagem orientada a objeto. (METSKER, 2004, p. 18). Os desenvolvedores em sua maior parte buscam solues para seus problemas, ao utilizar padres de projetos, ou aps ter conhecimentos em alguma linguagem de programao, ou ainda j terem programado por algum tempo. Antes disso, talvez observamos que cdigos de outros programadores parece mais funcional e mais simples, mas, que exijam um pouco mais de tempo para analisar, e voc se pergunta, como este cdigo deste desenvolvedor chegou a tal ponto de simplicidade e funcionalismo. Com o aumento da complexidade das aplicaes a serem desenvolvidas torna-se fundamental o uso de uma arquitetura, ou de padres de projetos, eles dependem freqentemente das caractersticas como polimorfismo e herana, o principio geral de padres de projeto que essa abordagem seja aplicada igualmente a todas as abordagens de projeto de software, de maneira que eles contribuam tal volvedor chegou aossosm nossos projetos para um bom andamento dos nossos projetos e que nos ajude a cumprir nossas metas. Abaixo abordaremos a arquitetura MVC que tende a cumprir com seus objetivos. 4. Arquitetura MVC A arquitetura MVC foi desenvolvida para ser usado em projetos de interface visual em Smalltalk, linguagem de programao que juntamente com o C++ganhou grande reconhecimento na poca, o MVC

foi criado na dcada de 70, e aps esses anos de sua criao ainda um pattern aplicvel nas mais variadas aplicaes, principalmente em aplicaes web. O gerenciamento da interface com o usurio uma tarefa difcil para os desenvolvedores, porm fundamental para o sucesso do sistema, alem da dificuldade, a complexidade na confirmao dos dados onde necessitamos apresentar ao usurio de forma correta e ainda gerenciar a aplicao para os usurios possam control-las apropriadamente, fundamental que as interfaces e o controlador estejam sincronizados. H uma maneira simples de entender o MVC uma vez que, o definimos como um padro de arquitetura, MVC o mesmo entendimento de um design pattern: primeiro entendemos o problema (que a motivao para o surgimento de um padro), e aps entender como este padro resolve este problemas, e quais as vantagens que ele nos oferece, mas com isso necessrio seguir a risca o MVC. Quando um software comea a ficar grande e complexo, muitos dados so apresentados para os usurios, sentimos a necessidade de aplicar uma arquitetura que facilite nosso trabalho, desde a organizao do projeto, as divises das responsabilidades at as possveis modificaes que podero ser efetuadas ao longo do desenvolvimento do software para isso precisaram dividir o projeto em trs objetos para aplicar o MVC. 4.1 Objetivos da Arquitetura Para a Gamma et al. o MVC : MVC composto por trs tipos de objetos. O modelo o objeto de aplicao, a vista a apresentao na tela e o controlador define a maneira como a interface do usurio reage s entradas do mesmo. Antes do MVC, os projetos de interface para o usurio tendiam em agrupar esses objetos. MVC para aumentar a flexibilidade e a reutilizao. (GAMMA et al. 2000, p. 20). O MVCtem como principal objetivo: separar dados ou lgicos de negcios (Model) da interface do usurio (View) e o fluxo da aplicao (Controller), a idia permitir que uma mensagem da lgica de negcios possa ser acessada e visualizada atravs de vrias interfaces. Na arquitetura MVC, lgica de negcios, ou seja, nosso Model no sabe quantas nem quais as interfaces com o usurio esta exibindo seu estado, a view no se importa de onde esta recebendo os dados, mas ela tem que garantir que sua aparncia reflita o estado do modelo, ou seja, sempre que os estados do modelo mudam, o modelo notifica as view para que as mesmas atualizem-se. 4.2 Caractersticas da Arquitetura Separao entre os cdigos, View e Controller que gerencia as relaes entre Model e a View. Separa a lgica de negcios da apresentao. Possui re-usabilidade, podemos criar bibliotecas e adicionar interfaces facilmente. possvel desenvolver-lo em paralelo, ou seja, pode comear o projeto por qualquer camada. Divide as responsabilidades, ou seja, programadores na programao e web designers na construo visual do software. Reduz o esforo na manuteno do software, pois as alteraes so efetuadas separadamente no afetando as outras camadas do sistema. 4.3 Arquitetura Como a arquitetura atua na infra-estrutura dos sistemas, como comunicaes, interfaces com usurios e compiladores. Agora abordaremos cada uma das camadas da arquitetura MVC, e o relacionamento com um browser em aplicaes web, com os objetos request e response, onde o request o pedido de uma informao ou evento, e o response a resposta deste pedido sada dos dados depois de efetuado o procedimento request. o

Figura 1.1Arquitetura MVC em aplicaes web.

MVC um conceito (paradigma) de desenvolvimento e design que tenta separar uma aplicao em trs partes distintas. Uma parte, a Model, esta relacionada ao trabalho atual que a aplicao administra outra parte a View esta relacionada a exibir os dados ou informaes dessa uma aplicao e a terceira parte, Controller, em coordenar os dois anteriores exibindo a interface correta ou executando algum trabalho que a aplicaoprecisa completar. (GONALVES, 2007, p. 141).

Model: ou modelo a camada que contm a lgica da aplicao, responsvel pelas regras de negcio, para sistemas persistentes, o modelo representa a informao (dados) dos formulrios e as regras SQL para manipular dados do banco, o modelo mantm o estado persistente do negcio e fornece ao controlador capacidade de acessar as funcionalidades da aplicao, o modelo o principal responsvel toda aplicao deve representar o modelo atua isoladamente no tem conhecimento de quais sero a ou as interfaces que ter de atualizar, o modelo somente acessa base de dados e deixa os dados prontos para o controlador este por sua vez encaminha para a viso correta.

View:ou viso a camada de apresentao com usurio, a interface que proporcionar entrada de dados e a visualizao de respostas geradas, nas aplicaes web representado pelo HTML que mostrado pelo browser, geralmente a viso contm formulrios, tabelas, menus e botes para entrada e sada de dados. A viso deve garantir que sua apresentao reflita o estado do modelo, quando os dados do modelo mudam, o modelo notifica as vistas que dependem dele, cada vista tem a chance de atualizar-se. Desta maneira permite ligar muitas vistas a um modelo podendo fornecer diferentes apresentaes, essa camada no contm cdigos relacionados lgica de negcios, ou seja, todo o processamento feito pelo Modelo e este repassa para a viso, evidenciaremos abaixo um exemplo de duas vistas atuando sobre o mesmo modelo.

Figura 2.1 Duas View atuando em um mesmo modelo, Model: a=100, b=90, c=80.

Controller:j descrevemos da view e do modelo, mas, temos de concordar que tudo isso se tornaria uma baguna se tivesse algum para organizar esta arquitetura, um controlador funciona de intermedirio entre a camada de apresentao e a camada de negcios, sua funo como j diz controlar coordenar o envio de requisies feitas entre a viso e o modelo. O controller define o comportamento da aplicao, o controle quem interpreta as solicitaes (cliques, selees de menus) feitas por usurios com bases nestes requerimentos o controlador comunica-se com o modelo que seleciona a view e atualiza-a para o usurio, ou seja, o controlador controla e mapeia as aes. Embora o MVC s contenha trs camadas h outra camada fundamental para o bom andamento da arquitetura, esta um mecanismo de eventos necessrio a comunicao entre outros trs elementos, este elemento permite uma comunicao assncrona que invocada quando algum evento interessante acontece, esta quarta camada contm os beans de entidade onde se localizam os mtodos get e set das classes. 5. Design Patterns aplicados na arquitetura MVC A arquitetura MVC utiliza padres de projetos em suas camadas analisamos a arquitetura agora com os patterns. O MVC usa outros padres de projeto, tais como Factory Method, para especificar por falta (by default) a classe controladora para uma vista e Decarator, para acrescentar capacidade de rolagem (scrolling) a uma vista. Mais os principais relacionamentos do MVC so fornecidos pelos padres Observer, Composite, Strategy. (GAMMA et al. , 2000, p. 22) Os designs patterns nos ajuda explicar a arquitetura MVC, e com eles podemos perceber que por traz do MVC pode conter um conjunto de padres trabalhando juntos em uma mesma estrutura. Abordamos agora os patterns Observer e Strategy que so padres comportamentais e o Composite padro estrutural, o objetivo de abordar os patterns para facilitar a compreenso de como a arquitetura MVC trabalha, sabendo que um padro de arquitetural que confundem projetistas e desenvolvedores. Nas palavras de Gamma et al. os principais padres que oMVC utiliza so os Observer, Composite e o Strategy. Analisemos a Figura 3 do livro de Padres de Projetos dos autores Freeman & Freeman que nos ajudar a explicar como os padres contribuem na arquitetura MVC: A visualizao ou a View juntamente com o padro Compositeest disposio do usurio esperando por qualquer evento, quando este evento ativado o controlador avisado sobre o evento, este avisa para a viso se atualizar, e ao mesmo tempo manda o modelo para que ele atue para contemplar o evento provocado pelo usurio, depois de atuado o modelo fica pronto para ser acessada pela visualizao esta por sua vez acessa e atualiza-se para o usurio assim funciona a arquitetura MVC em conjunto com os padres de projetos.

Figura 3 (FREEMAN& FREEMAN, p. 424). 5.1 Padres Estruturais Composite na camada da View. Em aplicaes grficas como na interface com o usurio temos um conjunto de componentes aplicados, como botes, menus e caixa de textos. Os padres estruturais se preocupam com a forma como as classes e objetos so compostos para formar estruturas maiores. [...] o Composite um exemplo de padro estrutural de objetos. Ele descreve como construir uma hierarquia de classe composta para dois tipos de objetos: primitivos e compostos. (GAMMA et al., 2000, p.139).

O padro Composite um padro estrutural so usados na camada de viso os componentes das telas so compostos. [...] Quando o controlador determina visualizao que atualize a tela, esta tem de transmitir a ordem ao componente mais alto do nvel, porque o padro Composite cuida do restante. (FREEMAN & FREEMAN, 2007, p. 424). A visualizao composta por vrios componentes, componentes de nvel mais alto contm outros componentes, que contem outros at chegarem aos ns folhas, portando quando a informao do controller chega a view manda a ordem para o componente de maior nvel.

5.2 Padres Comportamentais: Observer na camada da Model, e Strategy na camada do Controller.

5.2.1 Padro Observer O Model por sua vez pode fazer o uso do padro Observer que separa a viso do estado de um objeto do prprio objeto, permitindo que sejam fornecidas vises alternativas mantendo os objetos interessados constantemente informados sobre suas mudanas de estado. Esse padro pode ser utilizado em todas as situaes em que mais de um formato de display para informaes de estado pode ser requerido e em que no seja necessrio para o objeto que mantm as informaes de estado saber sobre os especficos formatos de displays utilizados. (SOMMERVILLE, 2003, p.273). O uso do padro Observer mantm o modelo totalmente independente das visualizaes e controladores, o que nos permite utilizar mltiplas visualizaes mesmo tempo como, por exemplo, graficamente ou como texto partindo do mesmo modelo.

5.2.2 Padro Strategy O Controller por sua vez adota o padro Strategy segundoFreeman & Freeman A visualizao e o controlador utilizam uma estratgia que fornecida pelo controlador. A visualizao s precisa se preocupar com os aspectos visuais do aplicativo, porque todas as decises sobre o comportamento da interface so delegadas ao controlador, o uso deste padro mantm a visualizao desconectada do modelo, porque a responsabilidade pela iterao com o modelo por executar as solicitaes do usurio cabe apenas ao controlador, a visualizao no tem a mnima idia de como isto feito. (FREEMAN & FREEMAN, 2007, p. 424). o controller que organiza o MVCpor meio de mtodos, todas as decises, estratgias e eventos que podem ser usados pelo usurio definido nele, a interface s preocupasse em mostrar os dados ao usurio, e reagir segundo as suas programaes. Utilize padres de projeto quando tiver absoluta certeza que ele resolver seu problema, distinguir onde aplic-los uma conseqncia de sua experincia e conhecimento, podemos afirmar que a falta de experincia e conhecimento seja o motivo de outro tpico, os anti-padres. 6. Anti-Patterns(Anti-Padres) Aps a publicao do livro da GoFSolues Reutilizveis de Software Orientado a Objeto iniciaram -se um aumento do nmero de publicaes, seminrios e outras atividades que referenciava a utilizaes de padres de projetos, muitas pessoas aderiram ao uso de padres e o uso de padres por desenvolvedores e arquitetos de software comeou a crescer, por sua vez, passaram a surgir de forma naturalmente os anti-padres do ingls anti-Patterns. Um Anti-Padro lhe informa como ir de um problema at uma soluo ruim. (FREEMAN & FREEMAN, 2007, p. 478). Suponha-se que os anti-padres podem ter como origem a falta de experincia ou de conhecimento de um profissional de desenvolvimento de software que na tentativa de solucionar um problema ou na aplicao de um padro encontro uma forma errada, ou seja, partiu de um problema at uma soluo

ruim. Mas quem iria de um problema a uma soluo ruim, o anti-padro mostra que uma soluo ruim pode ser atraente, ningum esc olheria uma soluo ruim se no se ouve algo luc rativo nela. Um anti-padro indic que por essa soluo ruim longo prazo. Para entender um anti-padro, a voc c ompreender c omo ele exerc um efeito negativo ao longo do tempo. O anti-padro desc er reve onde o uso da soluo devera lhe c ausar problemas. (FREEMAN& FREEMAN, 2007, p. 479). Assim c omo os padres, os anti-padres tambm possuem um nome para que possamos nos referenc iar a eles em um voc abulrio c ompartilhado. Exemplo de um anti-padro: Nome: Vidro Quebrado Problema: voc prec ir ao trabalho de c isa arro, voc esquec a c eu have dentro do c arro e o c arro enc ontra-se c haveado. Como fao para no me atrasar para o trabalho? Contexto: tranquei as c haves dentro do c arro. Soluo: quebrar a janela entre no c arro ligue-o e dirija para o trabalho. Temos aqui os c omponentes, o problema que o objetivo a ser alc anado, tem o c ontexto que a c have que esta dentro do c arro esta inac essvel e a soluo ruim quebrar a janela para no se atrasar no trabalho. Pois bem este um exemplo de anti-padro, pois voc parte de um c ontexto (tranc a c ar have no c arro) e c hega a uma soluo por hora boa que alc anou o seu objetivo que era no se atrasar para o trabalho, mas existe um problema se todo dia voc quebrar a janela do c arro para alc anar o objetivo ter um enorme prejuzo o c usto da janela. Partimos de um problema para uma soluo ruim (quebrar a janela). 7. Consideraes Finais No dec orrer das ultimas quatro dc adas o software evoluiu de uma ferramenta de anlise e de informao para uma indstria em si, no entanto esta indstria evoluiu juntamente c os problemas que om persistem at hoje, mas, destes problemas boa parte resolvemos aplic ando padres e planejando-o de ac ordo c a nec om essidade nossas aplic aes. Este artigo dedic ou-se no estudo de um dos modelos mais usadas no desenvolvimento de aplic aes para web, o MVC apesar de ser de uma longa data se mostra presente em vrios frameworks e linguagem, podemos c luir que a arquitetura MVC oferec aos onc e projetistas e desenvolvedores uma c lara separao entre os elementos, c o intuito de dividir as om func ionalidades de um sistema em c amadas, separando as responsabilidades da equipe desenvolvedora, reutilizando c digos fontes, fac ilitando a manuteno do sistema, pois possumos esc alabilidade, a arquitetura MVC mostra-se fundamental nas aplic aes, seja ela web ou desktop. Use padres quando houver uma nec essidade para aplic padres de projeto, e quando houver algo ar mais simples fique c esta opo c om aso o c ontrrio ele aumentar a c omplexidade do sistema, mas, se houver uma razo prtic e que seu aplic a ativo nec essitar de mudanas v em frente e usufrua deste rec urso. Referncias METSKER, Steven John. Padres de projeto em Java. Porto Alegre: Bookman, 2004. GAMMA, Eric et al. Padres de Projeto: Solues reutilizveis de software Orientado a Objetos. Porto h Alegre: Bookman, 2000. SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Addison Wesley, 2003. FREEMAN & FREEMAN, Eric& Elizabeth. Padres de Projetos: Seu c rebro em padres de projetos. Rio de Janeiro: ALTABOOKS, 2007. PRESSMAN, Roger S. Engenharia de Software. So Paulo: Pearson Educ ation do Brasil, 1995. GONALVES, Edson. Desenvolvendo aplicaes web com JSP, Servlet, Java Server Faces, Hibernate, EJB3 persistence, jax.Rio de Janeiro: Cinc Moderna, 2007. ia

Adriano Jos Baptistella - Ac admic de Sistemas de Informao - UNIPAR o Campus Franc o Beltro. isc

Email

22

Leia tambm
Voc pode ganhar um iPad 2 de 16GB na promoo do Frum Javafree! Confira!
Java

Voc pode ganhar um iPad 2 de 16GB na promoo do Frum Javafree! Confira!


Java

Serializao Soluo Para Persistncia de Objetos


Java

Programao a Objetos - Nvel Zero


Modelagem

Bubble Sort com Java


Java

Comentrios
Curtir Login

Adicionar novo comentrio


Digite seu comentrio aqui.

Mostrando 0 comentrios
M Notificar por e-mail S RSS

Ordenar por: populares

URL de Trackback
blog comments powered by DISQUS

Estamos aqui: Linha de Cdigo faz parte do grupo Web-03

Poltica de privacidade e de uso | Anuncie | Cadastre-se | Fale conosco

2012 Linha de Cdigo. Todos os direitos reservados