Utilizando Ajax com Asp.Net MVC    

Olá pessoal, hoje vou falar de um assunto que é de extrema importância para desenvolvimento Web atualmente: Ajax.

Para quem não sabe, Ajax é o acrônimo de Asynchronous Javascript And XML, e que na  prática nada mais é que a capacidade de postar informações ao servidor, sem a necessidade de enviar a página inteira, e receber apenas uma pequena informação, sem a necessidade de atualizar a página toda. Para saber mais, clique no link do nome.

Hoje em dia, Ajax virou praticamente um conceito de atualização parcial de páginas Web, digo isso, porque Ajax em si não é mais utilizado na grande maioria das vezes! É isso mesmo, se reparar no nome completo, o X do Ajax é XML, e normalmente não utilizamos XML para a comunicação, mas sim JSON, ou seja, o que utilizamos de fato é chamado muitas vezes em blog e artigos pela Web de AJAJ (Asynchronous Javascript And JSON).

A responsabilidade de fazer a comunicação de forma assíncrona é do navegador, através do objeto XMLHttpRequest (IE 7+, e demais browsers) ou do Microsoft.XMLHTTP (IE 5 e 6). No nosso caso, não precisamos saber disso, porque utilizaremos JQuery para encapsular toda a lógica de criação da comunicação.

Apesar de usarmos JQuery, nós poderiamos utilizar outros frameworks JavaScript para encapsular a lógica de comunicação. A própria Microsoft disponibilizar nos projetos Web o framework MicrosoftAjax.js, que é extremamente bom. Com esse framework, inclusive, você pode acessar funcionalidades do Asp.Net, como a parte de Authentication.

Bom, mas vamos ao que interessa.

Utilizando JQuery para fazer chamadas assíncronas em Asp.MVC

No Jquery existe uma forma básica de se comunicar assincronamente com o servidor, que é o método $.ajax. Este método contém todas as informações necessárias para uma comunicação, nele você pode definir a url, o método de retorno em caso de sucesso e em caso de falha, tipo do dado passado (onde você pode passar uma sério de Content-Type, como json, xml, text, etc), verbo HTTP (get, post, etc), e mais uma série de opções. Como não utilizaremos esse método, você pode clicar aqui para ver uma lista detalhada de opções.

Não utilizaremos esse método, porque existem dois métodos que abstraem bastante a utilização dele, e que são suficientes para a maioria das situações, são os métodos $.post e $.get.

Estes métodos basicamente invocam o método $.ajax, passando no parâmetro type o tipo post ou get. O único problema é que ele não retorna erro, ou seja, se tiver algum problema no seu código que faça ter algum erro, você vai ficar sem saber até quebrar um pouco a cabeça, o ideal é: Quando tiver algum comportamento estranho, mude o método para $.ajax, e defina o parâmetro error, assim poderá ver qual a mensagem de erro está sendo retornada do servidor.

Nosso site fará quatro testes:

  • Obter informação do servidor via Get
  • Enviar informação para o servidor via Get
  • Enviar informação para o servidor via Post através de parâmetros
  • Enviar informação para o servidor via Post através de um objeto.

Abaixo segue o código do Controller com suas Action:

   1:  public JsonResult ObterGet()
   2:  {
   3:      var json = new { Nome = "Nome do Servidor", Idade = 20 };
   4:      return Json(json, JsonRequestBehavior.AllowGet);
   5:  }
   6:   
   7:  public JsonResult EnviarGet(string nome, int idade)
   8:  {
   9:      var json = new { Nome = nome + " Servidor", Idade = idade + 1 };
  10:      return Json(json, JsonRequestBehavior.AllowGet);
  11:  }
  12:   
  13:  public JsonResult EnviarPost(string nome, int idade)
  14:  {
  15:      var json = new { Nome = nome + " Servidor", Idade = idade + 1 };
  16:      return Json(json);
  17:  }
  18:   
  19:  public JsonResult EnviarObjeto(Pessoa p)
  20:  {
  21:   
  22:      p.Nome += " Servidor";
  23:      p.Idade += 1;
  24:      return Json(p);
  25:  }

Os códigos são bem simples: Os métodos de GET (ObterGet e EnviarGet) precisam passar uma informação a mais no método Json pois o MVC força você a dizer que quer retornar uma chamada get, mesmo sabendo do risco que isso pode ser. É um risco porque um site de outro domínio pode invocar esse método utilizando GET, e se você não informar que isso aconteça, o ASP.NET vai barrar a chamada, retornado  a mensagem:

This request has been blocked because sensitive information could be disclosed to third party web sites when this is used in a GET request. To allow GET requests, set JsonRequestBehavior to AllowGet.

Como queremos testar o Get, então permitimos essa comunicação, adicionando o parâmetro JsonRequestBehavior.AllowGet. Para os métodos utilizados através de POST (EnviarPost e EnviarObjeto) não precisamos utilizar esse parâmetro.

Para o método EnviarObjeto funcionar, criei uma classe simples, que segue abaixo:

   1:  public class Pessoa
   2:  {
   3:      public string Nome { get; set; }
   4:      public int Idade { get; set; }
   5:  }

Para consumir esses métodos, criei o HTML abaixo:

<p>Nome:<input type="text" id="txtNome" /></p>
<p>Idade:<input type="text" id="txtIdade" /></p>
<input type="button" value="Enviar Get" onclick="enviarGet();"/>
<input type="button" value="Enviar Post" onclick="enviarPost();"/>
<input type="button" value="Enviar Objeto" onclick="enviarObjeto();"/>
<input type="button" value="Obter" onclick="javascript:obter();"/>

Sua visualização será essa:

image

E o Javascript da página será:

   1:  function obterCallback(retorno,status) {
   2:      $("#txtNome").val(retorno.Nome);
   3:      $("#txtIdade").val(retorno.Idade);
   4:  }
   5:  function obter() {
   6:      $.get("Ajax/ObterGet", obterCallback);
   7:  }
   8:   
   9:  function enviarGet() {
  10:      if ($("#txtNome").val() == "" || $("#txtIdade").val() == "") {
  11:          alert("Preencha todas os campos!");
  12:          return;
  13:      }
  14:      $.get("Ajax/EnviarGet",
  15:      { nome: $("#txtNome").val(), idade: $("#txtIdade").val() },
  16:         obterCallback
  17:      );
  18:  }
  19:   
  20:  function enviarPost() {
  21:      if ($("#txtNome").val() == "" || $("#txtIdade").val() == "") {
  22:          alert("Preencha todas os campos!");
  23:          return;
  24:      }
  25:      $.post("Ajax/EnviarJson",
  26:      { nome: $("#txtNome").val(), idade: $("#txtIdade").val() },
  27:         obterCallback
  28:      );
  29:  }
  30:   
  31:  function enviarObjeto() {
  32:      if ($("#txtNome").val() == "" || $("#txtIdade").val() == "") {
  33:          alert("Preencha todas os campos!");
  34:          return;
  35:      }
  36:      $.post("Ajax/EnviarObjeto",
  37:      { nome: $("#txtNome").val(), idade: $("#txtIdade").val() },
  38:         obterCallback
  39:      );
  40:  }

O JavaScript, utilizando o Jquery, é tão simples que nem precisaria de explicação, mas vamos lá: O primeiro parâmetro é o endereço da Action (Controller/Action), o segundo pode ser o método de retorno (Callback) ou os parâmetros que serão passados, caso seja definido parâmetro, o terceiro método é o método de retorno. Existe um quarto parâmetro que não estou utilizando, que seria para informar o tipo do retorno (json, xml, etc). No meu caso não preciso utilizá-lo.

Os parâmetros estou passando através de um objeto JSON, que o Jquery converte em querystring, caso seja GET ou coloca os parâmetros no corpo da mensagem HTTP, caso seja POST. Relembre essas regras aqui.

Para conseguir testar, basicamente eu altero o valor enviado para o servidor e retorno, preenchendo os campos com o novo valor, dessa forma posso ver que as informações estão realmente chegando no servidor e voltando.

Obervação: A Action que recebe as chamadas Assíncronas não precisa estar no mesmo Controller que retornou a View do formulário.

Conclusão

Quis mostrar nesse post como é simples utilizar Ajax juntando MVC e JQuery, tão simples quanto utilizar PageMethods no WebForms, porém, sendo mais rápido para primeira renderização (porque não precisa de ScriptManager para gerar um Proxy).

Obervação 2: No WebForms é possivel utilizar esses métodos do Jquery com os métodos estáticos da página marcados com o atributo WebMethod, dessa forma você não precisaria utilizar o ScriptManager para gerar o próximo PageMethods.

Acho importante esse tipo de conhecimento, pois hoje em dia não existe site ou sistema sem alguma funcionalidade Assícrona, e isso pode ser incluído nos conhecimentos básicos de Asp.Net MVC.

O Link para o exemplo está abaixo.

MvcAjax.zip (292,92 kb)

Bom, por hoje é isso. Até o próximo.


  
     
  
24. janeiro 2011 23:31 by Frederico | Comments (3) | Permalink

Tarefas básicas com Asp.MVC (CRUD)    

Olá pessoal!

Continuando os tópicos básicos do Asp.Net MVC, hoje vou fazer um pequeno cadastro para mostrar como interagir entre View e Controller. Vou procurar fazer tudo manualmente, para que você possa entender como funciona de fato essa intereção. Digo isso porque existem muitas formas de facilitar o desenvolvimento de Views, por exemplo, utilizando HTML Helpers, mas não vou fazer uso deles para que possamos, quando formos falar dos Helpers, entender como é o seu funcionamento.

Para nosso post hoje, vou criar apenas uma tabela no SQL Server Express para armazenar um cadastro de pessoas, como o objetivo é mostrar a Interação Controller/View/Controller, não vou tomar cuidado com validações, nem com um modelo elaborado.

Para começar, vamos criar nossa tabela como abaixo, e criar o acesso aos dados utilizando Entity Framework.

image

image

Feito isso, vamos adicionar um Controller no projeto chamado Cadastro, lembre-se que sempre começamos o desenvolvimento do site MVC adicionando o Controller. Coloquei “site” em negrito, porque muitos podem dizer que é pelo Modelo, ou Domínio, que se inicia o desenvolvimento, inclusive é o que prega as práticas de DDD (Domain Driven Development), mas quero deixar claro que o Modelo (Domínio) de fato é o princípio do desenvolvimento do Projeto, mas quando vamos iniciar o site, o Modelo já deve estar definido, portanto, conhecendo o Modelo você deve iniciar o site pelos Controllers necessários para esse Modelo, entendendo que o Modelo não é para o site, mas para o projeto, pois ele pode ser utilizado para qualquer ambiente. No futuro vou falar um pouco de DDD, visto que no MVC, a sua utilização é extremamente útil.

Adicionando o Controller, vamos marcar as opções para adicionar as Actions de Create, Update, Delete e Details, apenas para facilitar, visto que não é necessário utilizar exatamente métodos com esse nome para realizar o CRUD dos registros. Veja que ele criar algumas Actions com o mesmo nome, o motivo é bem simples:

Como para acessar uma View devemos acessar pela URL o Controller que contem a Action que sabe gerar essa View (por exemplo: http://seusite/Cadastro/Create), algumas Actions precisam se chamadas para renderizar a View e outras para Processar a requisição da View renderizadas anteriormente. Por exemplo: Para criar um novo registro, eu devo invocar a Action Create para renderizar os campos em brancos, dessa forma invocando a Action Create sem parâmetros, que só deve renderizar a View pura, e em seguida, após preencher os campos e clicar no botão Salvar, eu devo invocar a Action Create novamente, porém agora passando as informações que foram preenchidas, chamando dessa forma a Action com parâmetros. Isso é possível porque o motor do Asp.Net MVC consegue diferenciar overloads de métodos de acordo com as informações passadas no corpo da mensagem. Você precisa sempre utilizar essa regra de Overloads para Actions com funções ligadas? Não! No Asp.Net MVC você tem o controle de tudo, e pode usar da forma que achar melhor.

Além de criar as Actions do CRUD, ele também cria uma Action chamada Index, que é a invocada pelo Asp.Net se nenhuma Action form informada na URL. Precisa sempre ter o nome Index? Não! Como eu disse, você pode mudar quase qualquer coisa no MVC, apenas mudando as rotas padrões no arquivo Global.asax.

Abaixo segue todo o código do meu Controller. Você verá que cada método é muito simples:

  public ActionResult Index()
        {
            using (var bd = new bdEntities())
            {
            var query = from pessoas in bd.Pessoa select pessoas;

                //ObjectQuery p = new ObjectQuery("select cod_pessoa,nom_pessoa,des_email,num_telefone from  Pessoa", bd);
                //var resultado = p.Execute(MergeOption.NoTracking);

            
                return View(query.ToList());
            }
        }

      
        public ActionResult Create()
        {
            return View();
        } 

        [HttpPost]
        public ActionResult Create(FormCollection collection)
        {
            try
            {

                using (var bd = new bdEntities())
                {


                    var pessoa = new Pessoa();

                    pessoa.Email = collection["txtEmail"];
                    pessoa.Nome = collection["txtNome"];
                    pessoa.Telefone = collection["txtTelefone"];

                    bd.AddToPessoa(pessoa);
                    bd.SaveChanges();
                }


                return RedirectToAction("Index");
            }
            catch
            {
                return View();
            }
        }
        
        public ActionResult Edit(int id)
        {

            using (var bd = new bdEntities()){
                var pessoa = (from p in bd.Pessoa
                             where p.Codigo == id
                             select p).First();
                         
            return View(pessoa);
            }
        }

        [HttpPost]
        public ActionResult Edit(int id, FormCollection collection)
        {
            try
            {
                using (var bd = new bdEntities())
                {
                    var pessoa = (from p in bd.Pessoa
                             where p.Codigo == id
                             select p).First();

                    pessoa.Email = collection["txtEmail"];
                    pessoa.Nome = collection["txtNome"];
                    pessoa.Telefone = collection["txtTelefone"];

                    
                    bd.SaveChanges();
                }

                return RedirectToAction("Index");
            }
            catch
            {
                return View();
            }
        }

        public ActionResult Delete(int id)
        {
            using (var bd = new bdEntities())
            {
                var pessoa = (from p in bd.Pessoa
                              where p.Codigo == id
                              select p).First();

                bd.DeleteObject(pessoa);
                bd.SaveChanges();
                return RedirectToAction("Index");
            }
        }

Você pode excluir a Actions que não foram utilizadas, como Details (não teremos em nosso cadastro e Delete com dois parâmetros, pois o registro será excluído diretamente da lista.

Perceba que alguns trechos de códigos foram repetidos algumas vezes, e obviamente isso não é legal. Para solucionar esse problema, deveríamos criar um Domínio (Modelo) mais elaborado, encapsulando os métodos de pesquisas, mas para simplificar nosso modelo, resolvi fazer assim. Perceba também que alguns métodos recebem como parâmetro a classe FormCollection. Nesse parâmetro é armazenado todos os campos enviados a partir de formulários do HTML para o Controller, como era feito com Request.Form. É daí que leremos as informações fornecidas pelo usuário.

Você pode estar se perguntando: Posso colocar um método de auxilio no Controller, para facilitar a reutilização? A resposta é: não! Lembre que o MVC procura deixar claro o conceito de SoC - Separation of concerns (Separação de Interesses), por isso, todo método dentro de um Controller, tem a intenção de ser um Controlador (Action), e qualquer método (público) que você colocar ali dentro, será uma Action, mesmo que retorno um tipo incompreensivo para o Navagador. Tudo que tenha a ver com regra de negócio, deve ser colocado na camada Model.

Após criarmos nossos Controllers e Actions, vamos criar as Views.

Três actions necessitam ter Views específicas, são elas:

  • ActionResult Index()  - Retornará a lista de registros.
  • ActionResult Create()  - Retornará o formulário de criação de usuário.
  • ActionResult Edit(int id) – Retornará o formulário de edição de usuário já com os dados preechidos.

As demais Actions não precisam de View específica porque elas apenas persistem as informações e redirecionam o usuário para a listagem, criada na Action Index, sendo esse redirecionamento feito através do método RedirectToAction.

Para criar a View, clique no nome do método com o lado direito do método e Add View.

Vamos ver como ficará nossa View de listagem (Index)

    <h2>Lista de Pessoas</h2>
    <table>
		<thead>
			<tr>
				<th>Ação</th>
				<th>Nome</th>
				<th>E-mail</th>
				<th>Telefone</th>
			</tr>
		</thead>
		<tbody>
		<%foreach(var item in ViewData.Model){ %>
			<tr>
				<td><a href="Cadastro/Edit/<%=item.Codigo %>">Editar</a> <a href="Cadastro/Delete/<%=item.Codigo %>">Excluir</a></td>
				<td><%=item.Nome %></td>
				<td><%=item.Email%></td>
				<td><%=item.Telefone %></td>
			</tr>

		<%} %>
		</tbody>
    </table>
    <a href="Cadastro/Create">Novo</a>

Explicando: Estou criando uma tabela e fazendo um foreach no retorno da Action, que sempre fica exposto através da propriedade ViewData.Model. Para criar a coluna com os links de ação, perceba que estou adicionando links, e montando a URL de acordo com a estrutura Controller/Action/Parametros, e o botão para adicionar um novo, passando apenas Controller/Action. O resultado seria isso:

image

Para as duas outras Views, como vou submeter dados ao servidor, preciso criar um formulário, e definir como Action desse formulário, minha Action do Controller que receberá esses dados. Como são no mesmo Controller, posso apenas fornecer o nome da Action, sem passar o nome do Controller. A diferença de uma para outra é que uma eu já preencho os dados, e outra não:

View de Criação:

 <form name="formCadastro" action="Create" method="post">
    <h2>
        Criar novo Contato</h2>
    <p>
        <span>Nome</span><input type="text" name = "txtNome" id="txtNome" /></p>
    <p>
        <span>E-mail</span><input type="text" name = "txtEmail"  id="txtEmail" /></p>
    <p>
        <span>Telefone</span><input type="text" id="txtTelefone" name = "txtTelefone"  /></p>
    <p>
        <input type="submit" value="Salvar" /></p>
    </form>

View de Edição:

 <form name="formCadastro" action="Edit" method="post">
    <input type="hidden" id="hdfCodigo" name="id" value="<%=ViewData.Model.Codigo %>" />
    <h2>
        Alterar Contato</h2>
    <p>
        <span>Nome</span><input type="text" value="<%=ViewData.Model.Nome %>" name="txtNome"
            id="txtNome" /></p>
    <p>
        <span>E-mail</span><input type="text" value="<%=ViewData.Model.Email%>" name="txtEmail"
            id="txtEmail" /></p>
    <p>
        <span>Telefone</span><input type="text" id="txtTelefone" value="<%=ViewData.Model.Telefone %>"
            name="txtTelefone" /></p>
    <p>
        <input type="submit" value="Salvar" /></p>
    </form>

Diferente do WebForm no MVC você pode colocar quantos formulários quiser em uma mesma página, como é normal em qualquer outra plataforma Web, ou mesmo alterar o Action em tempo de execução. Para que as informações aparecem no parâmetro FormCollection, seus controles precisa ter o atributo name definido, pois é de onde o HTTP retira as informações para criar a mensagem (Post ou Get) a ser enviada ao server. No caso das Views acima, estou enviando via POST, como pode ser visto no atributo method do formulário.

Com esses códigos você já tem seu cadastro funcionando. Com certeza, para desenvolvê-lo você levará menos tempo que para ler esse post. Tudo ficou muito rápido e transparente, sem inúmeros arquivos de códigos inseridos pelo Asp.Net como acontece com o WebForm.

Como eu disse, não utilizei nenhum Helper do MVC para gerar HTML, se tivesse utilizado, com certeza o tempo gasto para desenvolver esse cadastro seria ainda menor.

Conclusão

Nesse post procurei mostrar como é simples criar uma página básica de cadastro. Nos próximos posts tentarei mostrar como deixar essa página um pouco mais elaborada.

Clique no arquivo abaixo para baixar o fonte do exemplo

MvcCrud.rar (426,09 kb)

Até o próximo

30. novembro 2010 14:36 by Frederico | Comments (1) | Permalink

A plataforma Asp.Net    

Olá Pessoal!

Depois de algum tempo impossibilitado de escrever, retomo minha pequena série introdutória sobre MVC.

Na realidade, no primeiro post, comentei que faria uma séria sobre Web, para que quando fosse falar de Asp.Net MVC, pudesse falar para pessoas que entendesse pelo menos de Web e Asp.Net, para saber onde Asp.Net MVC se encaixa, para quem não se lembra, segue a lista:

Tentarei ser breve nesse post, para que inicie a série sobre Asp.Net MVC o quanto antes.

O que seria o Asp.Net? Asp.Net é um framework da Microsoft para auxiliar o desenvolvimento Web. Entendam como framework, uma coleção de classes que auxiliam na solução de uma tarefa, e que tarefa é essa? Encapsular requisições HTTP, contextos de requisições, respostas HTTP, enfim, tudo do que a web pura é feita.

O Asp.Net faz o trabalho de traduzir as requisições por nós, é uma coleção poderosa de classes, que devemos utilizar para nos comunicar de forma melhor com os protocolos da Internet.

E o que é que podemos fazer com o Asp.Net? Tudo que você pensa que o IIS faz. Como assim? O que o IIS faz, em grande parte (não em todas é claro), é delegar o processamento de certas requisições as classes do Asp.Net. Você pode ver exemplos disso aqui e aqui. Quando geralmente desenvolvemos sites sobre o framework Asp.Net, não estamos utilizando ele diretamente, estamos utilizando outros componentes que rodam sobre o Asp.Net, como o WebForm e o MVC, e por isso chamados de Asp.Net WebForm ou Asp.Net MVC.

Conhecendo a arquitetura do Asp.Net, poderemos criar inclusive um servidor Web, nosso próprio IIS (como mostrado no segundo link acima), poderíamos implementar da forma que quiséssemos esse servidor, inclusive utilizando um servidor Linux, e rodando o CLR sobre o Mono.

Para entendermos um pouco mais sobre isso, vale mostrar uma ilustração:

Diagrama Asp.net

Perceba na imagem acima que Asp.Net é construído em cima do .Net, portanto pode ser utilizado em qualquer contexto onde qualquer classe do framework pode ser utilizada.

Você também deve ter reparado que coloquei três conjunto de componentes que rodam sobre a arquitetura do Asp.Net, e que geralmente é por onde nós alcançamos o Asp.Net de fato. Da mesma forma que esses três conjuntos estão sobre o Asp.Net, e não se complementam nem se anulam, podemos desenvolver novos frameworks que rodam sobre o Asp.Net.

Poderia ter colocado outros quadrinhos no nível superior do diagrama, mas não quis fazer isso pois quis focar apenas em componentes de Web (que auxiliam na construção de sites/tela). O Asp.Net também é um framework de auxilio ao desenvolvimento para internet (que é levemente diferente de simples Web), e poderíamos incluir no diagrama quadros como WebServices, que não é nem Asp.Net MVC, nem Asp.Net WebForms, nem Asp.Net Dynamic Data, é Asp.Net WebServices, que ainda existe, mesmo com o uso muito mais comum de serviços WCF rodando sobre o IIS.

A Microsoft, na atual estrutura do “framework Asp.Net”, decidiu por implementar três paradigmas distinto de aplicações, esses paradigmas não são exclusivos de Web: MVC também é implementado em aplicações Windows, da mesma forma que o WebForms procura levar para o desenvolvimento Web a experiência de desenvolver WindowsForm, e o Dynamic Data procura implementar o conceito RAD (Rapid Application Development) que visa desenvolver aplicações de forma rápida, interativa e incremental.

Como disse, da mesma forma que a Microsoft desenvolveu esses conceitos sobre o framework Asp.Net, nós poderíamos desenvolver outro paradigmas de desenvolvimento sobre o Asp.Net, e nossas páginas seriam servidas pelo IIS sem grandes modificações, afinal, o IIS conhece o Asp.Net, não a implementação específica de cada paradigma de desenvolvimento.

Um exemplo para isso é o MVC#, que procura implementar o padrão MVP, muito utilizado hoje no desenvolvimento Web. É um framework independente, não muito conhecido ainda, mas que mostra as possibilidades de se criar sobre o Asp.Net.

Entendendo como funciona o Asp.Net, as discussões do tipo “O MVC vai substituir o WebForms” devem acabar, pois dá para entender que cada forma de desenvolvimento tem o seu objetivo, quando vamos iniciar o projeto, devemos pensar em qual padrão se aplica melhor para a solução que queremos desenvolver, inclusive devemos analisar o uso do Dynamic Data, que pode resolver muitos problemas simples de forma extremamente rápida. Talvez no futuro eu faça algum post sobre o uso de tipo de Projeto.

Além de dá suporte aos tipos de aplicação que citei acima, outras tecnologias da Microsoft que rodam sobre o Framework .Net também fazem uso da arquitetura do Asp.Net, como o Silverlight em algumas situações ou o WCF, onde podemos utilizar sessões e outras características específicas de desenvolvimento de internet (sobre HTTP).

Para dar suporte ao desenvolvimento Web, a Microsoft também desenvolveu outras pequenas bibliotecas. Um exemplo disso é o Asp.Net Ajax, que pode ser utilizada tanto no lado Servidor (exclusivo para aplicações Asp.Net, mas exclusivamente para WebForms), como no lado cliente (podendo ser utilizada em qualquer arquitetura web, como Java, PHP, etc) codificada em JavaScript, que já parece estar com os dias contatos, com a adoção cada vez mais ampla pelo time da Microsoft do JQuery.

Bom, acredito que o que foi dito até aqui já dá para ter uma idéia de como o Asp.Net é divido, e como podemos usá-lo de acordo com a nossa necessidade para cada momento. Espero que esse texto possa te ajudar a ver o Asp.Net de uma forma mais ampla, e não apenas fechado a realidade que você trabalha (MVC ou WebForm em geral).

Até o próximo post.

8. novembro 2010 06:38 by Frederico | Comments (2) | Permalink

HTTP – Entendendo Post, Get, Status Code e Content-Type    

Para iniciar este post, vou utilizar um texto do livro para a certificação de Asp.Net do framework 3.5 (70-562):

“Um bom desenvolvedor de aplicações Web precisa saber muito mais que apenas sua linguagem preferida para ser um verdadeiro desenvolvedor Web. De fato, C# ou Visual Basic é só o começo. Você precisar saber como criar, gerenciar e implementar interface com CSS. JavaScript também será necessário se você quiser criar suas próprias funcionalidades no lado do Cliente em suas páginas. Você pode também precisar conhecer XML, Web Services e banco de dados. Claro, você também precisa saber como todas essas coisas trabalham juntas para fazer uma única solução. Um desenvolvedor de Web moderno precisa saber mais tecnologias (e ter facilidade de mudar entre elas) do qualquer outro desenvolvedor na história. Eu penso que essa é uma das razões que o desenvolvimento Web é uma experiência tão desafiadora, legal e recompensadora”

--Mike Snell – Microsoft .Net Framework 3.5 – Asp.Net Application Development – Training Kit

É isso que todo desenvolvedor Web deve saber: que ele deve conhecer muitas tecnologias! Como comentei no primeiro post dessa série introdutória à série de posts sobre Asp.Net MVC, a necessidade destes posts introdutórios é que o desenvolvedor Asp.Net saiba que para realmente ser um desenvolvedor Asp.Net ele precisa também ser , antes de qualquer coisa, um desenvolvedor Web, conhecer o funcionamento da Web (pelo menos o Básico).

Então vamos ao tema do post!

Aplicações Web não são como aplicações Windows, elas não rodam em um processo único nem em uma máquina única. Normalmente elas são hospedadas em um servidor Web e acessadas através de um navegador. A comunicação é feita através do protocolo HTTP (Hypertext Transfer Protocol). É necessário saber como essa comunicação é feita antes de você sair fazendo páginas que sobrecarregam a comunicação. Uma comunicação típica entre o navegador e servidor pode ser resumida nesses dez passos (retirados do livro acima):

  1. Um usuário solicita uma página ou qualquer recurso (uma imagem, por exemplo) de um servidor Web
  2. HTTP é utilizada para enviar uma requisição (request) GET para o servidor
  3. O servidor processa a requisição GET no servidor (normalmente localizando o código solicitado e executando-o)
  4. O servidor então envia uma resposta (response) de volta ao navegador. O protocolo HTTP é utilizado para enviar a resposta (response) de volta ao navegador.
  5. O navegador do usuário então processa a resposta (response), normalmente HTML e JavaScript, e renderiza a página Web para mostrar ao usuário.
  6. O usuário pode então digitar alguma informação ou realizar alguma ação, como clicar em um botão que causa a informação ser enviada de volta ao servidor para processamento.
  7. HTTP é usada para postar (POST) as informações de volta ao servidor (post back to the server).
  8. O servidor então processa a requisição POST (novamente chamando seu código no processo)
  9. O servidor então envia uma resposta de volta ao browser (response back) . HTTP é utilizada para responder ao navegador.
  10. O navegador novamente processa a resposta e exibe a página ao usuário. Esse processo se repete muitas e muitas vezes no tempo de vida de uma página comum.

Entendendo o papel do Hypertext Transfer Protocol

HTTP é um protocolo de comunicação baseado em mensagens de texto utilizadas para requisitar (Request) páginas do servidor e enviar respostas (Response) ao navegador. Estas mensagens são normalmente trocadas entre o servidor e o navegador  utilizando a porta 80 ou 443 se for utilizada HTTP seguro (HTTPs).

Uma mensagem geralmente é formada por cabeçalho (headers) e corpo (body), e veremos alguns exemplos de como essas mensagens são montadas.

Um comando de texto para requistiar uma página seria o seguinte:

GET /default.aspx HTTP/1.1
Host: www.fredericoemidio.com

A primeira linha tem o que chamamos de método HTTP, conhecido algumas vezes como comando HTTP ou Verbo. O verbo é seguido pela URL da página requisitada, seguida pela versão do HTTP utilizada para processar a requisição. A segunda linha define o nome do host que deve ser utilizado pelo servidor, é importante porque é normal que um servidor tenha mais de um site hospedado.

Toda requisição ao servidor, que a gente chama de Request (estava deixando em negrito para vocês verem a ligação, se não viram, agora viram), tem uma resposta, que a gente chama de Response, também baseado em texto. A requisição acima poderia ter uma resposta assim:

HTTP/1.1 200 OK
Server: Microsoft-IIS/6.0
Content-Type: text/html
Content-Length: 38
<html><body>Seja bem vindo!</body></html>

A primeira linha indica o protocolo de comunicação e a versão. Também inclui o código de status da resposta e o texto do status. A segunda linha, como você pode ver, indica o tipo do servidor, a terceira linha o tipo da resposta e a quarta linha o tamanho da resposta. Daí em diante é o conteúdo da resposta.

É importante conhecer um pouco de Códigos de Status para desenvolver uma boa aplicação Web. Na realidade, conhecendo três informações dessas mensagens, você já saberá bastante para desenvolver uma boa página: O Verbo, os Códigos de Status de Retorno e o Contet-Type. Essas três informações são as mais utilizadas ao desenvolver um bom site, e você terá a explicação delas pelo resto do post. Naturalmente, como os demais posts introdutórios, vou apenas pincelar esse tema de HTTP, se você quiser saber mais, visite o site da W3C, e poderá conhecer tudo sobre isso.

Verbos HTTP

Post e Get são verbos HTTP, e são os mais utilizados por nós, essa é a razão do titulo deste post, vamos entender a diferença.

O GET obtém (get em inglês) uma URL do servidor. Uma requisição GET é normalmente armazenada em cache pelo navegador, se nenhuma informação do Get mudar, o browser pode decidir não requisitar a resposta ao servidor, e utilizar uma versão em memória. GET também pode trabalhar com coleções, com aquelas de diretórios que têm lista de arquivos, apesar de que se você requisitar um diretório, o servidor pode estar configurado para retornar um arquivo padrão, como index.htm.

Quando passamos critérios em uma requisição GET, os parâmetros são passados no endereço da requisição, o que chamados de Querystring, ou seja, se digitarmos default.aspx?teste=1 no navegador, a mensagem HTTP que será enviada será:

GET /default.aspx?teste=1 HTTP/1.1
Host: www.fredericoemidio.com

Tudo que for utilizada depois do símbolo de interrogação (?) será considerado parâmetro para o servidor.

Utilizar GET tem seus prós e seus contras: Se você quiser manter o resultado de uma pesquisa em cache, ou enviar para alguém por e-mail, seria interessante utilizar o GET, por outro lado, se você desejar utilizar muitos campos e valores como critério, não será possível, pois o GET aceita no máximo uma string de 1024 caracteres. Os dados podem também ser facilmente alterados, mesmo os parâmetros podem ser alterados.

O POST é utilizado para postar informações para o servidor. Diferente do GET, o POST envia os dados no corpo da mensagem, não alterando o endereço da requisição, a mesma mensagem acima, se fosse enviada através de POST, seria da seguinte forma:

GET /default.aspx HTTP/1.1
Host: www.fredericoemidio.com
teste=1

Dessa forma, não será possível armazenar em Cache o resultado, porque o navegador não armazena o conteúdo da mensagem, apenas o endereço da mensagem. O POST também não tem limitação de tamanho, foi testado até 10 MB e não foi encontrado problemas. O POST também impede que usuário alterem as informações da mensagem, esse verbo é mais comum para envio de informações de formulários para servidores.

Os formulários em WebForms utilizando o método POST para envio, é por isso que muitas vezes validamos no PageLoad da página se a requisição é um PostBack (Retorno de Post).

Podemos facilmente alterar o verbo do envio de um formulário para o servidor, pois a tag FORM tem um atributo METHOD, que pode ter qualquer verbo HTTP, apesar de usarmos geralmente POST ou GET.

Conhecendo esses dois métodos já podemos fazer bastante coisa. Para trabalhar com Ajax, é o mínimo que você precisa conhecer. Existem muitos outros verbos, que você pode estudar mais tarde, mas conhecendo bem as diferenças desses dois é um bom começo.

Códigos de Retorno

Se você já fez alguma coisa com Ajax (de verdade, não com biblioteca que encapsulam tudo), já teve que trabalhar um pouco com códigos de retorno. Os códigos de status de retorno são agrupados em cinco grupos. Mesmo que você não se lembre todos os códigos, é interessante lembrar pelo menos os grupos. Os códigos são agrupados em grupos de três dígitos, conforme segue:

Cód. Descrição
1xx Informativo: Requisição recebida, continuando a processar
2xx Sucesso: A requisição foi recebida com sucesso, entendida e acatada
3xx Comando de Redirecionar: Ações adicionais devem ser tomadas para completar a requisição
4xx Erro do Cliente: A requisição tem algum erro ou o servidor não entendeu todo o pedido.
5xx Erro do servidor: O servidor falhou em completar uma requisição que parecer ser válida.

Você com certeza já deve ter visto alguns dos códigos acima, como 404 – Página não encontrada, ou 500 – Internal Server Error.

Busque conhecer mais sobre esses erros, pode ser muito útil para a solução de problemas estranhos.

Content-Type

Para finalizar esse post, acredito ser importante falar dos tipos de requisição. No exemplo acima mostrei uma requisição do tipo text/html. O tipo de conteúdo pode mudar muito, não é só HTML.

O indicador do tipo de uma mensagem é na forma de Multipurpose Internet Mail Extensions (MIME), no caso do exemplo (text/html), o arquivo é um arquivo estático de HTML. Os tipos MIME são definidos em duas partes (tipo/sub-tipo), no qual o primeiro tipo é tipo do geral do recurso, e o segundo é o tipo mais específico do recurso. Alguns exemplos do Content-Type são: text/xml, text/json, image/jpeg, etc.

Uma requisição ajax, por exemplo, utiliza um content-type text/json em geral, junto com um verbo POST. Muitas vezes, no MVC podemos querer retornar uma View que seja um gráfico, para isso podemos utilizar um content-type do tipo image/png, ou realizar a mesma coisa com WebForms utilizando um Generic Handler (ashx),alterando o content-type do Response.

Conclusão

Bom, nesse post quis mostrar que na Web pode ter um pouco mais do que você imagina. É claro que se você ainda não sabia do que foi dito aqui, então sabia muito pouco sobre a Web, é bom saber como as coisas funcionam por trás dos panos.

Esse artigo foi basicamente baseado no material para certificação da Microsoft, da prova 70-562. Diferente do que muitos pensam, eu acredito que é muito válido o estudo para as certificações da Microsoft, mesmo que você não acredite em certificações, o estudo pelo menos é valido.

Espero que esse post possa te ajudar a entender um pouco mais de Web. Naturalmente, o que foi falado aqui não é 1% do que poderia ser dito, mas como sempre, a idéia é que os posts te mostrem as possibilidades, e que você as busque.

Até a próxima!

25. outubro 2010 19:44 by Frederico | Comments (2) | Permalink

HTML + JavaScript + CSS    

Olá pessoal!

Continuando nossa série de posts introdutório sobre Asp.Net MVC, vamos falar hoje das linguagens básicas a serem utilizadas para o desenvolvimento de sites.

Acho importante abordar esse assunto porque com a facilidade que o WebForm deu ao desenvolvedor de clicar e arrastar controles, e configurar as visibilidades dos controles via Code-Behind, muitos desenvolvedores Asp.Net desconhecem totalmente a razão de ser do HTML, do JavaScript e do CSS.

Muitas pessoas quando precisam editar alguma coisa do código fonte ficam totalmente perdidas, ou se ocorre algum erro no JavaScript, ou a exibição de um controle não fica como o esperado em um determinado navegador: Pronto! “Isso não dá pra fazer”, “Isso é impossível”, “Isso vai levar muito tempo”, etc; É comum ouvir esse tipo de argumento para substituir “não sei como fazer isso”. A credibilidade dos desenvolvedores Asp.Net (e do próprio Asp.Net) caiu muito há alguns anos devido a esse tipo de desenvolvedor preguiçoso, sem o menor interesse de fazer as coisas certas.

É óbvio que o modelo de desenvolvimento do WebForm incentiva esse tipo de pessoa a pensar assim, mas com o Asp.Net MVC isso é diferente! Para fazer uma boa aplicação em Asp.Net MVC, você deve conhecer como a Web funciona, e hoje vamos entender como controlar a experiência do usuário ao navegar no seu site.

No primeiro post, falei de separação de interesses (SoC), mostrando a importância de se separar as coisas de acordo com o seu contexto. No desenvolvimento de um Site também, esse conceito também deve ser respeitado, não no que tange a interação de objetos, mas na responsabilidade de cada linguagem. As três linguagens básicas para desenvolvimento de um site têm uma razão de ser, foram criadas com um objetivo, e esse objetivo deve ser conhecido e respeitado.

A Web, quando foi pensada, não foi pensada apenas para fazer as aplicações serem acessadas de qualquer lugar, através de um navegador, ela não tem a intenção de trazer as possibilidades de uma aplicação desktop para uma aplicação que roda sobre o Browser. A Web também tem a intenção de prover informações, de ter significado, não apenas ser uma aplicação, portanto, quando dizemos que vamos fazer um site, devemos saber quais informações queremos exibir, e como queremos nos expressar com essas informações.

Para saber como expressar o que queremos dizer na web, devemos saber que em um site, o desenvolvimento é dividido em três momentos, em três definições:

  • Definir o que e como dizer (semântica);
  • Definir como usuário deve ver o que queremos dizer (layout)
  • Definir o comportamento do site para exibir o que queremos dizer e como responder ao que o usuário quer ver (behavior)

Entendendo essas três definições, devemos saber qual linguagem utilizar para cada uma delas, então vamos lá!

HyperText Markup Language – HTML (Semântica)

Nos primórdios das Web, o HTML foi criado para o desenvolvedor poder se expressar. As primeiras páginas basicamente eram textos lineares com texto corridos e eventualmente ligações entre uma página e outra, os navegadores liam o HTML e sabiam o que ele queria dizer, e essa foi a intenção do criado do HTML, se expressar.

Para isso, ele criou tags que têm significados claros e que devem ser usadas para aquilo que elas foram criadas, por exemplo:

  • Se você quiser criar uma parágrafo, você utiliza a tag P (Paragraph).
  • Se você quiser criar uma lista não ordenada, você utiliza uma UL (Unordered List)
  • Se você quiser criar uma lista ordenada, você utiliza uma OL (Ordered List)
  • Se você quiser criar itens de uma lista, ordenada ou não, você utiliza uma LI (List Item)
  • Se você quiser exibir dados de forma tabular, você utiliza uma TABLE.

E assim por diante, conhecendo cada tag do HTML, veremos que cada uma tem um significa para cada necessidade de se expressar.

E para que isso serve? Como diz anteriormente, o HTML faz a Web se expressar, um site que se expressa bem, ou seja, que tem boa semântica, pode ser navegado por um deficiente visual.

Por exemplo: Um programa narrador qualquer vai conseguir ler todo o site para uma pessoa que não consiga ler, e ele vai conseguir diferencia cada texto da página, vai conseguir falar para o usuário: “Título – Lista de Receitas”, se ele encontrar um HTML da seguinte forma “<h1>Lista de Receitas</h1>”, pois a tag H1 significa “Header (Título) de nível 1”, ou vai saber falar para o deficiente “Lista: Pudim, Bolo de Cenoura…” se encontrar um HTML assim: ”<ul><li>Pudim</li><li>Bolo de Cenoura</li></ul>”.

Não é só para leitores de texto que o HTML ajuda, para motores de busca também, como o Google. Esses motores de busca processam o HTML e indexa pelo que ele percebe que é importante na página, por exemplo H1, ou listas.

Se você já ouviu falar de Web Semântica e não sabia o que queria dizer, agora já sabe: Web Semântica é usar o HTML de acordo com o que cada TAG quer dizer. Para isso é muito importante conhecermos cada TAG do HTML, e sabermos que elas servem para organizar informação, e não layout.

Estou falando isso, porque há alguns anos atrás ficou na moda um termo chamado Tableless (sem tabelas em inglês), e de onde veio esse termo?

Entendendo Tableless

Quando o desenvolvimento Web começou a se tornar popular, poucas pessoas sabia para que servia o HTML, e começaram a utilizar as tags conforme bem entendiam, e perceberam que era muito fácil criar divisões na página utilizando tabelas (Tag Table). Mas espera aí, TABLE não é para exibir informações tabulares? Sim, então utilizar tabelas para criar divisões é um erro. Algumas pessoas então resolveram disseminar boas práticas do HTML e criaram esse termo, e mostram para o mundo que divisões em páginas, se criavam com tags DIVs.

Div é uma das poucas tags que não têm semântica de informações, serve apenas para criar blocos de códigos dentro de uma página. Deve ser usada após criar toda a semântica da página, iniciando o processo de design, mas apenas pensando em divisões de informações, e não em divisões de layout. O que quero dizer com isso? Quero dizer que se você sabe que uma informação pode não ser seqüência de outra, você pode utilizar um DIV, pois o designer futuramente pode querer dispor essa informação em um lugar diferente, sem fazer a exibição perder o sentido.

O termo Tableless muitas vezes é mal interpretado, pois as pessoas pensam que é proibido utilizar a tag TABLE, mas não é isso, é não utilizar TABLE para criar layout, divisões, dispor informações e isso estar errado, mas se você quiser em algum momento mostrar realmente uma tabela, mostra dados tabulares, você DEVE utilizar uma tag TABLE, pois semanticamente esse é o correto.

Já presenciei absurdos como utilizar infinitas DIVs para criar uma tabela, e isso está redondamente errado. Lembre-se: Tableless é a aplicação de Web Semântica! E uma coisa não pode contradizer outra!

Se você já ouviu falar de WebStandards saiba que nada mais é do que basicamente a aplicação de Web Semântica, no que tange a HTML.

Tentei mostrar basicamente para que serve HTML, caso você pense que vale a pena falar um pouco mais sobre isso, me fale, que posso falar em outro post. É importante saber que devemos conhecer o maior número de TAGs, para sabermos quando e para que usá-las. É interessante visitar o site da W3C para estudar um pouco sobre as tags e seus atributos, para que nossas páginas fiquem sempre mais inteligentes.

Cascading Style Sheet – CSS (Layout)

O CSS é uma linguagem de estilo ou design. É o CSS que define cor, posição e tamanho dos objetos em uma página Web, ela trabalha em cima da estrutura do HTML, portanto, é muito importante que o HTML esteja bem formado para que o layout seja facilmente manipulado. No Asp.Net, técnicas conhecidas como Tema são aplicados utilizando CSS.

Este blog utiliza a engine BlogEngine.Net. Você já deve ter lido vários Blogs que utilizam a mesma engine, porém, com layouts totalmente diversificados. Isso é possivel com a aplicação de CSSs diferentes. O HTML sempre continua o mesmo, porém a disposição das informações na tela é diferente. O HTML é o mesmo porque a informação que se deseja exibir é a mesma, portanto, a semântica é a mesma, para um deficiente visual, a ordem da informação será a mesma, independente do Layout, apenas o estilo (Layout) da informação variará, o que não altera em nada a semântica do site.

Para a utilização do CSS você pode definir sua implementação dentro de uma tag STYLE ou do atribulo style de uma TAG, porém, o mais comum, e mais recomendado, é a utilização em um arquivo separado, onde o mesmo código pode ser utilizado em várias páginas diferentes, além do arquivo individualmente poder ser utilizado a partir do cache do navegador, tornando o carregamento da página muito mais rápido. Utilizando um arquivo externo para programar o estilo da página, você deve referenciar o arquivo através da tag LINK, normalmente colocada dentro da tag HEAD.

Neste post, o objetivo não é mostrar as características a fundo do CSS, como o objetivo desta série de post é te preparar para o Asp.Net MVC, quero deixar claro que o CSS tem o objetivo de definir o estilo, ou design, da página, e toda configuração nesse sentido deve ser controlado pelo CSS.

Sempre que ao desenvolver uma página você sentir a necessidade de fazer a página ficar mais bonita, pense em CSS. Mesmo que você conheça alguma tag ou configuração HTML que resolva o seu problema, evite utilizá-la. Lembre-se, o CSS é o responsável pelo Design e o HTML pela semântica.

Caso você tenha maior interesse em conhecer CSS, poderá visitar também o site da W3C, ou visitar o ótimo site do Moujor, onde você encontrará muitas informações sobre WebStandards e Tableless.

JavaScript – Comportamento

JavaScript foi criada em 1995 pela Netscape. Sua intenção original era realizar validações em formulários e realizar interações com a página. Através do JavaScript é possível mudar informações do HTML, inclusive informações relacionadas com o CSS, o que é conhecido como DHTML.

Devido a essa capacidade de alterar informações do HTML que ao JavaScript é dado a responsabilidade de controlar o comportamento da página.

Como linguagem, o JavaScript tem algumas características:

  • Apensar de inspirada no Java, mas o conceito é bem diferente.
  • É interpretada e não compilada, ou seja, os erros ocorrerão apenas em tempo de excução.
  • Quanto ao tipo:
    • É fracamente tipada, tem o tipo mutável.
    • É dinâmica, ou seja, o tipo de uma variável muda durante a execução da aplicação.
    • É implícita, ou seja, a variável são declaradas sem tipos.

Como o CSS, o javascript pode definido em uma TAG dentro da página, sendo esta a tag SCRIPT, em um atributo de um tag, sendo este qualquer atributo que leve o nome de um evento, como onclick, ou onblur ou em um arquivo externo, também através da TAG SCRIPT, valorizando o atributo SRC com o endereço do arquivo. Essa técnica tem o mesmo benefício de CSS externos à página, ou seja, ganha desempenho com Cache do navegador e pode ser utilizado em várias páginas.

Para estudar JavaScript, um ótimo site seria o W3Schools, onde você poderá entender como funciona cada características da linguagem, desde a objetos à Garbage Collector.

Uma boa página, com boa interação com o usuário, deve sempre fazer bom uso do JavaScript. O Asp.Net utilizada Javascript onde você imaginar, e framework .Net, com Ajaxtook kit vivem a custa disso.

Com a popularização do JavaScript e do conceito Web 2.0, a necessidade de páginas cada vez mais interativas fez sugir diversas bibliotecas baseadas em JavaScript, que facilitam muito a vida de um desenvolvedor Web, que todos deveriam conhecer ao menos uma. Segue uma pequena lista:

Cada biblioteca JavaScript tem sua característica específica e muitas vezes uma finalidade específica, estude cada uma delas e veja qual é a melhor para o seu problema.

Conclusão

Este post teve a intenção de mostrar qual é o objetivo de cada linguagem de Browser da Web. É importante conhecer a divisão delas, para saber como usar. Quanto melhor a utilização dessas três linguagens, maios rápido vai ser o desempenho da sua página e melhor o tempo de desenvolvimento e manutenção.

Sem essas três linguagens a Web não existiria (Internet não é Web, caso não saibam), e o mal uso dela pode tornar a Web insustentável.

Para um bom desenvolvimento Web, e sem dúvida para um bom desenvolvimento em Asp.Net MVC, o conhecimento delas é impresindível.

Dei mais foco ao HTML (apesar de que ainda é pouco), porque é o que as pessoas mais dizem que sabem, sem nunca terem se questionado se sabem mesmo ao menos o conceito, é o que o eu aviso: Estude, aprenda HTML!

Espero que esse post tenha servido para entender um pouco mais como funciona o desenvolvimento de páginas Web, e te ajude a saber o que estudar para começar com Asp.Net MVC.

Abraços e até o próximo.

18. outubro 2010 07:36 by Frederico | Comments (3) | Permalink

MVC–O padrão.    

Olá pessoal!

Estou planejando para os próximos posts uma pequena série sobre Asp.Net MVC. Uma série para quem é desenvolvedor WebForms, e quer fazer suas primeiras aventuras no mundo MVC. Para isso, vou fazer alguns posts introdutórios, sobre conceitos que um desenvolvedor Web deve saber antes de iniciar suas aventuras em Asp.Net MVC.

Praticamente todos os assuntos tratados nessa posts introdutórios devem ser de conhecimento de qualquer desenvolvedor Asp.Net, porém, muitos dos desenvolvedores WebForms migraram do VB6 sem o menor conceito de Web, por isso, para que não surjam desenvolvedores Asp.Net MVC tão desconhecedores de Web como existe no WebForms, acho interessante esses posts introdutórios.

Os temas serão tratados ao longo de quatro post, como segue:

Caso eu vá percebendo ao longo da escrita desses post a necessidade de mais assuntos, eu posso atualizar a lista acima. Qualquer dúvida quantos aos assuntos tratados, por favor, me avisem.

Então vamos lá!

Separation of concerns (Separação de Interesses)

Antes de começarmos a falar de MVC, devemos falar do que veio antes, que é a idéia de Separation of Concerns (SoC). SoC é o processo de agrupar códigos com características distintas, separando em blocos de códigos especialistas, responsáveis por interesses específicos.

Se falarmos em orientação a objetos, seria deixar cada objeto responsável apenas por aquilo para o que ele foi criado, conhecendo apenas o seu escopo, e interagindo com outros objetos quando necessário para realizar atividades fora do seu escopo de conhecimento.

Normalmente isso é feito através de padrões de projetos (Design Patters), implementável em qualquer linguagem, e em qualquer paradigma, não apenas em Orientação a Objetos, como Linguagens Procedurais, ou em programação orientada a serviços.

Entre muitos padrões que implementam SoC, existe o MVC, que vamos falar no próximo tópico.

MVC, o que é?

MVC é a sigla para Model View Controller, um Design Pattern que implementa o conceito de SoC. MVC não foi criado pela Microsoft e muitos menos é algo exclusivo do Asp.Net. É um padrão de projeto que existe desde 1979, originalmente utilizado em uma antiga linguagem chamada Smalltalk.

Sua implementação é possível em qualquer ambiente que tenha interface de usuário, ou seja, não é aplicável apenas em Web, inclusive sua utilização foi muito disseminada em aplicações Desktop, devido a complexidade das telas, onde era necessário existir um padrão para facilitar a manutenção.

A idéia do MVC é separar a lógica de apresentação da lógica de negócio, e fazer com que uma lógica não conheça a outra. Dessa forma, é possível alterar a interface (podendo mudar inclusive de Desktop para Web, por exemplo), sem ter necessidade de alterar a lógica de negócio, ou vice-versa.

Cada parte ficaria da seguinte forma:

Model – Define o domínio do negócio, muitas vezes representado pelo Modelo de Dados (não é o mais correto, mas com tantos ORMs por ai, acaba sendo o que acontece), ou entidades de negócio, como por exemplo Cliente, ContaCorrente,  etc. As operações de negócio fazem parte do Model (Domínio da aplicação), ou seja, um método para obter o saldo de uma conta corrente faz parte do domínio e está no Model do MVC. O Model conhece apenas o que diz respeito a ele, ou seja, não sabe quem está visualizando os dados ou para que os dados estejam sendo visualizados.

View – Define uma visão do Modelo (Model), de acordo com a necessidade de um usuário. Muitos acham que a View no MVC é sempre uma tela (Página na Web ou Formulário no Desktop), mas na realidade vai muito além disso, qualquer tipo de exibição de dados de um modelo é chamado de View. Pensando em uma aplicação Web, poderia ser: A própria página (mais comum), um relatório (em qualquer formado – PDF, Excel, etc), um arquivo (TXT, XML), um formado de dados (JSON), enfim, qualquer representação do domínio de negócio que seja necessário para representar uma necessidade da aplicação. Várias Views podem existir para o mesmo Model

Controller – Faz o meio campo entre o Model e a View, é ele quem sabe qual View gerar de acordo com uma entrada específica. Ele conhece a View e o Model na aplicação. Um Controller geralmente é invocado a partir de uma View gerada por um Controller anterior.

Abaixo segue uma ilustração retirada do Wikipédia.

image

Falando um pouco de Web, existem muitos frameworks que implementam o padrão MVC, um dos mais conhecidos é o Ruby On Rails, inclusive é um dos que mais inspiraram a criação do Asp.Net MVC. Em Asp.Net já existia MVC desde o .Net 1.1, mas em iniciativas particulares, como o Monorail. Nas demais tecnologias Web, como Java, PHP, Asp 3, etc; também existem framework MVC disponíveis.

É importante conhecer bem o padrão MVC, para que ao desenvolver uma página nesse conceito, você não fique perdido em relação de onde colocar suas informações, seria interessante estudar um pouco de outro padrões, como DDD (Domain Driven Design), que não pretendo abordar nesta série de posts, mas que ajuda muito a modelar seu Domínio (Model), sem sempre trabalhando apenas no Modelo de Dados (Com frameworks ORM, como NHibernate ou Entity Framework).

Desenvolvendo MVC sem conhecer bem o padrão MVC, você cai no risco de misturar conceitos, como é comum acontecer com Orientação a Objetos, onde muita genta fala que trabalha com OOP só porque a linguagem dá suporte, mas acaba programando sempre proceduralmente.

Bom para introduzir o conceito MVC, acredito que esse Post seja suficiente, caso necessite de mais informações, faça um comentário logo ali abaixo.

Até o próximo.

13. outubro 2010 07:42 by Frederico | Comments (2) | Permalink

IE9 beta–Algumas coisas ainda podem melhorar    

Resolvi dar uma olhada no IE9 beta esse feriado, e definitivamente ela está melhor que o IE8. O que mais me agrada nas novas versões do IE é a Developer ToolBar. Na versão 9 ela dá a possibilidade de renderizar as páginas no padrão IE 7, 8 e 9, o que é uma baita vantagem para quem tem que trabalhar com CSS.

Existem várias novas funcionalidades, como você conseguir mover/separar/unir as Tabs da forma que  quiser, entre outras, coisas, que deixam o navegador realmente muito interessante.

No lado do desenvolvimento, achava a renderização do IE8 bem legal, semelhante ao resultado do Chrome, no IE 9 algumas páginas já pararam de renderizar corretamente (em relação ao IE 8, é claro). Isso pode ser bom ou ruim, depende do ponto de vista.

De qualquer forma, resolvi escreve esse rápido post, para mostrar que eles ainda têm que melhorar a renderização, não vou falar do teste do peixinho, que realmente é melhor que o Chrome (e que em outros navegadores chega a travar tudo), mas na navegação entre os sites, como UOL, Youtube, etc; tive a impressão de que o Chrome continua ainda mais rápido. Meio estranho isso, mas tudo bem, o que quero falar é do teste Acid3.

Esse teste basicamente testa a compatibilidade com os padrões W3C. Em relação ao IE8 e 7, a melhora do IE9 é absurda, nas versões anteriores, o IE praticamente não conseguia renderizar a página. Agora ele está batendo quase 100%.

É importante deixar claro que ainda é uma versão beta, e a Microsoft tem sempre ouvido os feedbacks da comunidade, então eu acho que esse teste, assim como todas as outras características do IE9, deve melhorar bastante até a versão final, mas vamos ao testes.

Neste teste o Chrome e o Safari ainda se dão melhor. Conforme os prints abaixo:

IE9:

image

Opera:

image

Safari:

image

Firefox:

image

Chrome:

image

 

Pode testar você mesmo: http://acid3.acidtests.org/

Abraços e até o Próximo!

13. outubro 2010 05:52 by Frederico | Comments (0) | Permalink

Stopwatch – Como controlar a performance do seu código.    

Boa noite pessoal, hoje vou com um post pequeno, porém, de muita importância para as pessoas. Na minha experiência, vi que muitas pessoas, inclusive eu algumas vezes, não sabem muito bem como medir desempenho dos códigos. Muitas vezes, quando as pessoas querem saber quanto tempo dura uma execução de um código, acabam utilizando as classes DateTime e/ou TimeSpan.

Na realidade é comum armazenar um DateTime.Now antes do método a ser verificado e subtrair o valor de um novo DateTime.Now do final do código. Da seguinte Forma:

	static void Main(string[] args)
        {

            var ini = DateTime.Now;

            DoWork();

            var fim = DateTime.Now.Subtract(ini);

            Console.WriteLine("Tempo total: {0}", ini.TimeOfDay.Milliseconds);

            Console.ReadKey();
        }

        private static void DoWork()
        {
            foreach(string dir in Directory.GetDirectories(@"C:\")){

                Console.WriteLine(dir);
            }
           
        }

Até parece funcionar, porém, utilizando este código para verificar desempenho, você já está perdendo desempenho, porque o DateTime é uma estrutura um pouco complexa para uma simples validação de tempo decorrido, além da necessidade de fazer uma subtração também ter um certo custo para o trabalho.

Agora, se utilizarmos a classe Stopwatch, muita coisa pode mudar. Além de ser uma classe muito mais simples, o seu intuito é realmente controlar tempos decorridos. Sua performance é muito melhor, e se alterarmos o código acima para utilizar Stopwatch, veremos que o tempo decorrido é bem menor. Na realidade o tempo exibido é bem mais correto, porque utilizando DateTime, muito do tempo perdido é para a criação da estrutura do DateTime.

Com o Stopwatch ficaria assim:

	static void Main(string[] args)
        {

            var tempo = new Stopwatch();

            tempo.Start();

            DoWork();

            tempo.Stop();

            Console.WriteLine("Tempo total: {0}", tempo.Elapsed.Milliseconds);

            Console.ReadKey();
        }

Se você executar os códigos acima, verá que o tempo decorrido com o Stopwatch é muito inferior. Além da utilização ser mais simples.

A classe Stopwatch, localizada no namespace System.Diagnostics, tem métodos muitos simples. Basicamente você começa a controlar o tempo invocando o método Start e quando desejar parar de controlar o tempo decorrido invoca o método Stop.

Para validar o tempo decorrido, você utiliza as propriedades Elapsed, que retorna um TimeSpan, ou a propriedade ElapsedMilliseconds, que retorna os milissegundos decorridos, ou a propriedade ElapsedTicks, que, adivinhem só, retorna os Ticks decorridos desde o Start.

O Stopwatch pode ser utilizado para o controle de vários intervalos de tempo. Para utilizar dessa forma, você pode simplesmente invocar o método Start novamente após o Stop, e o contador do tempo decorrido continuará sendo contado a partir do ponto onde parou, ou seja, o Stop funciona como uma pausa na contagem do tempo decorrido. Se você realmente quiser reiniciar o contador, deve invocar o método Reset.

Além do que já foi falado, o Stopwatch tem apenas mais uma propriedade que não comentei, a propriedade IsRunning, que retorna um booelano indicando se o contador está rodando ou não.

Para finalizar, é possível simplificar ainda mais o código, utilizando o método estático StartNew da classe Stopwatch para criar a estância da classe e já invocar o método Start automaticamente, o código fica um pouco mais simples, repare:

	static void Main(string[] args)
        {
	    //A linha abaixo substitui a invocação do new() e do Start()
            var tempo = Stopwatch.StartNew();
            
            DoWork();

            tempo.Stop();
            
            Console.WriteLine("Tempo total: {0}", tempo.Elapsed.Milliseconds);

            Console.ReadKey();
        }

Bom, fica ai a dica de quando você precisar controlar a performance do seu código. É muito mais simples, mais rápido e mais correto utilizar o Stopwatch ao invés do DateTime ou outra técnica qualquer para controlar tempos decorridos.

Espero que possa ajudá-los.

Até o próximo post.

7. outubro 2010 08:11 by Frederico | Comments (1) | Permalink

Entendendo o JQuery ready() e live()    

Quando estamos aprendendo JQuery, a primeira coisa que aprendemos é que todo código de inicialização é colocado no método ready, porém, muitas vezes não nos perguntamos o porque isso é feito dessa forma.

Quem nunca viu um navegador lento renderizar a página toda torta e depois de alguns segundos sumir com tudo, deixando tudo organizado?

Com certeza isso é devido à má utilização do método ready(), ou desconhecimento do método live().

JQuery.ready(), como funciona?

Muitos pensam que o ready é executado quando a página é carregada por completo, porém, esse pensamento não está certo.

O JavaScript tem nativamente um método que é executado quando a página está carregada por completo, e esse método é o window.onload, que muitas vezes utilizamos na tag body através do evento onload. O método ready do JQuery não substitui esse método, e nem executa no mesmo instante.

Para o navegador a página está totalmente carregada quando todos os recursos da página estão carregados, e isso inclui todos os arquivos externos, como scripts, música e imagens. Apenas quando todos os recursos estão carregados o navegador invoca o evento Load da janela, ou seja, caso a página esteja carregando um script ou uma imagem muito grande, dependendo do navegador, toda a página pode ser exibida, porém, o Load pode não ser chamado ainda. (Obs.: Dependendo do navegador porque existem alguns navegadores que só exibem a página quando todos os recursos da página estão carregados em memória).

Diferente do Onload, o ready executa quando a estrutura do documento está pronta, ou seja, quando o DOM foi carregado por inteiro, mesmo que os recursos da página, como scripts e imagens, ainda não tenham sido carregados. Isso pode acontecer porque muitos navegadores modernos carregam os recursos de forma assíncrona, ou seja, exibe a página, apenas com CSS e texto, por exemplo, e vai carregando imagens paralelamente, sem impedir que o usuário possa começar a ler o conteúdo da página.

Já aconteceu comigo de utilizar um plugin JQuery que carregava os scripts necessários por demanda, e muitas vezes, ao chamar a criação do plugin no método ready, era retornado o erro O objeto não dá suporte para a propriedade ou método, isso porque o arquivo que continha o plugin que eu tentava chamar ainda não estava carregado. Portanto, se você carrega arquivos de forma dinâmica, o ready não é uma boa opção.

Caso seja realmente interessante carregar scripts dinamicamente, crie métodos com callbacks que indiquem que os arquivos já foram carregados, para ai sim você poder atribuir eventos e plugins aos controles.

JQuery.live(), quando usar?

Agora que já entendemos como funciona o método ready(), podemos conhecer o live().

Imagine que você realmente precise carregar algumas informações assíncronas para criar a tela, por exemplo, as informações para criar tabs carregam de um arquivo de acordo com um script de globalization, que é carregado depois que o navegador identifica a linguagem do browser, ou imagine que alguns trechos do seu HTML serão adicionados/carregados, depois que o DOM já está pronto, e portanto, depois que o ready já executou, ou você não quer correr o risco que um browser renderize o começo da página antes de montar todo o DOM, e o começo da página em vez de exibir suas tabs, exiba uma lista (LI) de palavras, pois o ready não executou ainda e você não pôde ligar os métodos dos plugins.

Essas situações podem acontecer e é aí que você utiliza o live.

O live() gerencia eventos em controles que são dinamicamente adicionados ou removidos de uma página, você pode utilizar a chamada live em controle que nem existem ainda, mas que virão a existir durante a vida da página.

Por exemplo, o código abaixo:

<script type="text/javascript">
$().ready(function () {
        $("input:button").click(function () {
            alert(this.value);
            $("<input value=""+$("input:button").length+"" type="button" />").appendTo("#div");
        });
    });
</script>
<div id="div">
    <input type="button" id="btnClick" value="Botao1" />
    </div>

O código acima, do jeito que está, dentro de um ready, sempre que for clicado no primeiro botão, será exibido um alerta com o value do botão, e adicionará um novo. Porém, ao clicar nos adicionados, nada acontecerá, porque uma vez adicionado evento ao botão na criação do DOM, nada mais vai acontecer, porém, com o método live, os controles adicionados dinamicamente também irão receber o evento.

O código ficaria assim:

 

 

<script type="text/javascript">
$("input:button").live("click",function () {
            alert(this.value);
            $("<input value=""+$("input:button").length+"" type="button" />").appendTo("#div");
        });
</script>
<div id="div">
    <input type="button" id="btnClick" value="Botao1" />
    </div>

Desta forma, sempre que for adicionado um novo controle, o novo controle automaticamente irá receber o evento. Isso pode ser muito útil para controle como grid, por exemplo.

Identificando todas as situações onde o live poderia ser utilizado, poderíamos tirar bastante processamento do ready, o que deixaria o processamento da página muito mais rápido, pois os eventos já seriam adicionados ao controle no momento da criação, não só quando o DOM fosse totalmente criados. Fora que mesmo que fossem criados dinamicamente, como exemplificado acima, os eventos já seriam adicionados, poupando alguma quantidade de código, e deixando o documento menor.

E um detalhe interessante, você pode adicionar vários eventos ao mesmo tempo com o live, apenas separando os nomes dos eventos com espaço, por exemplo:

$("input:button").live("mouseover mouseout",function () {...

Conclusão

Nem tudo que a gente aprende no começo é a melhor coisa a se fazer em todas as situações. Nesse post não consegui abordar todos os prós e contras do live e do ready, mas dando uma estudada melhor na biblioteca do JQuery vamos descobrir muitas coisas interessantes.

Vou voltar a falar mais coisas sobre essa biblioteca incrível nos próximos post, tentando sempre melhorar o conhecimento dos métodos que facilitam nossa vida no JavaScript.

Fica ai a dica!

Abraços e até o próximo post.

30. setembro 2010 04:33 by Frederico | Comments (5) | Permalink

O que são Lambda Expressions?    

Lambda Expression para muitos pode ser um assunto simples, uma pratica simples, porém, sempre que começo a usá-las em meu código, vejo muitas interrogações nas pessoas em minha volta, e participando do TechEd neste ano, pude perceber que isso é muito comum, porque quando estava saindo de uma palestra do Otavio Pecego Coelho, sobre paralelismo, ouvi muitas pessoas comentando: “Putz, muito louco, mas quando começa a entrar um monte de ‘Lambda’ começa a ficar meio complicado.” .Bom, não sei como isso pode ser possível, visto que Lambda Expression só veio para facilitar, como veremos ao longo desse post.

Pensando nisso, e conversando com um amigo meu, ele me deu a sugestão de escrever sobre isso aqui, e lá vai. Caso tenham dúvidas ou sugestões, please let me know!

Um pouco do histórico

As expressões Lambdas não são uma grande inovação do time do .Net, na realidade, como a maioria das novidades que surgiram entre o .Net 3.0 e 3.5, elas são evoluções naturais dos rumos que a C# vinha tomando desde a sua criação. Vamos ver como isso aconteceu.

Delegates

Delegate é o princípio de tudo. Delegate resumidamente é um tipo por referência, que armazena ponteiros para métodos. Com a criação de uma Delegate, você defini a assinatura de um método que pode ser armazenado em uma variável do tipo dessa Delegate, ou seja, os métodos “apontados” nas variáveis de tipo Delegate devem seguir as regras definidas na Delegate.

Podemos usar Delegates para “delegar” a responsabilidade de execução de uma lógica específica a um outro método, que pode ser implementado depois.

A definição de uma delegate é a seguinte:

[modificador] Delegate [tipo de retorno [Nome da Delegate] ([parâmetros de entrada])

public delegate int Conta(int v1,int v2);

Definindo essa Delegate, qualquer método que tenha essa assinatura pode ser delegado a uma variável do tipo Conta. Os eventos basicamente utilizam Delegates para definir qual deve ser a assinatura de um método que implementa um evento. A Delegate do evento basicamente é a seguinte:

public delegate void Evento(object sender, EventArgs args)

E como podemos utilizar? O exemplo padrão sempre é o da calculadora. Imagina que queiramos delegar ao usuário a opção de escolher qual operação ele deseja executar. Vamos criar dois método, Somar e Subtrair. O código completo de uma aplicação console está abaixo:

    delegate int Conta(int v1,int v2);
    class Program
    {
        static int Soma(int valor1, int valor2)
        {
            return valor1 + valor2;
        }
        static int Subtrair(int valor1, int valor2)
        {
            return valor1 + valor2;
        }

        static void Main(string[] args)
        {
            Console.Write("Valor 1:");
            var v1 = Console.ReadLine();
            Console.Write("Valor 2:");
            var v2 = Console.ReadLine();
            Console.Write("Operação(+ ou -):");
            var op = Console.ReadLine();

            //Operação padrão é soma
            Conta operacao = Soma;

            switch (op)
            {
                case "+":
                    operacao = Soma;
                    break;
                case "-":
                    operacao = Subtrair;
                    break;
            }

            //Chamo o método que o usuário selecionou, sem me importar qual é
            var ret = operacao(Convert.ToInt32(v1), Convert.ToInt32(v2));

            Console.WriteLine("Resultado: {0}", ret);
            Console.ReadKey();
        }
    }

Assim estamos delegando ao usuário qual método utilizar. Com esse entendimento, podemos já perceber, como a equipe do C# percebeu, vários momentos onde utilizar ponteiros de métodos por parâmetro.

Obs.: Como Delegate obriga a implementação de uma assinatura, por isso os tipos e a quantidade de parâmetros são importantes, porém não o nome dos parâmetros.

Em Collections podemos ver o uso desta técnica em muitos métodos, por exemplo, o Sort, Find, etc. A equipe do .Net teve o segundo dialogo (obviamente o dialogo seguinte é inventado):

“Por que não podemos ter um Collection qualquer, e deixar que o programador se preocupe em como ordenar? “

“Sim, e para isso ele passa por parâmetro o método, desde que ele implemente a assinatura, respeitando uma Delegate”

Certo, então da mesma forma que podemos criar variáveis de tipos de Delegate, podemos utilizar parâmetros de tipos Delegate. Por exemplo, para utilizar o método Find, implementamos uma Delegate chamada Predicate, inclusive a utilização dos métodos de Collection são de predicados por esse motivo.

public delegate bool Predicate(T obj);

Onde T é o tipo da sua lista, ou seja, uma lista List<int> o T seria int. A implementação do método abaixo seria a seguinte:

	static bool Buscar(int valor)
        {
            return valor == 1;
        }

Sua chamada seria a seguinte:

           List<int> lista = new List<int>();
            //alimenta a lista
            
            var itemEncontrado = lista.Find(Buscar);

Certo, com isso entendemos como funciona uma Delegate, então vamos evoluir até chegar a Lambda Expression.

Métodos Anônimos

A equipe do C# percebeu que a adoção de Delegates era muito boa, porém, é um tanto trabalhosa, pois você precisa criar métodos sempre que precisar utilizar Delegate, o que te faz ter que digitar mais, e o seu código pode ficar mais confuso.

Imagine que você precisa realizar a busca citada acima apenas em um trecho especifico de código, você teria a necessidade de criar um método, mesmo que sua utilização fosse extremamente restrita, e o pessoal da Microsoft pensou: “Por que não criarmos apenas o código do método, e não o método em si? Ficaria mais simples e mais rápido”.

Ótimo idéia, e assim entra o método anônimo no jogo.

Métodos anônimos são métodos, como o próprio nome diz, sem nomes. São métodos criados dentro de outros métodos, adicionando seu conteúdo diretamente em uma variável ou parâmetro do tipo Delegate.

Por exemplo, em vez de criarmos o método Busca acima, poderíamos colocar o seu código diretamente na chamada do método:

	var item = lista.Find(delegate (int valor){
                return valor == 1;
            });

O resultado seria o mesmo, com a diferença de não precisarmos criar um novo método na classe. Essa técnica pode ser utilizada em qualquer situação onde usaríamos o método ponteiro para a Delegate, ou seja, variáveis, parâmetros, eventos, etc.

Finalmente Lambda Expression

Bom, diante de tudo que vimos acima, percebemos que codificar “on the fly” dessa forma agiliza muito o processo de desenvolvimento, além de não deixar códigos muito específicos por toda parte da classe.

Mas ai ainda percebemos que digitamos muito além do necessário. Pensa comigo:

“Para que a palavra chave “delegate”? Afinal, eu já sei que é uma delegate.”

“Para que ter que definir o tipo do parâmetro?” Afinal, se o compilador já sabe qual é a Delegate a ser utilizada, logo ele já sabe quais são os os tipos e a quantidade dos parâmetros.”

“E as vezes o método é tão simples, que a única linha já é o retorno, então para que utilizar o return?”

Aí mais uma vez o time do C# deu uma forcinha, dizendo: “Vamos simplificar tudo criando um novo operador que serve para separar os parâmetros do método do corpo do método e pronto!”

E o Find da Collection ficou assim:

var item = lista.Find(valor=>valor == 1);

Agora sim o método ficou sucinto, o que está antes do => (igual maior) são os parâmetros de entrada, e o que está depois é o retorno do método caso tenha só uma linha, ou o corpo do método, caso tenha mais de uma linha.

Se quisermos criar uma Lambda Expression para nossa delegate Conta criada acima, seria o seguinte:

 
operacao  = (valor1, valor2)=> valor1 + valor2;
var ret = operacao(Convert.ToInt32(v1), Convert.ToInt32(v2));

Muito simples! Perceba que para mais de um parâmetro, adicionamos parênteses. Caso o corpo do método seja mais complexo, com mais de uma linha, teremos que utilizar chaves e no final utilizar a palavra chave return.

Conclusão

Neste post vimos como Lambda Expression nada mais é que uma evolução natural das técnicas utilizadas pelo C# desde sua primeira versão.

Por ser uma evolução, isso só pode surgir para ajudar e simplificar nossa vida. Caso não esteja sendo claro em nossas cabeças as evoluções que a linguagem vem tomando, é importante que entendamos o porquê das mudanças.

Muitos já criticaram o “dynamic” do C#, sem ainda entender o porque de se utilizá-lo. Vou tentar abordar isso em um momento oportuno.

Bom, espero que tenham gostado desse post.

Até o próximo!

24. setembro 2010 06:51 by Frederico | Comments (4) | Permalink

Sobre mim

Minha Imagem

Meu nome é Frederico Batista Emídio, trabalho com desenvolvimento de sistemas profissionalmente a oito anos, porém, já faço sites pessoais a pelo menos dez anos.

Para saber mais clique aqui.

Páginas

Calendário

<<  novembro 2017  >>
seteququsedo
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

Visualizar posts em um Calendário
Sigua @fredemidio

MCP Asp.NET