Artigo no estilo: Curso

Do que trata o artigo

Neste artigo vamos criar uma aplicação completa de microblog utilizando ASP.NET. Este artigo será dividido em 3 etapas, sendo que nesta primeira vamos basicamente estruturar o HTML da aplicação utilizando tableless. Veremos boas práticas, compatibilidade com navegadores e JavaScript, incluindo o uso de AJAX.


Para que serve

O objetivo desta série de artigos é abordar todas as etapas de um projeto web, desde a criação do layout, montagem do HTML, criação da base de dados, estruturação da camada de acesso a dados, integração dos objetos com a camada de apresentação e finalmente a criação de serviços REST para expor informações desejadas.


Em que situação o tema é útil

Saber todas as etapas de um projeto web é essencial para qualquer programador. Desde a montagem do HTML a partir de uma imagem criada por um designer até a publicação no servidor de produção, existem muitas atividades que um bom desenvolvedor deve conhecer. Atrás de um exemplo prático veremos diversas boas práticas que podem lhe ajudar e muito a desenvolver produtos com mais qualidade.

Resumo do DevMan

Neste artigo vamos construir um microblog do início ao fim. Desde os conceitos mais básicos, passando pelo layout, montagem do HTML, banco de dados, camada de acesso a dados, integração com telas de apresentação, utilização de AJAX e até mesmo a criação de um serviço REST. É fundamental para qualquer profissional de TI conhecer as principais etapas de um projeto web. Nestes três artigos, veremos em detalhes como criar as principais partes que englobam o projeto, desde o “papel em branco” até a publicação da aplicação pronta em produção.

Diversos leitores me escrevem com dúvidas sobre integração ou com dificuldades de visualizar um projeto como um todo. Alguns desenvolvedores são muito bons com base de dados, mas não conseguem montar um HTML, por exemplo. Nestes três artigos pretendo dar uma visão global de um projeto web, desde a folha de papel, rabiscada em um “guardanapo”, até a entrega do projeto pronto para produção.

Conhecer todas as etapas de um projeto certamente é algo que leva tempo, e conseguir fazer bem todas elas é um desafio constante. Espero que com estes três artigos possamos criar juntos um produto de qualidade e que seja apreciado pelos usuários.

O Projeto – DevTwit

Muitos conhecemos e utilizamos os chamados “microblogs”, ferramentas sociais para comunicação com quantidade de caracteres limitada. Em um microblog o usuário pode se cadastrar, pesquisar outras pessoas e seguí-las. Ao seguir uma pessoa, o usuário passa a ler todas as mensagens enviadas por ela. O usuário também pode enviar suas próprias mensagens, que por sua vez serão lidas pelas pessoas que o seguem. Funcionalidades que giram em torno deste cenário são bem-vindas, como pesquisa de usuários, pesquisa de mensagens, entre outras. Algumas destas funcionalidades estarão disponíveis também através de serviços web, ou seja, outros sistemas poderão ser integrados com o DevTwit. Para estes serviços utilizaremos REST. Nesta primeira etapa do artigo vamos focar na interface e usabilidade do sistema.

Por onde começar um projeto web?

Esta pergunta é capaz de gerar muita discussão. Não existe uma única resposta correta, pois tudo depende muito do projeto, da equipe, do cliente, do prazo, metodologia utilizada etc. Metodologias ágeis de desenvolvimento de software pregam que devemos entregar o mais rápido possível, com o máximo de qualidade, o que mais gera valor para o cliente, e deixá-lo informar os próximos itens mais importantes, baseados na última entrega, para que então a equipe informe o que conseguirá entregar em um período pré-determinado.

Saber por onde o projeto deve começar pode ser uma decisão tomada em conjunto com o cliente, levando em conta o que agrega mais valor ao seu negócio e também o que a equipe será capaz de entregar. Com base nisso, vamos analisar agora alguns cenários.

Faz sentido começar pelo serviço web?

Serviços web são meios de fazer com que sistemas se comuniquem através de mensagens. Hoje em dia os tipos de serviços web, ou web services, mais comuns são baseados em princípios REST ou SOAP (RPC). Ao longo dos três artigos veremos as diferenças entre eles, portanto não se preocupe com isto agora.

Nós programadores podemos achar meio estranho começar pelo serviço web, uma vez que não temos a base de dados criada, o layout, a interface, e nem conhecemos direito as funcionalidades ainda. Então, como podemos começar pelo serviço web?

Imagine que o seu cliente exponha o seguinte cenário. Nós temos um prazo de três semanas para colocar a primeira versão deste projeto em produção, sendo cada semana um ciclo. Ele tem um parceiro estratégico que precisa integrar o sistema dele com o DevTwit. Ele já informou que precisa de duas semanas para integrar. Por onde faz mais sentido começar o projeto neste cenário? Certamente pelo serviço web. Neste caso seriam levantadas as funcionalidades necessárias para o serviço web, para que pelo menos a criação das interfaces dos serviços sejam criadas, mesmo que os dados sejam fictícios, ou seja, sem necessariamente termos a base de dados.

Com a interface do serviço pronta, o parceiro do cliente pode começar a integrar seu sistema com o DevTwit, pois neste momento não interessa para ele se as mensagens recebidas vêm de uma base de dados, de um arquivo XML, ou estão fixas no código. O que ele precisa saber, em um nível mais baixo, são os nomes dos “nós do XML”, o endereço de acesso, qual a tecnologia utilizada, enfim, tudo para que ele consiga em duas semanas integrar o seu sistema com o DevTwit.

Poderíamos neste caso criar endereços permitindo que o parceiro crie novos usuários, vincule-os a outros usuários, adicione novas mensagens, receba uma lista das últimas mensagens e assim por diante. Mesmo sem banco de dados nem objetos criados, estes métodos podem ser escritos como “esboços” (ou stubs), retorno apenas mensagens pré-definidas pois, nesta etapa inicial, o que importa para o parceiro é ter um endereço de serviço sobre o qual ele possa simular a sua integração.

À medida que o DevTwit for ganhando corpo, ou seja, que tiver uma base de dados e métodos funcionais, o serviço vai ao mesmo tempo ganhando vida, pois seus métodos passam a realmente executar as operações que se propõem a executar, mas baseados na mesma interface criada anteriormente.

Nota do DevMan

RPC (Remote Procedure Call) significa chamada de procedimento remoto é utilizado para criação de aplicativos cliente/servidor. O RPC é um estilo (sendo o SOAP o protocolo utilizado) para criação de aplicativos cliente/servidor no qual um proxy (objetos locais que permitem acesso ao servidor) é utilizado para permitir que métodos (funções ou procedimentos) sejam invocados de outra máquina como se estivessem trabalhando localmente.

Nota do DevMan

REST significa Representational State Transfer e é um conjunto de diretrizes de desenvolvimento de software para distribuição de sistemas hipermídia que trabalham em cima do HTTP. Quando utilizamos SOAP, na maioria dos casos, os dados empacotados são transferidos usando o protocolo HTTP. Neste caso, HTTP é utilizado apenas para transporte, já que ambos os lados (cliente e servidor) precisam conhecer SOAP para desempacotar e utilizar os dados. Em serviços construídos com REST (conhecidos também como serviços RESTful) não existe a necessidade do empacotamento dos dados transferidos pois a própria estrutura do HTTP é utilizada.

...

Quer ler esse conteúdo completo? Tenha acesso completo