[Off-Topic] Motivação importa

Filed Under ([Off - Topic]) by Vinicius Quaiato on 04-02-2010

Tagged Under : , , ,

diamantesAcredito que as empresas querem ter os melhores funcionários (colaboradores, parceiros, times, equipes, etc). Esta é minha crença.
E o que mostra que um profissional é o melhor profissional? Conhecimento técnico? Comprometimento? Disponibilidade? Olhar crítico? Tudo isso. Porém acredito em algo mais: Motivação.

Não basta contratar o profissional com o maior conhecimento técnico disponível no mercado. Este conhecimento técnico pode ser, e acredite que é, suprimido pela falta de motivação. E se você quer que sua empresa, time, equipe, etc, esteja entre os melhores:

 

  • Conheça os anseios e desejos deste profissional – Entenda o que ele almeja, e ajude-o a conquistar
  • Dê a ele a chance de participar – Faça-o parte de um time
  • Invista nele, além do salário – Apagar incêndio é importante, mas permita-o crescer
  • Preocupe-se com a qualidade técnica do trabalho executado – Mostre que o que ele faz tem valor
  • Fuja dos modelos organizacionais batidos e ultrapassados – Se quer mentes brilhantes, inove!
  • Crie um ambiente colaborativo – É muito melhor trabalhar em grupo
  • Mostre a ele que perder a batalha não é perder a guerra – Participe com ele das derrotas e construam vitórias juntos
  • Desafie-o constantemente – Os melhores aguentam a pressão e criam soluções inesperadas
  • Deseje tê-lo em sua equipe – Mostre o quão importante é sua participação

O mercado está cheio de profissionais medíocres, que se contentam em receber um contra-cheque no final do mês, porém, o mercado é construído por aqueles que se importam com os itens mencionados acima.

Um profissional brilhante pode tornar-se medíocre em razão do ambiente desfavorável, e quando isso acontecer, esteja certo, ele vai abandonar este time.
Não se pode apagar mentes brilhantes, então se você realmente deseja tê-las em sua equipe, faça por merecer. Cultive os talentos que você possui na sua empresa.
Cultive os seus diamantes!

Mantenha seus profissionais motivados, e eles terão os melhores resultados. Eles farão a diferença. Eles se importarão com o que fazem. Eles se importarão com o que entregam. Farão com qualidade. Participarão das decisões, evitarão cometer erros. Assumirão os erros.

Se você deseja resultados medíocres, se deseja apenas pagar incêndios, e receber de seus clientes, não se importe com nada do que foi dito. Agora, se você deseja que sua empresa se destaque, se deseja os melhores profissionais, se quer fazer diferente e tornar-se referência, não atue da mesma maneira que os medíocres, faça de sua empresa uma empresa brilhante.

Motivação matters.

Att,
Vinicius Quaiato.

Coding Dojo .NET Architects – 30/01/2010 – São Paulo

Filed Under (.NET, Boas Práticas, Dojos, TDD) by Vinicius Quaiato on 29-01-2010

Tagged Under : , ,

Fala galera! Sábado, dia 30/01/2010 teremos um Coding Dojo, organizado pela comunidade .NET Architects.

Este Coding Dojo dará início ao grupo de Dojo do .NET Architects, que fará encontros regulares focando os dojos nas diversas linguagens e tecnologias .NET.

Local: Unip Jaguaré – São Paulo – SP
Horário: à partir das 10hs
Data: sábado, 30/01/2010

Confira o mapa do local e faça sua incrição aqui: http://dojo.dotnetarchitects.net
Totalmente gratuito!

Não existem pré-requisitos para participar, basta ter vontade e comparecer!

Saiba mais sobre Coding Dojo aqui.

Abraços, nos vemos lá!

Vinicius Quaiato.

Entity Framework 4 – Model First com POCOs

Filed Under (.NET, .NET 4.0, Boas Práticas, Entity Framework, Visual Studio 2010) by Vinicius Quaiato on 27-01-2010

Tagged Under : , ,

Fala galera, de buenas? Resolvi escrever um pouco sobre o Entity Framework 4.0 (na verdade é a versão 2 do EF mas para acompanhar o .NET 4.0 ele será chamado assim também).

Hoje vou mostrar uma característica bem interessante, que é o model first trabalhando com POCOs.
Model First diz respeito a primeiro criar suas entidades, ou seja, suas classes, e somente depois modelar o banco de dados – e é isto que queremos fazer quando desenvolvemos aplicações usando Orientação a Objetos, não é?
POCOs são classes simples, que não herdam nem implementam nenhuma outra classes/interface específica de frameworks, dizendo respeito exclusivamente ao nosso domínio e contendo apenas o necessário ao nosso domínio.

Para começar vamos criar um projeto de testes e adicionar um arquivo .edmx como mostra a figura abaixo:



Feito isso vamos selecionar o tipo de modelo “empty model”:

Selecionando o empty model

Selecionando o empty model


Pronto!
Vamos então adicionar duas entidades ao nosso design surface. Estas serão nossas entidades POCO, ou seja, não terão nenhuma dependência do Entity Framework, nem do Linq, nem de nada, é apenas o nosso modelo de classes, vamos ainda desabilitar a geração de código do Visual Studio, para que ele não “polua” as classes:


E então clicamos na parte branca do design e abrimos a janela de propriedades para desabilitar a geração de código:


Estamos a meio caminho andado. Pode parecer muito trabalho a ser feito, mas isso não leva mais do que 2 minutos. É realmente simples e os resultados são muito bons.
Agora vamos para a parte bacana, codificar nossas classes.
Vamos iniciar codificando as classes Pedido e ItemPedido, que são classes realmente bastante simples:

public class Pedido
{
    public virtual int Id { get; set; }
    private IList<ItemPedido> itens = new List<ItemPedido>();
    public virtual IList<ItemPedido> Itens
    {
        get { return this.itens; }
        set { this.itens = value; }
    }
}
 
public class ItemPedido
{
    public virtual int Id { get; set; }
    public virtual string Produto { get; set; }
    public virtual int Quantidade { get; set; }
    public virtual Pedido Pedido { get; set; }
}

Os virtuais que usamos nas nossas classes são para que o Entity Framework possa fazer o “tracking” dos nossos objetos. Internamente ele criará proxies para nossas classes. Em um primeiro momento basta colocarmos as propriedades como virtual e ele se encarregará de tudo, isso ainda ajudará no Lazy Loading.

Agora, como desabilitamos a geração de código, precisamos também criar o nosso contexto do EF. Isso é bastante simples, e neste cenário nos obrigará a escrever apenas umas 10 linhas de código, como pode ser visto abaixo:

public class EF4Context : ObjectContext
{
    public EF4Context()
        : base("name=EF4Container", "EF4Container") { }
 
    private IObjectSet<Pedido> pedidos;
    public IObjectSet<Pedido> Pedidos
    {
        get
        {
            if (pedidos == null)
                pedidos = CreateObjectSet<Pedido>();
 
            return pedidos;
        }
    }
}

Feito isso nos resta apenas gerar o banco de dados. Como dissemos, geramos primeiro nossas classes, sem nos preocupar em como estes dados seriam armazenados, conseguimos focar puramente no nosso domínio e no nosso modelo, afinal estamos pensando em classes e objetos, e não em linhas/tuplas de banco, chaves, índices, etc.
O Visual Studio irá gerar o código necessário para nosso banco de dados veja abaixo:


Agora é só executar o SQL gerado:


Se vocês fizeram tudo certinho até o momento, devem ser capazes de executar os seguintes códigos de testes com sucesso:

[TestMethod]
public void Deve_Adicionar_Um_Pedido_No_DB_Usando_Contexto_E_Poco()
{
    var contexto = new EF4Context();
 
    var pedido = new Pedido();
 
    pedido.Itens.Add(new ItemPedido
    {
        Produto = "Novo Produto",
        Quantidade = 5,
        Pedido = pedido
    });
 
    contexto.AddObject("PedidoSet", pedido);
    contexto.SaveChanges();
}

Depois este:

[TestMethod]
public void Deve_Obter_Todos_Os_Pedidos_Do_Banco_Usando_Contexto_E_Pocos()
{
    var contexto = new EF4Context();
 
    var pedidos = contexto.Pedidos.ToList();
 
    Assert.IsTrue(pedidos.Count > 0);
}

E por fim este:

1
2
3
4
5
6
7
8
9
10
11
12
13
[TestMethod]
public void Deve_Selecionar_1_Pedido_Do_Banco_Usando_Contexto_E_Pocos()
{
    var contexto = new EF4Context();
    contexto.ContextOptions.LazyLoadingEnabled = true;
 
    var pedido = contexto.Pedidos
                            .Where(p => p.Id == 1).Single();
 
    Assert.AreEqual(1, pedido.Id);
    Assert.IsTrue(pedido.Itens.Count > 0);
    Assert.AreEqual("Novo Produto", pedido.Itens[0].Produto);
}

Percebam como na linha 5 habilitamos o lazy loading para que as propriedades sejam carregadas no momento em que forem chamadas apenas.

E se fizermos uma consulta no banco de dados, veremos que de fato os dados estão lá:


Bom pessoal, é isso.
Esta é uma das funcionalidades presentes no Entity Framework 4.0. É claro que existe muita coisa a ser explorada ainda, e existem muitas coisas a serem feitas ainda, mas é um enorme avanço poder trabalhar com POCOs e utilizar os recursos de uma ferrmenta ORM como o EF. Poder dar “tchau” para os SqlConnection, SqlCommand, ExecuteScalar, etc, é algo realmente incrível.

Espero que tenham gostado. Dúvidas, críticas e sugestões me enviem email ou comentários.

Abraços,
Vinicius Quaiato.

ASP.NET MVC + JQuery

Filed Under (.NET, ASP.NET, ASP.NET MVC, Visual Studio 2010) by Vinicius Quaiato on 25-01-2010

Tagged Under : , , , ,

Neste artigo mostrarei um pouco de como usar o ASP.NET MVC com o Jquery para criar páginas mais dinâmicas e funcionais.

Este não é um artigo introdutório ao ASP.NET MVC, posso escrever sobre isso depois, e você pode encontrar tudo sobre o MVC do asp.net aqui: http://www.asp.net/mvc/.

Neste exemplo estou utilizando o VS2010 beta 2, Asp.Net MVC 2 e Jquery 1.3.2. Também utilizarei o plugin DataTables para o Jquery, que você deve baixar aqui: http://datatables.net/

Primeiramente vamos criar um website do tipo Asp.Net MVC no VS2010. Feito isso eu vou excluir todas as Views e Controllers que são criados por padrão, mantendo apenas os configs e a pasta Scripts.

Agora vamos criar um Controller para retornar uma lista de objetos, para que possamos montar um grid e executar algumas ações. Vou criar um Controller chamado HomeController, e adicionar o código abaixo:

public ActionResult Index()
{
    var items = new List<ExpandoObject>();
    for (int i = 0; i < 10; i++)
    {
        dynamic item = new ExpandoObject();
        item.Id = i + 1;
        item.Nome = string.Format("Item {0}", i + 1);
        item.Valor = 10 + i;
        item.Descricao = string.Format("Descricao do Item {0}", i + 1);
 
        items.Add(item);
    }
 
    ViewData["items"] = items;
    return View();
}

O código é bastante simples, cria apenas uma lista de ExpandoObjects e manda esta lista para a View(leia mais sobre ExpandoObjects aqui).

Agora crie uma pasta chamada Home dentro da pasta Views e então crie uma View chamada Index dentro da pasta Home, a solution deve ficar assim:

Solution com View e Controller

Solution com View e Controller

Vamos para o código .aspx da nossa View que deve ficar assim:

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="Head1" runat="server">
    <title>HomeView</title>
</head>
<body>
    <div>
        <table id="dataTable">
            <thead>
                <tr style="background-color:#aabbcc; color:#fff;">
                    <th style="width: 50px;">
                        Id
                    </th>
                    <th style="width: 100px;">
                        Nome
                    </th>
                    <th style="width: 70px;">
                        Preço
                    </th>
                    <th style="width: 200px;">
                        Descrição
                    </th>
                </tr>
            </thead>
            <tbody>
                <%
                    var items = ViewData["items"] as List<System.Dynamic.ExpandoObject>;
                    foreach (dynamic item in items)
                    {
                %>
                <tr id="<%=item.Id %>">
                    <td>
                        <%=item.Id %>
                    </td>
                    <td>
                        <%=item.Nome %>
                    </td>
                    <td>
                        R$
                        <%=item.Valor.ToString("N2") %>
                    </td>
                    <td>
                        <%=item.Descricao %>
                    </td>
                </tr>
                <%} %>
            </tbody>
        </table>
    </div>
</body>
</html>

Tudo que este código faz é obter nossa lista de items e então desenhá-los na tela em forma de uma tabela.
Agora vamos usar o Jquery para ir até o servidor, excluir um item da lista no servidor, e então removê-lo da lista no client utilizando Ajax.

Para isso incluiremos uma referência para o Jquery em nossa View. O Jquery já vem junto com os projetos MVC do asp.net em sua versão 2, basta arrastar o arquivo da pasta Scripts para dentro da View que a referência é adicionada:

<head id="Head1" runat="server">
    <title>HomeView</title>
    <script src="../../Scripts/jquery-1.3.2.js" type="text/javascript"></script>
</head>

Agora vamos criar uma function javascript que fará a chamada via Ajax para o Controller:

1
2
3
4
5
6
7
8
9
10
function Remover(action, param) {
    $.post(action + "/" + param,
    function (data) {
        alert(data);
 
        $("#" + param).fadeOut("slow");
    });
 
    return false;
}

Esta function recebe 2 parâmetros, o primeiro é o nome da Action que executaremos no Controller, e o segundo é o parâmetro que passaremos, nesse caso o id do nosso item.
A linha 2 utiliza uma função do Jquery para fazer chamas Ajax usando post. O primeiro parâmetro é a url a ser chamada, no nosso exemplo será algo como “remover/5″. O segundo parâmetro é uma function de callback, que será executada depois que a resposta vier do servidor, e o que estamos fazendo é exibindo a resposta, e então removendo da nossa tabela a linha excluída, utilizando uma animação do Jquery chamada fadeOut.

No nosso Controller adicionaremos um método para simular a exclusão do item, como pode ser visto abaixo:

[AcceptVerbs(HttpVerbs.Post)]
public string Remover(int id)
{
    return string.Format("removeu item: {0}", id);
}

Tudo que esta Action faz é retornar uma string dizendo que o item foi removido.
Agora precisamos fazer com que exista um link na nossa tabela para executar esta ação, e para isso incluiremos mais uma coluna, a coluna Ação, e este código será necessário para renderizar os dados:

<td>
    <a href="remover/<%=item.Id %>" onclick="return Remover('remover','<%=item.Id %>')">
        Remover</a>
</td>

Pronto! Agora já temos uma tabela capaz de excluir itens usando Ajax e ainda ter a linha removida da tabela utilizando um efeito bem bacana.

E para deixar as coisas um pouco mais “profissionais” vamos deixar esta tabela com cara e comportamente de grid, usando o plugin DataTables.
Para isso inclua o arquivo jquery.dataTables.js que você baixou dentro da pasta Scripts, e então arraste o mesmo até a View, para incluir a referência.
Agora coloque o seguinte código javascript dentro do da sua view:

$(document).ready(function () {
    $("#dataTable").dataTable();
});

Este código irá aplicar o plugin na nossa tabela, e o resultado será como mostrado abaixo:

table usando plugin DataTables

table usando plugin DataTables

Agora podemos filtrar, ordenar e paginar nossos dados, sem nenhum esforço adicional, veja um exemplo de filtro abaixo:

plugin DataTable filtrando dados

plugin DataTable filtrando dados

Bom galera, é isso!
O código fonte desta solução está disponível aqui.

Qualquer dúvida, email ou comentários.

Abraços,
Vinicius Quaiato.

IronRuby: Rodando Ruby dentro do .NET

Filed Under (.NET, .NET 4.0, IronRuby) by Vinicius Quaiato on 21-01-2010

Tagged Under : , , ,

O IronRuby é um port da linguagem Ruby para ser executada juntamente com o .Net Framework.
Atualmente o IronRuby está em release candidate(versão 1.0 – RC1), e em algum tempo devemos ter a versão oficial.

A idéia aqui não é descrever em pormenores os detalhes da linguagem Ruby, pois inúmeras referências podem ser encontradas na web: Ruby on Br é uma delas.

Vou demonstrar como começar a utilizar o IronRuby juntamente com as bibliotecas do .Net e como produzir algum código.

Vamos iniciar instalando o IronRuby, e para isso faça o download no site oficial do Ironruby no CodePlex aqui. Eu utilizei a versão Windows Installer.
Execute este instalador após o download, ele irá extrair os arquivos para uma pasta especificada.

Assim como a maioria das linguagens dinâmicas o IronRuby possui um console interativo, onde podemos escrever código e testar seu uso. E é desta forma que trabalharemos neste primeiro momento.

Execute o console do IronRuby, que deve ser encontrado na [pasta de instalação]\bin\ir.exe.

Você deverá ver uma tela semelhante a esta:

IronRuby Console

IronRuby Console

Agora já podemos começar a escrever nosso código Ruby/IronRuby.
Como nosso primeiro código, vamos criar uma classe que terá apenas um método, um famoso Olá Mundo:

class OlaIronRuby
    def DigaOi
	puts "Olá Mundo IronRuby!"
    end
end

Quando digitarmos esse código no console do IronRuby esta classe estará disponível para uso, e a utilizaremos assim:

instancia = OlaIronRuby.new

E fazemos a chamada para o método assim:

instancia.DigaOi

Abaixo vocês conferem todo o código no console do IronRuby:

Criando instancia de classe no IronRuby

Criando instancia de classe no IronRuby

Agora vamos criar uma nova classe que irá trabalhar com bibliotecas do framework.
Para referenciarmos um assembly no console, vamos utilizar o require ‘nome do assembly’, como pode ser visto no código abaixo, onde utilizamos o WindowsForms.MessageBox para exibir uma mensagem usando o IronRuby:

require 'System.Windows.Forms'
 
System::Windows::Forms::MessageBox.show "Olá MessageBox!"

E o resultado podemos ver aqui:

Usando MessageBox com IronRuby

Usando MessageBox com IronRuby

Podemos ainda criar aplicações WPF por exemplo. Para isso vamos digitar nosso código em um arquivo e salvá-lo como WpfIronRuby.rb, o código pode ser visto abaixo:

require 'wpf'
include Wpf
 
janela = Wpf::Window.new
janela.Title = 'WPF com IronRuby'
janela.content = Wpf::TextBlock.new
janela.content.text = "Janela WPF usando IronRuby!"
janela.content.font_size = 60
 
app = Application.new
app.run janela

Para este código funcionar eu copiei o arquivo wpf.rb da pasta [instalação do ironruby]\Samples\Tutorial\app\wpf.rb para [instalação do ironruby]\Lib\ironruby

Para executar a aplicação eu abri o command do windows e naveguei a até a pasta onde salvei o arquivo, no meu caso o Desktop e digitei: ir.exe WpfIronRuby.rb como pode ser visto na imagem abaixo:



Rodando aplicação Wpf com IronRuby

Rodando aplicação Wpf com IronRuby

Bom galera, é isso.
O ironRuby ainda está saindo do forno, e com certeza será(e já é) uma grande soma para o .Net Framework.

Qualquer dúvida, mail-me ou comentem.

Abraços,
Vinicius Quaiato.

Injeção de Dependência com MS Unity

Filed Under (.NET, Boas Práticas, Patterns) by Vinicius Quaiato on 18-01-2010

Tagged Under : , , , ,

Bom pessoal, pudemos ver os benefícios e alguns usos de Inversão de Controle e Injeção de Dependências aqui e aqui.

Uma das formas de obter excelentes ganhos com a inversão de controle é através da utilização de um contêiner de Injeção de Dependências.

Um contêiner de injeção de dependências é capaz de criar objetos com todas suas dependências injetadas e totalmente pronto para uso. Em geral estes conteiners podem ser configurados manualmente(programaticamente) ou dinamicamente(através de arquivos de configuração por exemplo).

Falaremos um pouco do Unity que é um contêiner de Injeção de Dependência que faz parte dos Application Blocks da Microsoft.

Para que vejamos como o Unity funciona faça o download do mesmo aqui e execute o setup, que irá apenas criar uma pasta com as DLLs do Unity.

O Unity, como veremos nos exemplos, suporta 3 tipos de injeção de dependência:

  • Constructor Injection (injeção por construtor)
  • Property Injection (injeção de propriedade)
  • Method Call Injection (injeção de chamada de métodos)

Vamos usar como exemplo estas classes e interfaces:

public interface ILogger
{
    void RegistrarMensagem(string mensagem);
}
 
public class SqlLogger : ILogger
{
    public void RegistrarMensagem(string mensagem)
    {
        //abre conexão SQL
 
        //Executa insert da mensagem
    }
}
 
public class EnviadorDeEmails
{
    public ILogger Logger { get; set; }
    public EnviadorDeEmails(ILogger logger)
    {
        this.Logger = logger;
    }
    public void EnviarEmail(string email, string mensagem)
    {
        //Envia email
 
        //registra envio
        this.Logger.RegistrarMensagem(string.Format("Email enviado para {0}", email));
    }
}

Adicione as seguintes referências ao seu projeto: Microsoft.Practices.ObjectBuilder2.dll e Microsoft.Practices.Unity.dll que se encontram na pasta que você “instalou” o Unity, como pode ser visto na figura abaixo:
Incluindo Dlls do Unity

As classes acima são bem simples, no final das contas o que faremos é com que o Unity crie um EnviadorDeEmails com a dependência de ILogger injetada e resolvida, ou seja, que ele crie um EnviadorDeEmails passando para ele um SqlLogger. Para isso vamos “ensinar” ao Unity como resolver a interface ILogger, como pode ser visto no código abaixo:

1
2
    var unityContainer = new UnityContainer();
    unityContainer.RegisterType<ILogger, SqlLogger>();

Na linha 1 criamos uma instância do contêiner do Unity. Na linha 2 dizemos para o Unity que quando quisermos o tipo ILogger (interface) ele deve utilizar a classe concreta SqlLogger. Simples assim.

Constructor Injection

Agora podemos mandar que o Unity construa nosso EnviadorDeEmails usando constructor injection, conforme visto abaixo:

1
2
3
4
5
6
7
8
9
10
[TestMethod]
public void Configurando_Unity_Para_Resolver_ILogger()
{
    var unityContainer = new UnityContainer();
    unityContainer.RegisterType<ILogger, SqlLogger>();
 
    var enviadorEmails = unityContainer.Resolve<EnviadorDeEmails>();
 
    Assert.IsInstanceOfType(enviadorEmails.Logger, typeof(SqlLogger));
}

O grande segredo aí está na linha 7 onde dizemos para o Unity construir nosso EnviadorDeEmails. O Unity percebe que existe uma dependência no construtor do EnviadorDeEmails, e baseado na configuração que fizemos ele sabe como resolver esta dependência. Na linha 9 apenas verificamos se de fato o ILogger utilizado é o SqlLogger, e executando o teste obtemos sucesso.
E notem que neste caso utilizamos o constructor injection pois a classe EnviadorDeEmails possui um construtor com uma dependência para uma interface, que o Unity conhece.

Property Injection

Poderíamos dizer que a dependência não deve ser resolvida via construtor, mas sim diretamente na propriedade, para isso alteraríamos a classe EnviadorDeEmails assim:

1
2
3
4
5
6
7
8
9
10
11
12
public class EnviadorDeEmails
{
    [Dependency]
    public ILogger Logger { get; set; }
    public void EnviarEmail(string email, string mensagem)
    {
        //Envia email
 
        //registra envio
        this.Logger.RegistrarMensagem(string.Format("Email enviado para {0}", email));
    }
}

A única diferença aqui foi a utilização do DependencyAttribute na linha 3 para marcar que a propriedade Logger, do tipo ILogger, deve ser resolvida pelo Unity.
Executando nosso teste mais uma vez devemos obter sucesso.

Method Call Injection

A outra forma que o Unity tem para injetar nossas dependências é através da chamada de um método. Por exemplo, imaginem que temos um método Initialize na nossa classe, que é responsável por criar os objetos que nossa classe precisa. Podemos fazer com que o Unity execute este método resolvendo todas as dependências.
Vejamos o código da classe EnviadorDeEmails utilizando um Method Call Injection:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class EnviadorDeEmails
{
    public ILogger Logger { get; set; }
    public void EnviarEmail(string email, string mensagem)
    {
        //Envia email
 
        //registra envio
        this.Logger.RegistrarMensagem(string.Format("Email enviado para {0}", email));
    }
 
    [InjectionMethod]
    public void Inicializador(ILogger logger)
    {
        this.Logger = logger;
    }
}

Tudo o que fizemos desta vez foi criar um método, neste caso o método Inicializador, na linha 13, que recebe como parâmetros as dependências da nossa classe. E marcamos este método com o InjectionMethodAttribute, para dizer ao Unity que este método deve ser chamado e resolvidor por ele na criação de nosso EnviadorDeEmails.
E novamente se executarmos o mesmo método de teste, obteremos sucesso.

Como vimos nos três exemplos acima, o Unity após configurado consegue resolver as dependências de nossas classes de forma simples e trivial. Basta alterarmos a forma de resolução da dependência, por exemplo de constructor para setter, e nada no código mudará, assim como se mudar de SqlLogger para XmlLogger, nada no código mudará, apenas a configuração do Unity.

Bom galera, é mais ou menos isso. O Unity é uma ferramenta bastante poderosa, extensível e simples de usar.

Qualquer dúvida é só escrever nos comentários ou enviar email.

Abraços,
Vinicius Quaiato.

TDD na .Net Magazine 69

Filed Under (.NET, Boas Práticas, Publicações, TDD) by Vinicius Quaiato on 07-01-2010

Tagged Under : , ,

.NET Magazine edição 69

Acaba de chegar às bancas a .NET Magazine com um artigo sobre TDD.

Neste artigo eu demonstro passo-a-passo a utilização do TDD na criação de uma simples aplicação de compras.

Vários dos benefícios do TDD são demonstrados na prática.

O link para a matéria online é:
http://www.devmedia.com.br/articles/viewcomp.asp?comp=15242

Série de posts sobre TDD aqui no blog:
http://viniciusquaiato.com/blog/index.php/tdd-test-driven-development-c/

http://viniciusquaiato.com/blog/index.php/tdd-test-driven-development-c-parte-ii/

http://viniciusquaiato.com/blog/index.php/tdd-test-driven-development-c-parte-iii/

http://viniciusquaiato.com/blog/index.php/tdd-test-driven-development-c-parte-iv/

É isso aê galera, boa leitura e dêem seu feedback!

Abraços, Vinicius Quaiato.

DynamicObject: dinamismo no .NET 4.0

Filed Under (.NET, .NET 4.0, Visual Studio 2010) by Vinicius Quaiato on 23-12-2009

Tagged Under : , , , ,

Continuando a falar de dynamic no .NET 4.0, vamos falar um pouco sobre DynamicObject.

DynamicObject é uma classe abstrata que permite definir quais operações podem ser feitas em um objeto dynamic e como estas operações são realizadas.

Falei um pouco sobre ExpandoObject aqui, que é um tipo de objeto dynamic.

Para não dizer que esta é uma das novas features e que ela é inútil, estou envolvido em um projeto e se esta feature já estivesse disponível em versão realease, eu já estaria utilizando a mesma por necessidades do projeto.

Bom para dar um exemplo, vamos imaginar que estamos implementando um provider customizado para sessões em nossa aplicação.
Muitas vezes não queremos ter que escrever algo como minhaSessao["Usuario"], afinal se sabemos que sempre haverá um Usuario na sessão ele poderia ser uma propriedade. Com DynamicObject podemos fazer isso (primeiro vou escrever os testes):

[TestMethod]
public void Deve_Criar_Uma_Propriedade_Nome_No_Objeto_Dinamico()
{
    dynamic sessaoDinamica = new SessaoDinamica();
    sessaoDinamica.Nome = "Vinicius";
 
    Assert.AreEqual(sessaoDinamica.Nome, "Vinicius");
}

E a classe SessaoDinamica:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class SessaoDinamica : DynamicObject
{
    private Dictionary<string, object> sessionItems = new Dictionary<string, object>();
 
    public override bool TrySetMember(SetMemberBinder binder, object value)
    {
        sessionItems[binder.Name.ToLower()] = value;
 
        return true;
    }
 
    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
        return sessionItems.TryGetValue(binder.Name.ToLower(), out result);
    }
}

Podemos notar na linha 1 que nossa classe herda de DynamicObject, que como foi dito é uma classe abstrata.
Na linha 3 definimos um dicionário para ser a coleção de itens da nossa sessão.
Nas linhas 5 a 10 fazemos um override em um dos métodos da classe DynamicObject. O método TrySetMember é que fará toda a mágica. Quando uma propriedade for chamada no objeto dynamic o .net irá verificar se esta propriedade existe de fato e caso ela não exista o método TrySetMember será então chamado. Dentro deste método estamos atribuindo o nome da propriedade chamada à uma chave do nosso dicionário, e o valor que foi atribuído a ela para o valor do item do dicionário.
Pronto! Com isso já é possível chamar qualquer propriedade na nossa sessão.
Nas linhas 13 a 15 fazemos o mesmo mas para um get. Sempre que tentar obter um valor de uma propriedade em um objeto dynamic o .net irá verificar se a propriedade existe, e caso não exista será chamado o método TryGetMember.

Com isso podemos executar o código do teste abaixo:

1
2
3
4
5
6
7
8
9
10
[TestMethod]
public void Deve_Criar_Uma_Propriedade_Nome_E_outra_Sobrenome()
{
    dynamic sessaoDinamica = new SessaoDinamica();
    sessaoDinamica.Nome = "Vinicius";
    sessaoDinamica.Sobrenome = "Quaiato";
 
    Assert.AreEqual(sessaoDinamica.Nome, "Vinicius");
    Assert.AreEqual(sessaoDinamica.sobrenome, "Quaiato");
}

Nas linhas 5 e 6 estamos setando duas propriedade que “não existem” definidas na nossa classe SessaoDinamica, mas o TrySetMember está fazendo a mágica “por baixo dos panos”.
E nas linhas 8 e 9 estamos obtendo o valor das duas propriedades e o TryGetMember está fazendo a mágica também.
Note que na linha 9 usamos a propriedade com letra minúscula, podendo trabalhar com elas de modo case-sensitive ou case-insensitive.

É isso galera.
Tenho certeza que as capacidades dinâmicas do .net 4 irão fornecer base para muitos trabalhos interessantes, tanto em projetos na comunidade quanto em projetos particulares.

Qualquer dúvida é só postar aqui ou escrever um email.

Abraços,
Vinicius Quaiato.

Injeção de Dependência no C#

Filed Under (.NET, Boas Práticas, Patterns) by Vinicius Quaiato on 21-12-2009

Tagged Under : , , , , ,

Hoje vamos falar um pouco sobre Injeção de Dependências no C#.

Injeção de Dependência é uma das formas de obter Inversão de Controle.

O nome já diz quase tudo, quando uma classe possui dependência de alguma outra classe concreta, devemos então criar uma dependência para uma interface, ou seja, uma abstração.
Com nossa classe dependendo de uma abstração, nós injetamos um objeto concreto nela.

É um conceito bastante simples, vamos entender com um pouco de código.

A classe abaixo é uma classe de acesso ao banco de dados. Ela é responsável por executar um comando SQL apenas:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public class SqlClass
{
    public void ExecutarComando(string comando)
    {
        try
        {
            using (SqlConnection conexao = new SqlConnection("CONNECTION STRING"))
            {
                using (SqlCommand comandoSql = conexao.CreateCommand())
                {
                    comandoSql.CommandText = comando;
                    comandoSql.CommandType = CommandType.Text;
 
                    comandoSql.ExecuteNonQuery();
                }
            }
        }
        catch (SqlException sqlEx)
        {
            new LogErros().RegistrarArquivoTexto(sqlEx.Message);
 
            throw sqlEx;
        }
    }
}

Qual o problema desta classe? Simples, ela depende de uma classe concreta de log, como pode ser visto na linha 20.

O que podemos fazer para resolver este problema?
Em primeiro lugar precisamos extrair uma interface para a geração de logs, teríamos uma interface mais ou menos assim:

public interface ILogErros
{
    void RegistrarErro(string mensagemDeErro);
}

Agora fazemos nossa classe de banco de dados conhecer esta interface e criar uma forma de ter um objeto que implemente esta interface injetado:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
public class SqlClass
{
    private ILogErros logErros = null;
 
    public SqlClass(ILogErros objetoLog)
    {
        this.logErros = objetoLog;
    }
 
    public void ExecutarComando(string comando)
    {
        try
        {
            using (SqlConnection conexao = new SqlConnection("CONNECTION STRING"))
            {
                using (SqlCommand comandoSql = conexao.CreateCommand())
                {
                    comandoSql.CommandText = comando;
                    comandoSql.CommandType = CommandType.Text;
 
                    comandoSql.ExecuteNonQuery();
                }
            }
        }
        catch (SqlException sqlEx)
        {
            logErros.RegistrarErro(sqlEx.Message);
 
            throw sqlEx;
        }
    }
}

Na linha 3 criamos um campo na classe do tipo da interface. É importante perceber que agora nossa classe de banco de dados não conhece o objeto de log, ela apenas conhece sua interface. Ela não sabe como o log será gravado.
Nas linhas 5 a 8 criamos um construtor que recebe um objeto que implementa a interface ILogErros, e este construtor irá garantir que quem quer que instancie a classe tenha que injetar um objeto de log para ela. E isto é Injeção de Dependências!

Este tipo de injeção de dependência é conhecido como Constructor Injection, ou seja, injeção via construtor.

Agora para que consigamos instanciar nossa classe SqlClass precisamos passar um objeto que implemente ILogErros, algo mais ou menos assim:

SqlClass sql = new SqlClass(new LogEmArquivoTexto());

Onde LogEmArquivoTexto implementa ILogErros.

Podemos usar o recurso de Inversão de Controle visto aqui para criarmos uma factory que já nos retorne um objeto SqlClass com a dependência injetada, nos poupando algum trabalho.

E no próximo post veremos como utilizar o Unity, um contêiner de injeção de dependências da Microsoft.

Abraços galera, espero que tenham gostado.
Qualquer dúvida é só escrever.

Att,
Vinicius Quaiato.

ExpandoObject: dinamismo no .NET 4.0

Filed Under (.NET, .NET 4.0, Visual Studio 2010) by Vinicius Quaiato on 15-12-2009

Tagged Under : , , , ,

Fala galera, hoje vamos falar um pouco sobre dynamic no .NET 4.0.

Dynamic é um novo tipo introduzido no .net framework 4.0, é um tipo estático assim como os outros tipos do framework, no entanto ele ignora as verificações estáticas em tempo de compilação.
Deve-se prestar atenção, então, aos erros que podem acontecer em runtime, pois um código que não existe e seja chamado gerará um erro em tempo de execução.

Alguns podem achar que isso é um problema, esse papo todo de runtime e etc, eu já não enxergo desta maneira, vejo como uma oportunidade para novas criações.
Diversas empresas e projetos que trabalham com .net se deparam em situações onde a equipe diz:
“Ah se isso fosse diferente… Poderíamos fazer de forma mais simples ou legível…”.
Isso não é uma coisa ruim, é um sinal de que em algumas situações necessitamos de algo mais dinâmico do que o que o .net proporciona (proporcionava) até então.

Bom vamos falar um pouco do ExpandoObject.
ExpandoObject é um objeto que pode ter membros adicionados ou removidos dinâmicamente. Com ele é possível definirmos métodos e propriedades em tempo de execução.
Talvez muitos de nós não vejamos vantagens neste tipo de feature logo de início, mas para muitos será uma feature muito interessante e que proporcionará um grande avanço.

Vamos imaginar o seguinte cenário para a utilização do ExpandoObject:
Um sistema consome diversos webservices de empresas distintas de um mesmo segmento, porém, para cada usuário do sistema configuramos uma permissão diferente aos serviços oferecidos por estes webservices.
Vejamos um código de exemplo (lembrando que você precisa do Visual Studio 2010 beta 2).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
using System;
using System.Dynamic;
 
namespace ExpandoObjectApplication
{
    class Program
    {
        static void Main(string[] args)
        {
            dynamic objetoDinamico = new ExpandoObject();
            dynamic Sistema1 = new ExpandoObject();
            dynamic Sistema2 = new ExpandoObject();
 
            Sistema1.PodeAcessar = false;
            Sistema1.AlgumaAcao = (Func<string>)(() =>
            {
                if (Sistema1.PodeAcessar)
                    return "AlgumaAcao no Sistema1";
                else
                    return "Você não pode acessar este serviço";
            });
            objetoDinamico.Sistema1 = Sistema1;
 
            Sistema2.PodeAcessar = true;
            Sistema2.OutraAcao = (Func<int>)(() =>
            {
                if (Sistema2.PodeAcessar)
                    return 1 + 1;
                else
                    throw new Exception("Você não pode acessar este serviço");
            });
            objetoDinamico.Sistema2 = Sistema2;
 
            Console.WriteLine("objetoDinamico.Sistema1.AlgumaAcao: {0}", objetoDinamico.Sistema1.AlgumaAcao());
 
            Console.WriteLine("objetoDinamico.Sistema2.OutraAcao: {0}", objetoDinamico.Sistema2.OutraAcao());
 
            Console.ReadKey();
        }
    }
}

Na linha 2 incluímos uma referência para System.Dynamic, necessário para utilizar o ExpandoObject.
nas linhas 10, 11 e 12 criamos 3 objetos dynamic do tipo ExpandoObject. O primeiro objeto será nosso objeto de permissões. Os objetos Sistema1 e Sistema2 serão cada um a permissão e o acesso ao serviço de terceiros.
Na linha 14 nós criamos uma propriedade em Sistema1 e setamos o seu valor para false.
Nas linhas 15 a 21 estamos definindo um método para o objeto Sistema1. Este método verifica se a propriedade PodeAcessar está com o valor true e então executa o corpo do método.
Na linha 22 dizemos que a propriedade Sistema1 do objeto objetoDinamico é do tipo ExpandoObject, e setamos o seu valor atribuindo a ela o objeto Sistema1.
Nas linhas 24 a 32 fazemos as mesmas coisas para o objeto Sistema2.

O resultado pode ser conferido na imagem a seguir:

Resultado ExpandoObject

Resultado ExpandoObject

Uma das desvantagens para quem está acostumado com o Visual Studio é que os objetos dynamic não possuem intellisense. Talvez isso não seja algo ruim, ou talvez seja, depende bastante do cenário em que é utilizado.

Dynamic object intellisense

Dynamic object intellisense

É isso galera, um outro exemplo do uso de ExpandoObject pode ser visto aqui.

Att,
Vinicius Quaiato.