Artigo no estilo: Curso

Por que eu devo ler este artigo:Este artigo é útil para desenvolvedores que precisam aprender o funcionamento e como implementar uma aplicação distribuída através do uso dos recursos da plataforma .NET.

A mesma fornece as tecnologias necessárias para o desenvolvimento de sistemas distribuídos com uso de web services baseado em REST, aplicações desktop, tecnologias para web sites e aplicações para mobilidade.

Este artigo será dividido em três partes. Será desenvolvida uma aplicação distribuída completa para força de vendas. Nesta primeira parte do artigo focaremos na estrutura de web services com base no REST.

O serviço irá expor uma interface comum para todas as entidades envolvidas seguindo as funcionalidades e operações CRUD para o SGDB SQL Server 2014. Será criado um cadastro de clientes, produtos e pedidos, sendo que a implementação será feita diretamente com a ASP.NET Web API.

Desenvolver sistemas distribuídos não é uma tarefa fácil, principalmente na hora de escolher qual tecnologia usar para realizar a integração entre aplicações diversas que estarão rodando em plataformas distintas.

Até pouco tempo atrás os Web Services baseados em SOAP eram a melhor forma para estabelecer comunicação entre aplicações, porém existe uma série de fatos que tornaram esta implementação complexa e com custo bastante elevado, devido às características que o SOAP foi ganhando com o passar dos tempos.

Boa parte dos fornecedores de tecnologias para desenvolvimento de aplicações não conseguiam acompanhar a evolução do SOAP, desta forma era preciso escolher com bastante calma e atenção quais soluções e tecnologias utilizar para integrar sistemas distribuídos utilizando como meio de comunicação padrão o SOAP.

O SOAP ainda está presente na maior parte das soluções para sistemas distribuídos. O fator que auxilia este número é a segurança, pois este protocolo proporciona um excelente nível de segurança para troca de informações entre aplicações.

Outro ponto a destacar sobre os sistemas distribuídos é o novo meio de troca de dados entre aplicações rodando em qualquer plataforma. O REST é o novo padrão arquitetural que proporciona a troca de dados entre qualquer aplicação que faça uso do protocolo HTTP, ou seja, o REST tem como base a estrutura do protocolo HTTP para enviar e receber dados entre o servidor e uma aplicação cliente.

Esta nova forma de implementação de Web Service vem se consolidando no mercado e existem vários fatores que levam o REST a ser hoje umas das melhores alternativas para solução de troca de dados entre sistemas distribuídos. Veja a seguir algumas características do REST.

· O primeiro ponto a destacar sobre o sucesso do REST é o fato do mesmo ter como base para comunicação o protocolo HTTP, desta forma qualquer aplicação com acesso à internet pode estabelecer comunicação com um Web Service implementado seguindo o esse padrão arquitetural.

· A implementação do REST é bem simplificada, ou seja, tanto no lado do servidor como também do lado da aplicação cliente. Isso se deve ao fato do REST usar alguns verbos do HTTP: GET, POST, PUT e DELETE. Podemos até fazer uma breve comparação com as operações de transações em um banco de dados, o famoso CRUD, acrônimo de CREATE, READ, UPDATE e DELETE.

· Por fim, mas não parando por aí, o REST possibilita a troca de dados em vários formatos, os mais utilizados são o JSON e XML.

Após esta breve introdução sobre sistemas distribuídos agora podemos entender e conhecer um pouco sobre a plataforma .NET e o que a mesma oferece como solução para esta estrutura. A Microsoft vem atualizando a plataforma .NET de acordo como os novos padrões que vão surgindo.

Se tratando de web service a plataforma .NET até certo tempo atrás tinha como principal uma tecnologia denominada WCF (Windows Comunication Foundation), que incorporava várias formas de comunicação para sistemas distribuídos e também o uso de web services ASMX.

Estas tecnologias utilizam como base para comunicação o protocolo SOAP, então com o surgimento do REST a Microsoft inovou e criou uma nova tecnologia que implementa esse padrão, a ASP.NET Web API.

Porém esta tecnologia não para por aí, ou seja, a mesma tem como base o ASP.NET MVC, então toda a implementação de web services com base na Web API segue o padrão MVC.

A Web API é parte do framework ASP.NET MVC, desta forma você pode utilizar toda a estrutura de um website ASP.NET MVC na Web API e vice-versa. A Web API pode ser hospedada em um servidor IIS normalmente como um site com ASP.NET MVC, pois sua implementação tem como base o REST e protocolo HTTP.

Criando o DER do projeto para o banco de dados

Como iremos criar uma aplicação distribuída, é interessante ter o máximo de documentação possível sobre o software a ser desenvolvido.

A documentação serve para consulta pela equipe de desenvolvimento, sendo que uma software house com processos bem definidos pode ter equipes especializadas em determinada tecnologia e plataforma.

Pensando neste cenário, iremos criar um DER (Diagrama Entidade Relacionamento) que representa a estrutura de tabelas do banco de dados de nossa aplicação referente às entidades do mundo real que fazem parte do levantamento de requisitos funcionais do software a ser desenvolvido.

Para evitar o acoplamento do DER a um determinado SGDB, iremos utilizar uma ferramenta free denominada DBDesigner que gera script SQL para vários SGDBs, como o SQL Server, MySQL, Oracle, PostgreSQL, Firebird, SQLite, dentre outros. Você pode baixar o DBDesigner no link presente na seção Links deste artigo.

O banco de dados da aplicação terá quatro tabelas: cliente, produto, cabeçalho do pedido e itens do pedido. O DER do banco de dados com todas as tabelas necessárias para o sistema força de vendas pode ser visualizado na Figura 1, a mesma apresenta as tabelas juntamente aos relacionamentos necessários entre elas.

Integrando aplicações com Web API

Figura 1. DER (Diagrama Entidade Relacionamento) do banco de dados

Analisando esse DER, o mesmo merece algumas observações a serem destacadas, conforme a seguir.

· Tabela cliente: os campos da tabela cliente são auto descritivos, porém perceba que a coluna cpf_cnpj é do tipo varchar, pois se utilizássemos um int não caberia o dado e nem poderíamos armazenar valores iniciados em zero.

Com uso do varchar é possível até mesmo gravar no campo os números do CPF ou CNPJ com máscara, apesar de essa não ser uma boa prática, já que existem componentes que fazem o trabalho de adicionar máscaras em campos.

· Tabela produto: na tabela produto também não existem segredos, porém temos um problema: o campo preço de compra não pode ser apresentado no dispositivo móvel com Windows Phone, pois o vendedor não pode saber este preço.

Assim sendo, temos duas soluções: ocultar este campo na implementação mobile, ou criar um DTO exclusivo para consumo do serviço pela aplicação mobile. Em nosso cenário o melhor e menos dispendioso seria fazer isso no lado mobile, que é o que faremos.

· Tabela pedido cabeçalho: a ideia desta tabela é armazenar as informações sobre o pedido como um todo, ou seja, qual cliente, valor total da venda, quantidade de itens, data da venda e status (que pode ser Finalizada, Cancelada, dentre outros status possíveis).

· Tabela itens pedido: esta tabela também é auto descritiva, porém é importante notar as chaves estrangeiras que representam os relacionamentos com as tabelas produto e pedido cabeçalho.

Com DER do banco de dados pronto, agora é hora de criar o banco propriamente dito. Iremos utilizar o SGDB SQL Server 2014 Express e Management Studio 2014 para obter uma interface para administração do SQL Server.

Abra o Management Studio 2014 e crie um novo banco de dados chamado de “BD_FORCA_VENDA”, logo após é necessário obter o script SQL para criar as tabelas. Abra o DBDesigner e vá até menu File> Export> SQL Create Script. Na sequência irá abrir uma nova janela conforme mostra a Figura 2, nela selecione SQL Server em Target Data Base e depois clique no botão Copy Script to Clipboard para copiar para memória o script SQL para gerar as tabelas.

Realizado este procedimento, volte ao Management Studio, abra uma nova query para o banco BD_FORCA_VENDA recém-criado e cole o script SQL (presente na Listagem 1).

Execute o script e terá uma estrutura conforme apresentado na Figura 3, com todas as tabelas definidas no DER do banco de dados.

Integrando aplicações com Web API

Figura 2. Exportando script SQL com DBDesigner para banco BD_FORCA_VENDA.

Listagem 1. Script SQL para gerar tabelas do banco de dados BD_FORCA_VENDA.

  01 CREATE TABLE produto (
  02  idproduto INTEGER  NOT NULL   IDENTITY ,
  03  descricao VARCHAR(100)    ,
  04  preco_compra DECIMAL(6,2)    ,
  05  preco_venda DECIMAL(6,2)    ,
  06  qtde_estoque INTEGER    ,
  07  data_cadastro DATE    ,
  08  status_produto VARCHAR(20)      ,
  09 PRIMARY KEY(idproduto));
  10 GO
  11
  12 CREATE TABLE cliente (
  13  idcliente INTEGER  NOT NULL   IDENTITY ,
  14  nome VARCHAR(100)    ,
  15  cpf_cnpj VARCHAR(18)    ,
  16  endereco VARCHAR(200)    ,
  17  bairro VARCHAR(40)    ,
  18  cidade VARCHAR(40)    ,
  19  cep VARCHAR(10)    ,
  20  email VARCHAR(50)    ,
  21  telefone VARCHAR(15)    ,
  22  status_cliente VARCHAR(20)    ,
  23  data_cadastro DATE      ,
  24 PRIMARY KEY(idcliente));
  25 GO
  26
  27 CREATE TABLE pedido_cabecalho (
  28  idpedido_cabecalho INTEGER  NOT NULL   IDENTITY ,
  29  idcliente INTEGER  NOT NULL  ,
  30  valor_total_pedido DECIMAL(6,2)    ,
  31  qtde_itens INTEGER    ,
  32  status_pedido VARCHAR(20)    ,
  33  data_pedido DATE      ,
  34 PRIMARY KEY(idpedido_cabecalho)  ,
  35  FOREIGN KEY(idcliente)
  36    REFERENCES cliente(idcliente));
  37 GO
  38
  39 CREATE INDEX pedido_cabecalho_FKIndex1 ON pedido_cabecalho (idcliente);
  40 GO
  41
  42 CREATE INDEX IFK_Rel_Cliente__Ped_Cab ON pedido_cabecalho (idcliente);
  43 GO
  44
  45 CREATE TABLE pedido_itens (
  46  idpedido_itens INTEGER  NOT NULL   IDENTITY ,
  47  idpedido_cabecalho INTEGER  NOT NULL  ,
  48  idproduto INTEGER  NOT NULL  ,
  49  quantidade INTEGER    ,
  50  valor_unitario DECIMAL(6,2)    ,
  51  sub_total DECIMAL(6,2)    ,
  52  status_item VARCHAR(20)      ,
  53 PRIMARY KEY(idpedido_itens)    ,
  54  FOREIGN KEY(idpedido_cabecalho)
  55    REFERENCES pedido_cabecalho(idpedido_cabecalho),
  56  FOREIGN KEY(idproduto)
  57    REFERENCES produto(idproduto));
  58 GO
  59 
  60 CREATE INDEX pedido_itens_FKIndex1 ON pedido_itens (idpedido_cabecalho);
  61 GO
  62 CREATE INDEX pedido_itens_FKIndex2 ON pedido_itens (idproduto);
  63 GO
  64
  65 CREATE INDEX IFK_Rel_PedCab__Ped_Itens ON pedido_itens (idpedido_cabecalho);
  66 GO
  67 CREATE INDEX IFK_Rel_Produto__Ped_Itens ON pedido_itens (idproduto);
  68 GO

Integrando aplicações com Web API

Figura 3. Estrutura do banco de dados BD_FORCA_VENDA com as tabelas criadas.

Com isso, o banco de dados da aplicação já está pronto para receber os dados.

Criando o projeto ASP.NET Web API com Visual Studio

O primeiro projeto a ser desenvolvido será a Web API que funcionará como centro do sistema, pois tanto a aplicação ASP.NET MVC quanto a do Windows Phone irão consumir dados a partir deste serviço.

Abra o Visual Studio 2013 e a partir do menu File> New> Project escolha, dentro da categoria Web, o template ASP.NET Web Application. Selecione a versão do .NET Framework (aqui será usada a 4.5.1) e nomeie o projeto como ForcaVendasWebAPI.

Em seguida clique em OK. Depois disso será aberta outra janela onde você deverá selecionar o template Web API e pressionar OK novamente para que o Visual Studio possa criar toda a estrutura de arquivos e pastas do projeto para Web API utilizando o padrão MVC.

Após o projeto ser criado pelo Visual Studio, teremos a estrutura do projeto “ForcaVendaWebAPI” conforme apresentado na Figura 4. Aparentemente parece um projeto ASP.NET MVC comum, mas não se engane, pois este projeto já vem com um serviço Web API configurado e pronto para ser executado.

Você pode ver esta implementação no arquivo ValuesController.cs, que se encontra dentro da pasta Controllers. Veja a Listagem 2 que mostra a implementação de um serviço Web API seguindo o padrão REST.

Listagem 2. Implementação serviço Web API exemplo ValuesController.cs

  01 using System;
  02 using System.Collections.Generic;
  03 using System.Linq;
  04 using System.Net;
  05 using System.Net.Http;
  06 using System.Web.Http;
  07 
  08 namespace ForcaVendaWebAPI.Controllers
  09 {
  10    [Authorize]
  11    public class ValuesController : ApiController
  12    {
  13        // GET api/values
  14        public IEnumerable<string> Get()
  15        {
  16            return new string[] { "value1", "value2" };
  17        }
  18
  19        // GET api/values/5
  20        public string Get(int id)
  21        {
  22            return "value";
  23        }
  24
  25        // POST api/values
  26        public void Post([FromBody]string value)
  27        {
  28        }
  29
  30        // PUT api/values/5
  31        public void Put(int id, [FromBody]string value)
  32        {
  33        }
  34
  35        // DELETE api/values/5
  36        public void Delete(int id)
  37        {
  38        }
  39    }
  40 }

Esta listagem merece alguns comentários para que você possa entender como trabalhar com a Web API seguindo o padrão arquitetural REST, que por sua vez tem como base de comunicação o protocolo HTTP. Veja a seguir mais detalhes sobre a codificação.

· Linha 11: o primeiro ponto a destacar é o controller Values que herda de ApiController.

Em uma aplicação ASP.NET MVC o controller herda da classe Controller, então para que possamos implementar a Web API é necessário herdar da classe ApiController que já tem encapsulado todos os recursos necessários referentes à implementação de serviços com base no REST.

· Linhas 14, 20, 26, 30 e 35: nestas linhas estão implementados os métodos que expõem ao cliente a interface de comunicação através da definição de rotas, ou seja, o endereço que aponta para algum recurso no servidor. Perceba que cada método faz referência a um verbo do protocolo HTTP, sendo: Get para solicitar uma representação de um recurso no servidor; Post para criar um no recurso; Put para alterar um recurso existente; e Delete para excluir um determinado recurso no servidor.

É muito importante você fazer uma associação com as operações de CRUD, pois o objetivo deste projeto com uso da Web API é fornecer uma interface comum para os outros dois projetos.

Os projetos que irão consumir o serviço serão criados nas próximas partes deste artigo.

Integrando aplicações com Web API

Figura 4. Solution Explorer com a estrutura de pasta e arquivos do projeto.

Integrando o Entity Framework ao projeto

Para realizar a conexão entre o serviço com a Web API e banco de dados SQL Server iremos utilizar o ORM Entity Framework que é nativo da plataforma .NET. O mesmo é responsável por realizar o mapeamento objeto-relacional entre as tabelas do banco de dados e as classes model da aplicação.

Também é possível optar para que o Entity crie todas as classes para o modelo de dados. Seguindo este contexto o BDA pode realizar atualizações na estrutura do schema do banco de dados e a partir da aplicação Web API podemos facilmente atualizar o modelo na aplicação através do EDMX do Entity framework.

Para adicionar o Entity Framework ao projeto você deve selecionar a pasta Models no Solution Explorer. A mesma faz parte da estrutura do padrão MVC. Com a pastas Models selecionada, clique nela com botão direito e depois na opção Add> New item. Abrirá uma nova janela onde deverá ser selecionada a categoria Data e o template ADO.NET Entity Data Model (Entity Framework). Informe o nome “ModelForcaDeVenda” e por fim clique em Add.

Após clicar em Add será apresentada uma nova janela, conforme a Figura 5. Esta janela é muito importante, pois é aqui onde você deve selecionar a forma que vai trabalhar com Entity Framework, ou seja, você irá escolher como vai gerar seu modelo de dados. Também deve definir como será a criação do banco de dados, se vai gerar o banco a partir de seu modelo ou se vai gerar o modelo a partir do banco de dados. Assim sendo, é possível selecionar as seguintes opções:

· Empty EF Designer Model: utilizando esta forma de trabalho você irá criar um modelo visualmente através do EF Designer. A partir deste modelo visual será criado o banco de dados e suas classes models, sendo assim, a estrutura de ORM do Entity Framework permite facilmente a inclusão e manutenção de dados no banco de dados;

· Empty Code First model: esta opção cria um modelo vazio Code First a partir da linha de código, ou seja, você irá codificar seu modelo manualmente e em seguida poderá gerar o banco de dados a partir deste código. Por este motivo que se chama Code First, primeiro o modelo e depois a geração do banco de dados.

· Code First from database: selecionando esta opção será criado um modelo Code First com base em um banco de dados já existente, bastando apenas você selecionar as tabelas necessárias para o modelo da aplicação.

· EF Designer from database: aqui será criado o modelo no EF Designer (EDMX) baseado em banco de dados já existente, dessa forma você precisa apenas informar a conexão com banco de dados, selecionar as tabelas e as views se necessário, em seguida será criado um arquivo EDMX.

O EF Designer é um diagrama que representa as tabelas do banco de dados transformadas em classes para seu modelo.

Esta abordagem é interessante para nosso contexto de sistema distribuído, pois não temos uma dependência do projeto Web API para com o banco de dados. Este cenário é o contrário da abordagem Code First, porém em outros cenários o code first é mais apropriado, tudo depende do contexto e domínio de negócio onde o projeto é baseado.

Então será esta abordagem que iremos usar no projeto com a Web API, clique no botão Next para avançar para próxima tela.

Integrando aplicações com Web API

Figura 5. Escolhendo forma de trabalho com Entity Framework.

Na próxima tela você deve criar uma nova conexão com banco de dados clicando no botão New Connection. Realizado este procedimento, marque a opção “Yes, include the sensitive data in the connection string”, logo após clique em Next.

A Figura 6 mostra a nova janela onde devem ser selecionadas as tabelas necessárias do banco de dados para o serviço, em seguida clique em Finish. Perceba que nesta tela também é possível selecionar Views e Stored Procedures caso existam no banco de dados e sejam necessárias na aplicação.

Integrando aplicações com Web API

Figura 6. Selecionado as tabelas do banco de dados para o serviço.

Após finalizada a inclusão do Entity Framework ao projeto, será aberto o arquivo EDMX contendo todas as classes models que representam as tabelas do banco de dados, conforme a Figura 7, ou seja, o mapeamento objeto relacional propriamente dito. Perceba que na Solution Explorer, dentro da pasta Models, é criado várias classes com extensão .cs para cada entidade do mapeamento objeto relacional realizado com a base de dados.

Integrando aplicações com Web API
abrir imagem em nova janela

Figura 7. Arquivo EDMX com o diagrama e os Models referente às tabelas do banco de dados.

Criando o Controller Cliente para realizar operações CRUD com EF

A partir deste ponto focaremos na criação das funcionalidades do serviço da Web API para expor os métodos para acesso às funcionalidades de CRUD para as entidades cliente, produto, cabeçalho do pedido e itens do pedido.

O acesso será realizado via requisições HTTP com uso de seus verbos, sendo que cada recurso terá uma rota especificada em forma de URI que identifica o caminho para as requisições de cada operação como a inclusão, leitura, alteração e exclusão de recursos no servidor.

Como a Web API roda em cima do ASP.NET MVC, precisaremos criar um controller para cada model que irá expor alguns métodos. Começaremos então criando o controller para clientes.

Para adicionar um novo controller para cliente, clique com o botão direito na pasta Controllers localizada no Solution Explorer, em seguida clique na opção Add> Controller. Com misso será aberta uma nova janela conforme mostra a Figura 8.

Selecione a opção “Web API 2 Controller with actions, using Entity Framework“, assim o Visual Studio irá auxiliar na criação do controller Cliente com base no model do Entity Framework. Desta forma serão gerados os métodos que precisaremos para as operações de CRUD no banco de dados. Este procedimento é conhecido como Scaffold.

Integrando aplicações com Web API

abrir imagem em nova janela

Figura 8. Criando um controller para cliente através do Scaffold.

Essa figura apresenta várias possibilidades de uso do scaffold, que nada mais é que um assistente para gerar um controller automaticamente com base na Web API ou ASP.NET MVC, desta forma ele nos poupa de um grande trabalho manual de codificação. Nosso contexto utiliza o Entity Framework, assim sendo o scaffold gera automaticamente todos os métodos para manutenção de dados.

Após selecionado o scaffold correto para o contexto do projeto e clicado em Add, será aberta ...

Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo