Palestra sobre ASP.Net SignalR + Demos + Vídeo

Palestra sobre ASP.Net SignalR ministrada no Visual Studio Summit 2013.

ASP.Net SignalR

Desde que comecei a estudar ASP.Net SignalR me interessei muito e se tornou um dos meus assuntos favoritos, acompanhe aqui como foi minha palestra:

Vídeo da Palestra

Eu ainda não sou o bom palestrante que desejo ser, mas um dia chego lá 🙂

Slides

Demos (compatíveis com VS 2012)

*Jogo da velha original foi baixado aqui. Fiz melhorias, correções e complementos para demonstração.

Quer conhecer mais sobre ASP.Net SignalR? Leia o meu artigo aqui.

O Visual Studio Summit é um dos maiores eventos sobre desenvolvimento na plataforma Microsoft, assista todas palestras da edição 2013 aqui.

Deixe seu feedback logo abaixo 🙂
Abraços!

ASP.Net MVC – ViewData, ViewBag e TempData

ASP.Net MVC – ViewData, ViewBag e TempData entenda as diferenças.

Quando usar ViewData, ViewBag e TempData? Essa é uma das primeiras perguntas que qualquer desenvolvedor faz quando inicia nos aprendizados do ASP.Net MVC.

UPDATE – 13/06 – Adicionando detalhes/correções fornecidos pelo @vcavalcante

Vamos basear nossa explicação conforme a ilustração

ViewData, ViewBag, TempData

Similaridades entre ViewData e ViewBag

ViewData e ViewBag são similares nas seguintes características:

  • São utilizadas para persistir dados entre a Controller e a View correspondente.
  • A duração “tempo de vida” é apenas entre o envio através da Controller e a exibição na View, depois disso tornam-se nulas novamente.
  • No caso de um redirect se tornam nulas.

Diferenças entre ViewData e ViewBag

ViewData ViewBag
É um dicionário de objetos derivado de ViewDataDictionary e é acessível utilizando strings como chaves. É uma propriedade dinâmica baseada na funcionalidade “dynamic” do C# 4.0
Requer typecasting (conversão) quando associada a tipos complexos. Não necessida de conversão para tipos complexos.

Exemplos de aplicação

Controller

public class HomeController : Controller
{
    public ActionResult Index()
    {
        // Meu dado de tipo complexo
        var func = new Funcionario
                        {
                            Nome = "Eduardo Pires",
                            Idade = 31
                        };

        // Propriedades "Dinâmicas"
        ViewBag.Funcionario = func;

        // Modo tradicional
        ViewData["Funcionario"] = func;

        return View();
    }
}

View

@model ProjetoModelo.Models.Funcionario;

@{
    ViewBag.Title = "Exemplo ViewData ViewBag";

    // Necessita de TypeCasting
    var viewDataVariavel = ViewData["Funcionario"] as Funcionario;

    // Não necessita de TypeCasting
    var viewBagVariavel = ViewBag.Funcionario;
}

Resumindo, ViewData e ViewBag possuem a mesma proposta, porém o ViewBag está disponível a partir do ASP.Net MVC 3, enquanto o ViewData existe desde a primeira versão.

OBS: O ViewData é um wrapper, uma implementação do ViewBag, pois utiliza o ViewBag internamente, portanto:

// Criar o ViewBag:
ViewBag.Teste = "Eduardo";

// É o mesmo que criar um ViewData["Teste"],
// pois o ViewData é utilizado internamente. Se chamarmos:

var teste = ViewData["Teste"]; // Teremos teste = "Eduardo";

Por este motivo ViewData é mais rápido que o ViewBag, porém essa diferença de velocidade é mínima, não é necessário deixar de usar o ViewBag por este motivo.

Eu preferencialmente sempre utilizo ViewBag

TempData

  • TempData assemelha-se mais a uma sessão de servidor, porém de curta duração.
  • Possui um tempo de vida maior que o ViewBag e ViewData, o TempData perdura desde sua criação até que seja chamado, ou seja, quando houver um request da informação do TempData, ele se tornará nulo novamente.
  • Uma informação em TempData criada em um Controller persiste após um redirect entre actions (apenas um) e pode ser exibido em sequência em uma View (muito usado em tratamento de erros).
  • Caso não seja chamado o TempData pode manter o estado de seus dados até que a sessão do usuário se encerre.
  • É utilizado para compartilhar informações entre Controllers.
  • O TempData salva suas informações no SessionState do servidor.
  • Após a leitura os dados do TempData são marcados para deleção, ou seja, no final do request todos os dados marcados serão deletados.
  • É um benefício quando necessário transmitir um volume de informações entre as Controllers sem se preocupar em zerar os valores, pois o TempData automaticamente faz isso.

Exemplo de aplicação

Controller

public class HomeController : Controller
{
    [HttpPost]
    public ActionResult CriarFuncionario(Candidato cd)
    {
        // Meu dado de tipo complexo
        var func = new Funcionario
                        {
                            Nome = cd.Nome,
                            Idade = cd.Idade
                        };

        // Pertistir dados até o próximo request.
        TempData["Funcionario"] = func;

        // Redirect entre Controllers
        return RedirectToAction("CriarBeneficiosFuncionario");
    }

    [HttpGet]
    public ActionResult CriarBeneficiosFuncionario()
    {
        // Validando se está vazio
        if (TempData["Funcionario"] != null)
        {
            // Necessário TypeCasting para tipos complexos.
            var func = TempData["Funcionario"] as Funcionario;
        }

        return View();
    }
}

Neste exemplo pudermos entender que o propósito do TempData é compartilhar dados entre Controllers, portanto sua duração persiste até que a informação seja lida.
Outro detalhe é sempre checar se o TempData não está nulo.

Caso você queira manter o dado de um TempData mesmo após a leitura, basta chamar o método Keep(), assim o dado será persistido novamente até a próxima requisição.

// Mantendo o dado do TempData até a próxima leitura (requisição).
TempData.Keep("Funcionario");

// Removendo o dado do TempData desta e da próxima requisição.
TempData.Remove("Funcionario");

Recomenda-se utilizar sempre ViewBag e ViewData para transferência de dados entre Controller e View. O TempData em Views é recomendado no caso de um dado necessitar ser redirecionado entre Actions e posteriormente ser exibido numa View (ViewBag e ViewData são anulados em redirects).
Um caso comum dessa aplicação é no tratamento de erros, veja aqui um exemplo.

Espero ter esclarecido as diferenças e características de ViewData, ViewBag e TempData. Caso tenha alguma dúvida ou queira comentar algo, deixe seu recado logo abaixo 😉

Referências

Vou palestrar no evento de 10 anos do Codificando.Net

Olá Pessoal,

O Codificando.Net é uma das maiores comunidades de desenvolvedores de software e está comemorando seus 10 anos com um evento presencial.

O evento terá diversas apresentações sobre Desenvolvimento Web, SQL, Business Intelligence e Cloud Computing.

O tema da minha palestra será Comunicação em tempo real usando ASP.NET SignalR

Esta é mais uma ótima oportunidade de aprender, conhecer as novidades, fazer contatos e trocar conhecimentos com a comunidade técnica.

Informações

O dinheiro arrecadado com as inscrições do evento, cobrirão o coffee-break e a compra de alimentos não perecíveis para doação à instituição de caridade (à definir).

Espero você lá!

 

Orientação a Objeto – SOLID

SOLID é um acrônimo dos cinco primeiros princípios da programação orientada a objetos e design de código identificados por Robert C. Martin (ou Uncle Bob) por volta do ano 2000. O acrônimo SOLID foi introduzido por Michael Feathers, após observar que os cinco princípios poderiam se encaixar nesta palavra.

São eles:

Letra Sigla Nome Definição
S  SRP Principio da Responsabilidade Única Uma classe deve ter um, e somente um, motivo para mudar.
O  OCP Princípio Aberto-Fechado Você deve ser capaz de estender um comportamento de uma classe, sem modificá-lo.
L  LSP Princípio da Substituição de Liskov As classes base devem ser substituíveis por suas classes derivadas.
I  ISP Princípio da Segregação da Interface Muitas interfaces específicas são melhores do que uma interface única.
D  DIP Princípio da inversão da dependência Dependa de uma abstração e não de uma implementação.

Os princípios SOLID devem ser aplicados para se obter os benefícios da orientação a objetos, tais como:

  • Seja fácil de se manter, adaptar e se ajustar às alterações de escopo;
  • Seja testável e de fácil entendimento;
  • Seja extensível para alterações com o menor esforço necessário;
  • Que forneça o máximo de reaproveitamento;
  • Que permaneça o máximo de tempo possível em utilização.

Utilizando os princípios SOLID é possível evitar problemas muito comuns:

  • Dificuldade na testabilidade / criação de testes de unidade;
  • Código macarrônico, sem estrutura ou padrão;
  • Dificuldades de isolar funcionalidades;
  • Duplicação de código, uma alteração precisa ser feita em N pontos;
  • Fragilidade, o código quebra facilmente em vários pontos após alguma mudança.

Os princípios SOLID deveriam ser aplicados por qualquer desenvolvedor maduro, porém pouquíssimos profissionais preocupam-se em utilizá-los, sugiro que crie um sistema simples e utilize estes princípios para treinar, será uma experiência gratificante.

Este é apenas o artigo introdutório sobre SOLID, nos próximos abordarei cada princípio em um artigo separadamente, explicando e demonstrando com código e exemplos a proposta de cada um, continue acompanhando 😉

Referências:

ASP.NET SignalR – Introdução e Utilização

O ASP.NET SignalR é uma biblioteca open-source que facilita a implementação de comunicação em tempo real, atualizações/notificações de forma assíncrona em uma aplicação.

Foi desenvolvido por dois funcionários da Microsoft – Damian Edwards e David Fowler, todo o código fonte do projeto está disponível no GitHub

Há um certo tempo foi incorporado pela plataforma ASP.Net, sendo:

ASP.Net SignalR

Funciona através de uma biblioteca Server Side (ASP.Net) e uma Client Side (Javascript), é suportado em aplicações do tipo Silverlight, Windows Phone 7 e 8 e WinRT. Veja a lista completa de plataformas suportadas aqui.

Quem já precisou desenvolver uma aplicação real-time conhece as dificuldades de manter um certo volume de conexões do servidor, manipular a maneira que o servidor trata as requisições, garantir que o client esteja exibindo as informações no tempo certo e enfim.

Existem alguns meios de implementar uma comunicação em tempo real (Long Polling, WebSockets, Node.js) todas essas técnicas/tecnologias possuem sua complexidade ou limitação técnica, o SignalR propõe a facilitar a implementação da comunicação real-time em sua aplicação.

O que é uma aplicação real-time?

É uma aplicação onde a informação chega em tempo real, imagine um chat ou um ticker de cotação da bolsa de valores, essas informações estão sendo distribuídas em tempo real para todos os clientes consumidores da aplicação.
Para se desenvolver uma aplicação em tempo real é necessário que o servidor seja capaz de sensibilizar todos os clientes conectados assim que uma informação chegar.

Como funciona?

O ASP.Net SignalR é uma abstração de uma conexão, ele trabalha por baixo dos panos definindo o melhor tipo de transporte em dois níveis diferentes de abstração o que ocasiona uma impressão de uma conexão persistente.

ASP.Net SignalR

Transportes

Um dos grandes pontos do ASP.Net SignalR é sua capacidade de gerenciar a escolha do tipo de transporte a ser utilizado.

Como mostra a figura existem quatro tipos de transportes disponíveis:

  1. WebSockets
  2. Long Polling
  3. Server Sent Events
  4. Forever Frame

Lendo a documentação do ASP.Net SignalR iremos entender que fica a cargo dele encontrar o transporte mais eficaz entre um server/client, dando sempre preferência por WebSockets quando disponível e caso não esteja disponível parte para Long Polling e os demais em sequência.

WebSocket é uma tecnologia que permite a comunicação bidirecional por canais full-dulplex sobre um único soquete Transmission Control Protocol (TCP). Ela foi projetada para ser executada em navegadores e servidores web que suportem o HTML5, mas pode ser usado por qualquer cliente ou servidor de aplicativos. A API WebSocket está sendo padronizada pelo W3C e o protocolo WebSocket está sendo padronizado pelo IETF.

Sendo assim apesar de termos tipos de transportes variantes o código fonte é sempre o mesmo, a responsabilidade de escolher o tipo de transporte fica por conta do SignalR, porém existe disponível uma maneira de definir o uso de um transporte específico.

Comunicação com PersistentConnection e Hubs

O ASP.Net SignalR oferece dois níveis de abstração de comunicação entre clientes e servidores, sendo o Hubs de alto nível e PersistentConnection de baixo nível.

PersistentConnection representa um endpoint de comunicação com um único destinatário, agrupamentos ou mensagens de broadcast.
É necessário a configuração de uma rota customizada dentro do arquivo Global.asax.

A API de conexão (representada em código .Net pela classe PersistentConnection) dá ao desenvolvedor acesso direto a comunicação de baixo nível que o SignalR expõe, similar a forma de trabalhar com Sockets. O modelo de comunicação PersistentConnection será familiar para os desenvolvedores que usam API’s baseadas em conexão como o Windows Communcation Foundation – WCF.

Hubs é um pipeline de mais alto nível construído sobre a API PersistentConnection  e que permite que o cliente e servidor chamem métodos entre si diretamente.
O SignalR lida com o envio através dos limites da máquina, permitindo que o cliente chame os métodos no servidor tão facilmente como métodos locais e vice-versa.
Se o seu aplicativo usa diferentes tipos de mensagens é recomendável que você use a classe Hub, de modo que você possa chamar métodos no client em vez de enviar uma mensagem explícita que precisa ser recebida, interpretada e posta em prática. Usando o modelo de comunicação Hubs será familiar para os desenvolvedores que usam API’s de invocação remota como. NET Remoting.

A escolha de um modelo de comunicação

A maioria dos aplicativos deve usar o modelo Hubs.
PersistentConnections podem ser utilizados nas seguintes circunstâncias:

  • O formato da mensagem enviada necessita de ser controlado.
  • O desenvolvedor prefere trabalhar com um modelo de envio de mensagens ao invés de um modelo de invocação remota.
  • Um aplicativo existente que usa um modelo de mensagem está sendo portado para usar SignalR.

Como começar?

É necessário o Visual Studio 2010 SP1 ou o Visual Studio 2012

  • Inicie um projeto ASP.Net MVC
  • Instale o ASP.Net SignalR através do Nuget:
Install-Package Microsoft.AspNet.SignalR
  • Adicione um Controller vazio
public class ChatController : Controller
{
    public ActionResult Index()
    {
        return View();
    }
}
  • Crie uma View
@{
    ViewBag.Title = "Chat Básico";
}
<label for="apelido" >Seu Apelido:</label><input type="text" name="apelido" id="apelido" /><br />
<label for="mensagem" >Mensagem:</label><input type="text" name="mensagem" id="mensagem" maxlength="100" />
<div id="chatWindow" style="width: 100%; height: 300px; overflow: scroll; border: 1px solid grey"></div>

<!-- Referenciando os scripts adicionados ao Bundle -->
@Scripts.Render("~/bundles/jquery")
@Scripts.Render("~/bundles/SignalR")

<!-- Referencia para o script de Hub criado automaticamente -->
<script src="/signalr/hubs" type="text/javascript"></script>

<script type="text/javascript">
    $(function () {
        // Declarando um proxy de referencia ao Hub
        var chatHub = $.connection.chat;

        // Criando a função que será chamada pelo Hub para distribuir as mensagens aos clientes.
        // Por convenção as chamadas aos métodos são feitas em "camelCase"
        chatHub.transmitirMensagem = function (apelido, msg) {

            // Area do chat
            var chatWin = $("#chatWindow");

            // Publicando a mensagem no chat
            chatWin.html(chatWin.html() + "<b>" + apelido + "</b>: " + msg + "<br />");
        };

        // Iniciando a conexão com o Hub
        $.connection.hub.start();

        // Validando o botão enter
        $(document).keypress(function (e) {
            if (e.which == 13) {

                // Chamando o método de transmissão de mensagem no Hub
                chatHub.enviarMensagem($("#apelido").val(), $("#mensagem").val());

                // Limpando o texto da mensagem.
                $("#mensagem").val("");
            }
        });
    });
</script>
  • Crie um Hub
public class Chat : Hub
{
    public void EnviarMensagem(string apelido, string mensagem)
    {
        Clients.TransmitirMensagem(apelido, mensagem);
    }
 }

Este exemplo está disponível para download aqui.

Ao executar o projeto abra uma segunda instância de um browser (experimente browsers diferentes) e teste a conversação do chat.

ASP.Net SignalR

É incrivelmente fácil, não é mesmo?
O client chama métodos no Hub (server) como se fossem métodos locais e os métodos no server chamam métodos no client como se fossem métodos no servidor.

Quero conhecer e aprender mais!

Leia estes dois sites:

Assista este ótimo vídeo que foi gravado no TechEd 2012 por um dos desenvolvedores do  ASP.Net SignalR.

Leia este Free eBook do MVP JM Aguilar, eu já li e recomendo (inglês)

Mais exemplos para baixar:

Baixou o código fonte e teve alguma dúvida? Colocou a mão na massa e quer conhecer algum detalhe mais profundamente? Os desenvolvedores do ASP.Net SignalR respondem, eles ficam disponíveis neste chat, eu dei meu alô para eles e fui respondido:

ASP.Net SignalR

O exemplo do chat é o mais simples e clássico para usar na comunicação em tempo real, porém as possibilidades de utilização são inúmeras, adicione o ASP.Net SignalR em seu conhecimento técnico e faça proveito.

Este foi um post introdutório, falarei muito mais deste assunto em outros artigos, estou preparando uma aplicação especial para disponibilizar na comunidade utilizando ASP.Net SignalR e também tem minha palestra no Visual Studio Summit 2013 (será gravada e disponibilizada aqui).

Dê seu feedback e tire suas dúvidas nos comentários abaixo.
Gostou deste artigo? Compartilhe 😉

Referências

Vou palestrar no Visual Studio Summit 2013

Olá pessoal,

O Visual Studio Summit 2013 é um evento anual realizado na sede da Microsoft Brasil onde alguns dos maiores nomes do mercado e convidados realizam palestras sobre todo o processo de desenvolvimento de software utilizando a plataforma de desenvolvimento Visual Studio.

E como era de se esperar os temas que serão apresentados estão super interessantes, recomendo como uma atualização de conhecimentos e troca de experiências com a comunidade técnica, vale muito a pena conferir.

Nesta edição irei apresentar o tema:
ASP.NET SignalR. O que é e como usar!

Já estou preparando o material para a palestra, o que vai render alguns artigos sobre o ASP.Net SignalR, fique ligado 😉

Para mais detalhes do evento:
http://www.visualstudiosummit.com.br 

Agradeço ao Mestre Ramon Durães pela oportunidade de colaborar em mais uma edição deste grande evento.

Te vejo lá !!!

ASP.Net MVC – Validando e-mail com DataAnnotations

Olá pessoal,

Recentemente passei por um problema e gostaria de compartilhar a solução neste artigo.

Irei utilizar um projeto padrão do tipo MVC 4 – Internet Application do Visual Studio, este projeto já vem por padrão com o registro de usuários e controle do login com FormsAuthentication implementado.

Neste projeto temos uma área de registro de novos usuários e irei customizar para que o nome de usuário seja um e-mail, para isso é necessário que haja a validação no momento da criação do novo usuário.

Aqui está a Model AccountModels.cs original:

using System.ComponentModel.DataAnnotations;

public class RegisterModel
{
    [Required]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [Required]
    [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
    public string ConfirmPassword { get; set; }
}

Para que haja a validação é necessário decorar a propriedade do campo usuário (UserName), caso você pesquise na internet irá encontrar várias referências orientando a fazer a validação desta forma:

    [Required]
    [Display(Name = "User name")]
    [DataType(DataType.EmailAddress, ErrorMessage = "E-mail em formato inválido.")]
    public string UserName { get; set; }

No momento do registro não irá funcionar a validação do formato de e-mail, ou seja, um usuário com nome “Teste” será registrado sem ser barrado pela validação.

Explicação:
Aparentemente seria essa a proposta do atributo DataType, mas não, o atributo DataType é usado apenas para formatação e não validação.

No .Net Framework 4.5 há um novo atributo System.ComponentModel.DataAnnotations.EmailAddressAttribute, que é um tipo de atributo utilizado justamente para validação, sua aplicação inclusive é mais fácil:

    [Required]
    [Display(Name = "User name")]
    [EmailAddress(ErrorMessage = "E-mail em formato inválido.")]
    public string UserName { get; set; }

Utilizei o parâmetro ErrorMessage para definir a frase de erro a ser exibida, em outros casos basta usar o parâmetro [EmailAddress] que a validação será feita:

Lembrando que ainda existe a possibilidade de fazer a validação utilizando expressões regulares:

    [Required]
    [Display(Name = "User name")]
    [RegularExpression(@"b[A-Z0-9._%-]+@[A-Z0-9.-]+.[A-Z]{2,4}b", ErrorMessage = "E-mail em formato inválido.")]
    public string UserName { get; set; }

É isso pessoal, uma dica simples mas que pode salvar algum tempo do seu trabalho 🙂

Até a próxima.

Vou palestrar no DevBrasil Summit 2013

Olá Pessoal, tudo bem?

DevBrasil Summit 2013

O DevBrasil Summit 2013 é encontro nacional da rede social DevBrasil reunindo desenvolvedores de software de todo o Brasil para falar de inovação, empreendedorismo e tecnologia.

Farei minha palestra sobre Visual Studio LightSwitch, um tema que eu adoro falar principalmente para o público mais jovem que está iniciando na carreira de desenvolvimento.

Segue link oficial, façam suas inscrições (gratuíto):
http://devbrasil.net/events/devbrasil-summit-2013-sao-paulo

Mais uma vez agradeço ao Mestre Ramon Durães e o time DevBrasil pela oportunidade 🙂

Espero vocês lá!

C# – Para Iniciantes – Parte 7 – Generics C#

Olá Pessoal, Vamos falar sobre Generics C#.

Atendendo a um pedido de um leitor que segue a série C# para iniciantes, faremos aqui uma abordagem simples para entender sobre o tal Generics 🙂

Os Generics (Genéricos) foram incluídos no .Net Framework na versão 2.0 (isso foi em 2005), portanto é novidade apenas para quem está começando agora, hoje em dia os Generics são fundamentais, então sugiro que entendam bem o conceito.

Os Generics foram criados para eliminar o “casting“, facilitar a criação de classes e métodos e diminuir a quantidade de boxing (entenda o que é boxing).
Genérics representa uma coleção (lista, array, como preferir…) de objetos fortemente tipados. Uma collection de generics fornece métodos para pesquisar, ordenar e manipular através de um índice.

Fortemente tipados, pois é uma coleção de um tipo, (int, string, etc… ou T), sendo “T” nesse caso um tipo definido pelo próprio programador.

Para utilizar o generics é necessário fazer uso do namespace System.Collections.Generic

Exemplo, uma lista de int:

    List<int> listaInteiros = new List<int>();

Certo?
Agora dada a classe:

    public class Pessoa
    {
        public string Nome { get; set; }
        public int Idade { get; set; }
        public string Sexo { get; set; }

        // Construtor para facilitar a criação de uma nova pessoa.
        public Pessoa(string nome, int idade, string sexo)
        {
            Nome = nome;
            Idade = idade;
            Sexo = sexo;
        }

        // Construtor vazio para permitir uma instância vazia da classe Pessoa
        public Pessoa()
        {
        }
    }

A classe Pessoa foi escrita pelo programador, não é um tipo do .Net, nesse caso para montar uma lista de N pessoas, seria assim:

    // Criando uma lista do tipo pessoa.
    List<Pessoa> listaPessoas = new List<Pessoa>();

    // Adicionando novas pessoas na lista.
    listaPessoas.Add(new Pessoa("Eduardo",30,"M"));

    listaPessoas.Add(new Pessoa("Enzo", 7, "M"));

    listaPessoas.Add(new Pessoa("Juliana", 21, "F"));

    // Obtendo o total de pessoas na lista
    int totalPessoas = listaPessoas.Count(); // totalPessoas = 3 pessoas

Fazendo a mesma coisa, só que de forma diferente:

    // Criando uma lista do tipo pessoa.
    List<Pessoa> listaPessoas = new List<Pessoa>();

    // Criando um objeto pessoa vazio.
    Pessoa pessoaTeste = new Pessoa();

    // Preenchendo um objeto pessoa.
    pessoaTeste.Nome = "Eduardo";
    pessoaTeste.Idade = 30;
    pessoaTeste.Sexo = "M";

    // Adicionando a pessoa na lista.
    listaPessoas.Add(pessoaTeste);

Escrevendo um método que recebe uma lista genérica de Pessoas e trabalha os dados da lista:

    public static void MetodoAumentaIdade(List<Pessoa> listaPessoas)
    {
        foreach(Pessoa pessoa in listaPessoas)
        {
            // Aumenta 1 ano de idade.
            pessoa.Idade++;
        }
    }

Estes exemplos mostraram como criar uma lista genérica.
Agora que sabemos como criar e popular uma lista genérica, vou dar alguns exemplos de como trabalhar dados em listas:

    // Criando uma nova lista e ordenando por nome decrescente
    List<Pessoa> novaListaPessoas;
    novaListaPessoas = listaPessoas.OrderByDescending(x => x.Nome).ToList();

    // Varrendo e exibindo nomes ordenados
    novaListaPessoas.ForEach(n => Console.Write(n.Nome));

    // Criando uma nova lista baseada em pessoas selecionadas por um critério
    List<Pessoa> listaPessoaSelecionada =
                (from Pessoa p in novaListaPessoas where p.Nome == "Eduardo"
                select p).ToList();

    // Somando todas as idades das pessoas da lista
    int totalIdades = novaListaPessoas.Sum(x => x.Idade);

Notem que estou fazendo bastante uso de Expressões Lambdas.
Existem várias abordagens possíveis para trabalhar uma lista genérica, nesta documentação da Microsoft é possível estudar todas e aprender quando e de que forma podemos facilitar nosso trabalho utilizando Generics.

É isto pessoal, utilizem os comentários para participar ou tirar dúvidas.

Até mais 😉

O que é POCO?

Olá pessoal, O que é POCO? O que seria uma classe POCO?

Hoje em dia utilizar um ORM como Entity Framework ou NHibernate é bem comum, aplicar conceitos do DDD também vem sido bem abordados e discutidos e em todas essas abordagens acaba surgindo o uso de POCO. Afinal o que é POCO?

Tentar decifrar esse nome vai ser bem difícil, POCO significa Plain OLD CLR Object, tentando traduzir isso eu gosto de chamar POCO de “Bom e velho objeto do CLR”.
POCO é um acrônimo de POJO Plain OLD Java Object, criado por Martin Fowler (um expert em OOP) como ele vem de Java acabou dando esse nome, então os especialistas em .Net fizeram uma pequena mudança para trazer esse conceito ao nosso mundo e surgiu o POCO (mas é o mesmo conceito, não muda nada).

Legal, mas ainda não entendi o que é POCO?

É fácil de entender, POCO é uma classe que segue o ideal do OOP, pois tem estado e comportamento, porém não depende e não conhece nenhum recurso externo além do Framework .Net.

Uma classe POCO é utilizada como classe de domínio (negócio) da sua aplicação, o que chamo de Modelo de Domínio. Um Modelo de Domínio é formado pelas classes que compõem a estrutura de negócio do mundo real.

Nós não desenvolvemos sistemas apenas baseados no Framework .Net, quase sempre necessitamos de uma ferramenta externa, por exemplo um ORM, que por sua vez impõe o uso de referências como classes, interfaces, decorações nos métodos etc…

Construir uma classe POCO é escrever uma classe que contenha atributos, construtores e métodos mas que não dependam de nada mais do que o próprio .Net Framework forneça.

Quem já utilizou o Entity Framework na forma Database First já viu como que fica a bagunça de uma classe? Acabamos gerando um único arquivo EDMX com muitas dependências, herdando de um objeto ObjectContext. Geralmente esse código é bastante poluído e dificíl de estender.

    [EdmEntityTypeAttribute(NamespaceName="SistemaOS.Model", Name="Pessoas")]
    [Serializable()]
    [DataContractAttribute(IsReference=true)]
    public partial class Pessoas : EntityObject
    {
        [EdmScalarPropertyAttribute(EntityKeyProperty=true, IsNullable=false)]
        [DataMemberAttribute()]
        public global::System.Int32 id_pessoa
        {
            get
            {
                return _id_pessoa;
            }
            set
            {
                if (_id_pessoa != value)
                {
                    Onid_pessoaChanging(value);
                    ReportPropertyChanging("id_pessoa");
                    _id_pessoa = StructuralObject.SetValidValue(value, "id_pessoa");
                    ReportPropertyChanged("id_pessoa");
                    Onid_pessoaChanged();
                }
            }
        }
    }

Ou seja, estamos amarrados ao Entity Framework se deixarmos ele criar nossas classes de entidades.

Um exemplo simples de classe POCO:

    public class Pessoa
    {
        public string Nome { get; set; }
        public string Sobrenome { get; set; }
        public int Cpf { get; set; }

        public string NomeCompleto()
        {
            return Nome + " " + Sobrenome;
        }
    }

Veja que neste exemplo não dependemos de nada, é apenas uma classe, tratando de DDD o nosso domínio não pode depender de tecnologia, afinal a minha camada de domínio pode ser adaptada a um outro sistema que não utilizará o Entity Framework e tudo bem! Afinal minha classe POCO não depende disso.

Acredito que a vantagem de usar POCO é exatamente essa, podemos modelar nossas classes de domínio e portá-las para onde quiser, sem a dependência de nenhuma ferramenta externa.

Por isso recomendo que utilizem ferramentas que dê suporte a POCO, e isso não é difícil, por exemplo Entity Framework, NHibernate, WCF permitem trabalhar com POCO.

No Entity Framework, por exemplo, podemos trabalhar da forma Code First, ou seja, escrevemos primeiro classes POCO e no final a modelagem da base de dados é criada conforme a modelagem do nosso domínio.

Então uma classe POCO é uma classe anêmica?
– Não! Uma classe anêmica pode até ser uma classe POCO, mas nada diz que uma classe POCO deve ser anêmica, afinal ela pode possuir atributos e métodos.
Uma classe anêmica não possui métodos, e por alguns é considerada um anti-pattern, pois fere o conceito de orientação a objeto, mas isso é assunto para um outro artigo. 🙂

Uma classe POCO é como se fosse uma DTO então?
– Não! Uma DTO “Data Transfer Object” é outra coisa, pense em DTO como uma “sacola de dados”, ou seja, em um objeto DTO podemos ter dados das classes Pessoa, Endereço, Empresa.
DTO é um outro pattern desenhado justamente para reduzir o número de chamadas e a quantidade de dados necessários para trafegar entre camadas de sistemas, por exemplo, entre uma aplicação web e um serviço.
Uma classe POCO é sua classe de domínio e um DTO é o objeto para transitar dados apenas, podem possuir dados de mais de uma entidade e não possuem métodos, portanto não é POCO.

Se minha classe herda de uma classe base então não tenho uma classe POCO?
– Depende, desde que a classe base não tenha nenhuma dependência com outras camadas da aplicação e ferramentas externas, ainda é uma classe POCO.

Referências:

Espero que tenham aproveitado, se você gostou compartilhe esse artigo, se tiver dúvidas ou quiser contribuir com algo faça um comentário.

Até a próxima!