Analisando arquiteturas client-side com AngularJS
Esse artigo visa exibir uma visão simplificada de como os desenvolvedores e projetistas de sistemas podem lidar com as arquiteturas dos mesmos, trazendo ideias que inovam a forma de pensar sobre as tecnologias client side.
Este artigo tem como objetivo identificar os padrões de projeto e as características de uma arquitetura para aplicações web client-side, para então propor um modelo de arquitetura utilizando o framework AngularJS, de forma que atenda aos requisitos arquiteturais de uma aplicação exemplo.
Na prática, demonstraremos um conjunto de técnicas para implementar uma arquitetura executável e reutilizável, exemplificando a estrutura do projeto, padrões utilizados, ferramentas e código-fonte, bem como os demais atores envolvidos no ciclo de vida do software de uma forma geral.
O desenvolvimento de uma arquitetura client-side, traz consigo desafios arquiteturais equivalentes ao modelo tradicional implementado no lado servidor. Então como podemos modelar e implementar uma arquitetura no lado cliente capaz de atender aos requisitos arquiteturais de software de um determinado domínio?
Para o propósito deste artigo, foi selecionado o domínio de uma rede social para realizar a implementação baseada nos requisitos da arquitetura que serão descritos empregando o modelo FURPS, um acrônimo que representa um modelo de classificação de atributos de qualidade de software (requisitos funcionais e não funcionais), e que classifica os requisitos arquiteturais por funcionalidade, usabilidade, confiabilidade, desempenho e suportabilidade.
Neste contexto, a escolha do framework AngularJS foi realizada devido a sua popularidade e ao fato de suas características serem compatíveis com uma arquitetura robusta que possibilita a separação em camadas, assim como outras características importantes como a injeção de dependências.
Arquitetura de Software
Segundo Martin Fowler, a arquitetura de software é um termo com muitas definições, porém sem um consenso entre os autores. No entanto, ele afirma que sempre existem dois elementos em comum, o primeiro é o desmembramento do sistema em partes e o segundo são as decisões difíceis de mudar.
A arquitetura de software de um programa ou sistema computacional é composta pelas estruturas do sistema, que, por sua vez, são compostas por elementos de software, suas propriedades visíveis externamente e as relações entre elas. As formas arquiteturais recorrentes, depois de observadas e analisadas, podem gerar modelos padronizados, que podem ser utilizados mesmo em sistemas diferentes na forma dos chamados “estilos arquiteturais”, modelos de representação de arquitetura.
O estilo arquitetural mais utilizado em aplicações complexas é o estilo em camadas, também conhecido como layers, no qual ele define como um conjunto de subsistemas do software organizados em forma de bolo, onde cada camada é acomodada sobre a camada inferior.
Nesta estrutura a maior camada utiliza os serviços das camadas inferiores, mas as camadas inferiores não conhecem as camadas superiores e por isso não acessam os seus serviços. Entre os benefícios disso, podemos citar: coesão; separação de responsabilidades; redução de dependências; possibilidade de substituição da implementação.
Padrões de Projeto
O software é frequentemente lembrado pelas suas partes como as funções, arquivos fonte, módulos, objetos, métodos, classes, pacotes, bibliotecas, componentes, serviços, subsistemas e assim por diante.
Tudo isto representa visões corretas nas quais os desenvolvedores trabalham. Porém esta visão é focada nas partes, que por sua vez não contemplam a grande quantidade de relacionamentos e decisões que estão por trás do software.
Os padrões de projeto, também conhecidos como design patterns, surgem para descrever, capturar e nomear técnicas para solução de problemas de software. Diferentemente da utilização de experiência de forma empírica, os padrões são documentados, reutilizados em outras aplicações e compartilhados para disseminação do conhecimento.
Os principais padrões de projetos que serão empregados neste artigo estão descritos a seguir.
Dependency Injection
O padrão DI (Dependency Injection) é uma prática onde os objetos são desenhados de uma maneira na qual recebem instâncias de objetos de outras partes do código, ao invés de construí-los internamente.
Isto significa que qualquer implementação da interface que é utilizada pelo objeto pode ser substituída sem alterar o código, resultando na simplificação dos testes e na diminuição do acoplamento.
Service Oriented Architecture
O padrão SOA (Service Oriented Architecture) consiste em uma coleção de componentes distribuídos que fornecem e/ou consomem serviços. Neste padrão, os componentes dos fornecedores e dos consumidores de serviços podem utilizar diferentes plataformas e linguagens de programação.
Serviços são em sua grande maioria independentes e frequentemente pertencem a diferentes sistemas ou até mesmo diferentes organizações.
RESTful Web Services
O REST (Representational State Transfer) é um estilo arquitetural para aplicações em rede proposto por Roy Fielding em 2000. Ele consiste em um conjunto de restrições para tratar a separação de responsabilidades, visibilidade, confiabilidade, escalabilidade, desempenho, etc.
O grande diferencial do REST é a utilização da infraestrutura da web, como por exemplo, o protocolo HTTP, que permite construir aplicações distribuídas e publicar serviços nesta infraestrutura.
Pode ser denominado RESTful Web Services, os serviços web construídos utilizando as tecnologias HTTP, URI, XML e JSON que são padronizadas para utilização na web.
Active Record
O Active Record"
[...] continue lendo...Artigos relacionados
-
Artigo
-
Artigo
-
Artigo
-
Artigo
-
Artigo