Elemar DEV

Usando Asp.net Web API HttpClient para consumir serviços REST

elemarjr — Tue, 22 May 2012 02:12:14 +0000

Olá pessoal. Tudo certo?!

Asp.net Web API é uma excelente alternativa para desenvolvimento de serviços Web. Pessoalmente, acredito que ela vai revolucionar a forma como desenvolvemos aplicativos.

Um dos pontos fortes dessa biblioteca é a facilidade de consumir serviços produzidos com ela em JavaScript – visto que eles operam facilmente através de HTTP/Json. Entretanto, para aplicativos desenvolvidos em outras linguagens “a coisa” não é tão simples. HttpClient, que é parte do Asp.net Web API, facilita consideravelmente o desenvolvimento de clientes desse tipo.

Para ilustrar como HttpClient funciona, desenvolvi algum código demonstrativo e alguns learning tests. Eles estão no Github. Nesse post, mostro trechos de código mais importantes.

O serviço que desejamos consumir

O serviço que desejamos consumir é um “CRUD” para essa entidade:

namespace Learning.HttpClientAPI.Entities
{
    public class Person
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Email { get; set; }
    }
}

Que é mantido por esse repositório:

using System.Linq;
using System.Collections.Generic;

using Learning.HttpClientAPI.Entities;


namespace Learning.HttpClientAPI.Repositories
{
    public class PeopleRepository
    {   
        List data = new List
        {
            new Person {Id=1, Name="John Doe", Email="john@hotmail.com"},
            new Person {Id=2, Name="Mike Myers", Email="myers@hotmail.com"},
            new Person {Id=3, Name="Joseph Climber", Email = "climber@hotmail.com"},
            new Person {Id=1, Name="Mikaela Romanova", Email="mika@hotmail.com"},
        };

        private int newId = 4;

        public IEnumerable GetAll()
        {
            return data;
        }

        public Person Get(int id)
        {
            return data.FirstOrDefault(person => person.Id == id);
        }

        public Person Add(Person person)
        {
            person.Id = newId++;
            data.Add(person);
            return person;
        }

        public bool Update(Person person)
        {
            var index = data.FindIndex(p => p.Id == person.Id);
            if (index == -1) return false;

            data[index] = person;
            return true;
        }

        public void Remove(int id)
        {
            var index = data.FindIndex(p => p.Id == id);
            if (index == -1) return;
            data.RemoveAt(index);
        }
    }
}

Como pode ver, esse repositório mantém dados apenas em memória.

Agora, o serviço:

using System;
using System.Collections.Generic;
using System.Net;

using System.Net.Http;
using System.Web.Http;

using Learning.HttpClientAPI.Entities;
using Learning.HttpClientAPI.Repositories;

namespace Learning.HttpClientAPI.Controllers
{
    public class PeopleController : ApiController
    {
        static readonly PeopleRepository repository = 
            new PeopleRepository();

        public IEnumerable Get()
        {
            return repository.GetAll();
        }

        public Person Get(int id)
        {
            var result = repository.Get(id);
            if (result == null)
                throw new HttpResponseException(new HttpResponseMessage(HttpStatusCode.NotFound));
            return result;
        }

        public HttpResponseMessage Post(Person newPerson)
        {
            newPerson = repository.Add(newPerson);

            var result = Request.CreateResponse(HttpStatusCode.Created);
            result.Content = result.CreateContent(newPerson);
            var url = Url.Route("DefaultApi", new { id = newPerson.Id });
            result.Headers.Location = new Uri(url, UriKind.Relative);
            
            return result;
        }

        public void Put(int id, Person person)
        {
            person.Id = id;
            if (!repository.Update(person))
            {
                throw new HttpResponseException(new HttpResponseMessage(HttpStatusCode.NotFound));
            }
        }

        public HttpResponseMessage Delete(int id)
        {
            repository.Remove(id);
            return new HttpResponseMessage(HttpStatusCode.NoContent);
        }
    }
}

Tomei o cuidado de seguir as recomendações de implementação do Http.

Um exemplo simples usando HttpClient

Agora, vamos ver como consumir esse serviço usando HttpClient. Para mostrar como HttpClient funciona, comecemos com um projeto console simples.

Para começar, referências:

Essas são as referências necessárias para HttpClient. Como já é prática, utilizei NuGet para adicionar as referências que são necessárias.

Agora, vejamos a implementação:

using System.Json;
using System.Net.Http;

namespace Learning.HttpClient.Console
{
    internal class Program
    {
        private static void Main()
        {
            var client = new System.Net.Http.HttpClient();
 
            client.GetAsync("http://localhost:8585/api/people")
                .ContinueWith(requestTask =>
                {
                    var response = requestTask.Result;
                    response.EnsureSuccessStatusCode();

                    response.Content.ReadAsAsync().ContinueWith(readTask =>
                    {
                        foreach (var item in readTask.Result)
                        {
                            System.Console.WriteLine(item["Name"]);
                        }
                    });
                });
 
            System.Console.ReadLine();
        }
    }
}

Repare que:

“Tudo acontece” em torno do objeto HttpClient;
Toda implementação foi planejada para suporte assíncrono;

Penso que o código é auto-explicativo, então …

Agora, vejamos a facilidade que o async do C# 5 vai trazer (veja os posts que já escrevi sobre o tema):

using System.Json;
using System.Net.Http;

namespace Learning.HttpClient.ConsoleWithAsync
{
    internal class Program
    {
        private static void Main()
        {
            GetData();
            
            System.Console.ReadLine();
        }

        private static async void GetData()
        {
            var client = new System.Net.Http.HttpClient();

            var response = await client.GetAsync("http://localhost:8585/api/people");
            response.EnsureSuccessStatusCode();
            var people = await response.Content.ReadAsAsync();

            foreach (var person in people)
            {
                System.Console.WriteLine(person["Name"]);
            }
        }
    }
}

Bem mais limpo. Não acha?!

Learning Tests

Para entender como HttpClient funciona, de verdade, vamos escrever também alguns learning tests.

Referências

Como estamos em um projeto de testes, com automação, adicionei IISExpress Automation Library (que desenvolvemos há aqui no blog).

Implementação

Nossos exemplos, até aqui, foram simples. Agora, vamos ver como executar todas as operações associadas com um CRUD.

Eis os testes:

using System;
using System.IO;
using System.Net.Http.Formatting;
using NUnit.Framework;
using SharpTestsEx;
using IISExpressAutomation;

using System.Threading;
using System.Net.Http;
using System.Json;
using System.Net.Http.Headers;

using Learning.HttpClientAPI.Entities;
using System.Net;

namespace Learning.HttpClientAPI.Tests
{
    [TestFixture]
    public class GettingStarted
    {
        private IISExpress iis;

        [TestFixtureSetUp]
        public void Setup()
        {
            var path = Path.GetFullPath(@"..\..\..\Learning.HttpClient");
            Console.WriteLine(path);
            iis = new IISExpress(new Parameters
                    {
                        Port = 8585,
                        Path = path
                    }
                );
            Thread.Sleep(1000);
        }

      
        [Test]
        public void GettingAllData()
        {
            var client = new HttpClient();

            var getAsyncResult = client.GetAsync("http://localhost:8585/api/people").Result;
            getAsyncResult.EnsureSuccessStatusCode();
            var data = getAsyncResult.Content.ReadAsAsync().Result;
            data.Count.Should().Be.GreaterThanOrEqualTo(3);

            foreach (var item in data)
                Console.WriteLine(item["Name"]);

            client.Dispose();
        }

        [Test]
        [TestCase(1, "John Doe")]
        [TestCase(2, "Mike Myers")]
        [TestCase(3, "Joseph Climber")]
        public void GettingItem(int id, string expectedName)
        {
            var client = new HttpClient();

            var address = string.Format("http://localhost:8585/api/people/{0}", id);

            var getAsyncResult = client.GetAsync(address).Result;
            getAsyncResult.EnsureSuccessStatusCode();
            var person = getAsyncResult.Content.ReadAsAsync().Result;
            person.Name.Should().Be(expectedName);
                    
            client.Dispose();
        }

        [Test]
        public void ResourceNotFound()
        {
            using (var client = new HttpClient())
            {
                const string address = "http://localhost:8585/api/people/10";
                var getAsyncResult = client.GetAsync(address).Result;
                getAsyncResult.Executing(g => g.EnsureSuccessStatusCode())
                    .Throws();
            }
        }

        [Test]
        public void PostItem()
        {
            var newPerson = new Person
            {
                Name = "Mary Jo",
                Email = "maryjo@hotmail.com"
            };

            using (var client = new HttpClient())
            {
                const string address = "http://localhost:8585/api/people";
                var requestMessage =  CreateHttpRequestMessage(newPerson);

                var postAsyncResult = client.PostAsync(address, requestMessage.Content).Result;
                postAsyncResult.EnsureSuccessStatusCode();

                var person = postAsyncResult.Content.ReadAsAsync().Result;
                person.Name.Should().Be(newPerson.Name);
                person.Id.Should().Be.GreaterThanOrEqualTo(4);
            }
        }

        [Test]
        public void PuItem()
        {
            string expectedName;
            var updatedPerson = new Person
            {
                Id = 2,
                Name = expectedName = "Malcon Myers",
                Email = "mmyers@hotmail.com"
            };

            using (var client = new HttpClient())
            {
                const string address = "http://localhost:8585/api/people/2";
                var requestMessage = CreateHttpRequestMessage(updatedPerson);

                var putAsyncResult = client.PutAsync(address, requestMessage.Content).Result;
                putAsyncResult.EnsureSuccessStatusCode();

                var getAsyncResult = client.GetAsync(address).Result;
                getAsyncResult.EnsureSuccessStatusCode();
                var person = getAsyncResult.Content.ReadAsAsync().Result;
                person.Name.Should().Be(expectedName);
            }
        }

        private HttpRequestMessage CreateHttpRequestMessage(T data)
        {
            var mediaType = new MediaTypeHeaderValue("application/json");

            var jsonFormatter = new JsonMediaTypeFormatter();
            var requestMessage = new HttpRequestMessage(data, mediaType, new MediaTypeFormatter[] {jsonFormatter});

            return requestMessage;
        }

        [Test]
        public void DeleteItem()
        {
            using (var client = new HttpClient())
            {
                const string address = "http://localhost:8585/api/people/4";
                var deleteAsyncResult = client.DeleteAsync(address).Result;
                deleteAsyncResult.EnsureSuccessStatusCode();
                deleteAsyncResult.StatusCode.Should().Be(HttpStatusCode.NoContent);
            }
            
        }

        [TestFixtureTearDown]
        public void TearDown()
        {
            iis.Dispose();
        }

    }
}

O que eu gostaria de destacar:

Forcei uma implementação assíncrona requisitando a propriedade Result de cada método assíncrono de HttpClient;
O método EnsureSucessStatusCode garante que o serviço retornou adequadamente;
Há um método para cada verbo Http que necessitamos para “conversar” com nosso serviço.

Vejamos os testes em execução:

Era isso.

Tagged: AspNetMvc, async, Learning Tests, REST, WebAPI

Mens sana in corpore sano

elemarjr — Sun, 20 May 2012 23:40:42 +0000

Olá pessoal. Tudo certo!?

Quem disse que uma má notícia precisa ser ruim no todo?!

Meses atrás, descobri que sou diabético. Depois de anos de descuido comigo mesmo, dieta extremamente irresponsável e, acima de tudo, uma vida para lá de sedentária, vi minha rotina diária ser “forçosamente” modificada.

O que eu mudei?!

De um dia para o outro, eu, que não cuidava o que comia, passei a uma dieta saudável (com direito a saladas e tudo mais). Mais importante que isso: eu, que nunca havia pisado em uma academia de ginástica, passei a ser frequentador assíduo. Há semanas em que apareço seis vezes por lá. Se não bastasse, eu, que não gostava de sair, passei a buscar meios bacanas de me divertir. Comecei a dançar (algo que eu sempre gostei) e, o que é mais incrível, comecei a sair para dançar.

Tudo é uma questão de hábito

Não vou mentir. Já odiei saladas. Tinha pavor sincero de comida saudável. Havia semanas em que comia “junk-food” todos os dias. Já foi rotina, por exemplo, tomar mais de 2 litros de coca-cola em um turno. Hoje, sou disciplinado. Entendi que é “comer para viver” e não o contrário.

Não conseguia me imaginar saindo de casa para ir a uma academia! Pensava: “esteira?! bicicleta?! Nem pensar! Andar tanto e não sair do lugar – coisa de louco.”. Lembro que, no meu primeiro dia na academia, mal aguentei caminhar 20 min. Hoje, vou a academia regularmente e venho aumentando minhas cargas consideravelmente. Se não posso dizer que gosto, já posso dizer que, quando não vou, sinto falta.

Também não gostava de sair de casa. Adorava minha cama, meu sofá. Ano passado, resolvi mudar isso também, Fui fazer aulas de dança. Aprendi (de verdade) a sambar e… descobri que adoro isso! Hoje, saio quase toda semana.

Há quem diga que bastam 21 repetições para criar um novo hábito. Não sei se é verdade, mas, para mim, bastou apenas boa vontade.

Se o homem se acostuma a tudo, inclusive a viver mal, por que não se acostumar com o bom?!

Com o tempo, desafios são superados

Eu, que não caminhava até a esquina, resolvi ir um pouco mais longe. Hoje, por exemplo, acordei as 4 da manhã (sim, em um domingo), peguei o carro, fui até Porto Alegre, e corri o “Circuito das Estações”. Foram 5km correndo, sem pausa para caminhadas e.. foi muito bom.

Ainda não estou em forma e, por isso, me senti, inicialmente, um pouco deslocado. Todo mundo parecia tão bem! Mas, tinha um objetivo. Um desafio, na verdade. Queria correr 5 km, sem pausas para caminhar, na rua. Consegui!

Sei que não é bonito, mas, me sentia bem, mesmo “gordinho” (ainda!), passando os “em forma” que cansavam e começavam a caminhar.

Novo contexto, boas amizades

Obviamente, tudo fica muito melhor quando temos boas amizades. Hoje, por exemplo, contei com a companhia e apoio do meu amigo Anderson Comberlato (colega de trabalho e ex-aluno de informática [há quase 15 anos atrás]) e a Kátia Webber (minha personal trainer e grande amiga).

Conhecer gente nova, com bons hábitos, é algo muito bom.

Alguns resultados

Compilando alguns resultados, posso dizer:

Quando comecei, pesava 140Kg. Hoje, peso 106Kg (ainda estou obeso, mas faltam só 3Kg para deixar essa categoria).
Quando comecei, não conseguia caminhar 20 minutos. Hoje, CORRO 5Km, NA RUA.
Quando comecei, comia “junk-food” e dormia mal. Hoje, tenho uma dieta saudável e digo: “Sim, MVPs dormem!”

Concluindo…

Mens sana in corpore sano faz sentido! Se não estou “pensando bem”, posso dizer que, com certeza, estou “pensando melhor”.

BTW, há mais fotos do dia de hoje no meu Facebook.

Era isso.

Tagged: DevEmForma

IISExpress Automation agora está disponível no NuGet

elemarjr — Sun, 20 May 2012 01:46:57 +0000

Olá pessoal. Tudo certo?!

No último post, mostrei como controlar o IISExpress através de código em C#.

Depois de publicado o post, resolvi trabalhar um pouco mais naquele código e disponibilizar o resultado no NuGet.

Para obter o pacote

Resolvi chamar esse pequena contribuição de “IISExpress Automation Library”. Ela já está disponível no NuGet.

Sobre o código-fonte

O código-fonte foi revisado e melhorado. Está integralmente disponível no GitHub.

Espero contribuições.

Era isso.

Tagged: Aviso, FOSS, IIS, NuGet

Controlando o IISExpress, no código, através de automação

elemarjr — Fri, 18 May 2012 23:57:55 +0000

Olá pessoal. Tudo certo?!

Você conhece o IISExpress? Em caso negativo, recomendo que leia esse post do Scott Guthrie.

IISExpress é uma excelente alternativa para que possamos levantar nossos sites e/ou serviços para realizar testes de aceitação.

Como ele está baseado em um utilitário de linha de comando, mostro aqui um exemplo simples de automação para que possamos controlar o mesmo em nossos códigos.

Esse post será, fundamentalmente, código. Se você deseja entender melhor como funciona automação de interfaces, recomendo ler os outros posts que já escrevi sobre o tema.

Automação para IISExpress

No código que segue, assumo que o IISExpress está instalado na sua pasta padrão. Veja:

using System;
using System.Diagnostics;
using System.Runtime.InteropServices;

namespace Automation
{
    internal class NativeMethods
    {
        // Methods
        [DllImport("user32.dll", SetLastError = true)]
        internal static extern IntPtr GetTopWindow(IntPtr hWnd);

        [DllImport("user32.dll", SetLastError = true)]
        internal static extern IntPtr GetWindow(IntPtr hWnd, uint uCmd);

        [DllImport("user32.dll", SetLastError = true)]
        internal static extern uint GetWindowThreadProcessId(IntPtr hwnd, out uint lpdwProcessId);

        [DllImport("user32.dll", SetLastError = true)]
        internal static extern bool PostMessage(HandleRef hWnd, uint Msg, IntPtr wParam, IntPtr lParam);
    }

    internal class IISExpressProcessEnvelope : IDisposable
    {
        private readonly Process process;

        public IISExpressProcessEnvelope(Process process)
        {
            this.process = process;
        }

        #region IDisposable Members

        public void Dispose()
        {
            NativeMethods.PostMessage(
                GetHandleRef(), 
                0x12, 
                IntPtr.Zero, 
                IntPtr.Zero
                );
            process.Dispose();
        }

        #endregion

        private HandleRef GetHandleRef()
        {
            IntPtr ptr = NativeMethods.GetTopWindow(IntPtr.Zero);

            while (ptr != IntPtr.Zero)
            {
                uint num;
                NativeMethods.GetWindowThreadProcessId(ptr, out num);
                if (process.Id == num)
                    return new HandleRef(null, ptr);
                ptr = NativeMethods.GetWindow(ptr, 2);
            }

            throw new NullReferenceException("Process window not found.");
        }
    }

    public class IISExpress : IDisposable
    {
        private readonly IISExpressProcessEnvelope process;

        public IISExpress(int port, string path)
        {
            var info = new ProcessStartInfo
            {
                FileName = @"c:\Program Files (x86)\IIS Express\iisexpress.exe",
                Arguments = string.Format("/port:{0} /path:{1}", port, path)
            };

            process = new IISExpressProcessEnvelope(Process.Start(info));
        }

        #region IDisposable Members

        public void Dispose()
        {
            process.Dispose();
        }

        #endregion
    }
}

Destacando:

Faço automação através usando a API do Windows;
Inicio a execução do IISExpress quando a classe é criada e encerro na chamada do Dispose;
Criei um “Envelope” para separar a manipulação do processo da lógica principal.

Trata-se de uma solução muito simples. Além disso, sei que o design desse código poderia ser muito melhor. Por isso, ele está em um Gist. Adoraria ver sugestões de melhoria.

Exemplo de uso

O programa que segue, “levanta” um site na porta 8080. Veja:

using System;

namespace Automation.Demo
{
    class Program
    {
        static void Main()
        {
            using (var iis = new IISExpress(8080, @"c:\git\Garbage\WebDirectory\WebDirectory"))
            {
                Console.WriteLine("Pressione qq tecla para fechar.");
                Console.ReadLine();
            }

        }
    }
}

Bacana, não?! Perceba que não há restrição em quantas aplicações sejam “levantadas” simultaneamente.

Era isso.

Tagged: IIS, UIAutomation

FluentCodeMetrics – Parte 6 – TypeSets

elemarjr — Fri, 18 May 2012 01:18:48 +0000

Olá pessoal. Tudo certo?!

Até aqui, calculamos Ce para tipos individualmente. Mas, como proceder para calcular Ce para outras “unidades de análise”. Por exemplo, para um assembly ou namespace.

Nesse post, apresento como implementei esse importante avanço no FluentCodeMetrics (veja outros posts relacionados).

Lembre-se: todo código-fonte para FluentCodeMetrics está no Github.

DISCLAIMER: Adoraria sugestões de design. Veja o repositório para entender o projeto e, se possível, me ajude.

Cenários que desejamos implementar

Basicamente, pretendo implementar dois cenários novos:

1. Desejo poder restringir o cálculo do Ce para referências com tipos de determinados assemblies.

2. Desejo calcular Ce para um conjunto de tipos, por exemplo, para um assembly/namespace.

Pegou a idéia?!

Filtro de Assembly

Vamos começar atendendo o primeiro cenário. Começamos com um novo TypeFilter. Veja:

using System;
using System.Reflection;

namespace FluentCodeMetrics.Core.TypeFilters
{
    public class FromAssemblyTypeFilter : TypeFilter
    {
        private readonly Assembly assemblyField;

        internal FromAssemblyTypeFilter(Assembly assembly)
        {
            assemblyField = assembly;
        }

        public override bool Check(Type type)
        {
            return type.Assembly == assemblyField;
        }
    }
}

Além disso, mudei o TypeFilter (veja o código completo no github) para criar um “method helper”. Veja:

public static implicit operator TypeFilter(Assembly assembly)
{
    return FromAssembly(assembly);
}

public static TypeFilter FromAssembly(Assembly assembly)
{
    return new FromAssemblyTypeFilter(assembly);
}

Agora, para inferir as Ce para uma classe, apenas considerando referências para tipos do mesmo assembly, basta escrever algo assim:

Ce.For()
    .Ignoring(typeof(Foo).GetType().Assembly.Not());

TypeSet

Já conseguimos verificar Ce para tipos individuais. Entretanto, muitas vezes, desejaremos trabalhar com um conjunto de tipos (um assembly inteiro, ou um namespace).

Para isso, criei o conceito de TypeSet. Veja:

using System;
using System.Reflection;
using System.Collections.Generic;

namespace FluentCodeMetrics.Core.TypeSets
{
    public abstract class TypeSet : IEnumerable
    {
        public abstract IEnumerable GetAllTypes();

        public IEnumerator GetEnumerator()
        {
            return GetAllTypes().GetEnumerator();
        }

        System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
        {
            return GetAllTypes().GetEnumerator();
        }

        public static TypeSet FromAssembly(Assembly assembly)
        {
            return new CollectionTypeSet(assembly.GetTypes());
                // AssemblyTypeSet(assembly);
        }

        public static TypeSet With(params Type[] types)
        {
            return new CollectionTypeSet(types);
        }

        public static implicit operator TypeSet(Assembly source)
        {
            return FromAssembly(source);
        }
    }
}

Essa classe base tem uma especialização (por agora). Veja:

using System;
using System.Collections.Generic;

namespace FluentCodeMetrics.Core.TypeSets
{
    public class CollectionTypeSet : TypeSet
    {
        private IEnumerable source; 
        public CollectionTypeSet(IEnumerable source)
        {
            this.source = source;
        }

        public override IEnumerable GetAllTypes()
        {
            return source;
        }
    }
}

Aproveitando, também criei um TypeFilter para esse TypeSet. Veja:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace FluentCodeMetrics.Core.TypeFilters
{
    public class CollectionTypeFilter : TypeFilter
    {
        private readonly IEnumerable typesField;

        internal CollectionTypeFilter(IEnumerable types)
        {
            typesField = types;
        }

        public override bool Check(Type type)
        {
            return typesField.Contains(type);
        }
    }
}

Com mais alguns métodos auxiliares, posso escrever um filtro para diversos tipos dessas duas formas:

using System;

using NUnit.Framework;
using SharpTestsEx;
using FluentCodeMetrics.Core;
using FluentCodeMetrics.Core.TypeSets;

namespace FluentCodeMetrics.Tests
{
    [TestFixture]
    public class CeTests
    {
        [Test]
        public void Ce_ForSingleArgCtorIgnoringCommonTypes()
        {
            var ce = Ce.For()
                .Ignoring()
                .Ignoring()
                .Ignoring()
                .Ignoring()
                .Ignoring()
                .Ignoring()
                .Ignoring()
                .Ignoring()
                .Ignoring();

            ce.Value.Should().Be(1);
            ce.References.Should().Have.SameValuesAs(
                new[] {typeof (Samples.Fee)}
                );
        }

        [Test]
        public void Ce_ForSingleArgCtorIgnoringTypeSet()
        {
            var ce = Ce.For()
                .Ignoring(TypeSet.With(
                    typeof(System.Runtime.TargetedPatchingOptOutAttribute),
                    typeof(System.Security.SecuritySafeCriticalAttribute),
                    typeof(System.Runtime.ConstrainedExecution.ReliabilityContractAttribute),
                    typeof(System.Runtime.CompilerServices.CompilerGeneratedAttribute),
                    typeof(object),
                    typeof(int),
                    typeof(string),
                    typeof(bool),
                    typeof(Type)
                ));

            ce.Value.Should().Be(1);
            ce.References.Should().Have.SameValuesAs(
                new[] { typeof(Samples.Fee) }
                );
        }

        [Test]
        public void Ce_ForSingleArgCtorIgnoringOtherAssembliesTypes()
        {
            var ce = Ce.For()
                .Ignoring(typeof (Samples.SingleArgCtor).Assembly.Not());
                
            ce.Value.Should().Be(1);
            ce.References.Should().Have.SameValuesAs(
                new[] { typeof(Samples.Fee) }
                );
        }
    }
}

Ce suportando tipos e/ou TypeSets

Agora temos condições de rever o design do Ce para que este suporte tipos individuais ou conjuntos. Veja:

using System;
using System.Linq;

using FluentCodeMetrics.Core.TypeFilters;
using FluentCodeMetrics.Core.TypeSets;
using System.Collections.Generic;

namespace FluentCodeMetrics.Core
{
    public abstract class Ce
    {
        public int Value
        {
            get { return References.Count(); }
        }

        public abstract ReferencedTypesTypeSet References { get; }

        public static implicit operator int(Ce source)
        {
            return source.Value;
        }

        public abstract Ce FilterBy(TypeFilter filter);

        public Ce Ignoring(TypeFilter toIgnore)
        {
            return FilterBy(toIgnore.Not());
        }

        public Ce Ignoring()
        {
            return Ignoring(typeof(T));
        }

        public static TypeSetCe For(TypeSet typeSet)
        {
            var source = from type in typeSet
                         select For(type);

            return new TypeSetCe(source);
        }

        public static TypeCe For(Type type)
        {
            var references = ReferencesInspector.For(type)
                .Where(type.NestedTypes().Not());
            return new TypeCe(references, type);
        }

        public static TypeCe For()
        {
            return For(typeof (T));
        }
    }

   
    public class TypeCe : Ce
    {
        private readonly ReferencedTypesTypeSet references;
        private readonly Type type;
        public Type Type
        {
            get { return type;  }
        }

        internal TypeCe(ReferencedTypesTypeSet refs, Type type)
        {   
            references = refs;
            this.type = type;
        }

        public override ReferencedTypesTypeSet References
        {
            get { return references; }
        }

        public override Ce FilterBy(TypeFilter filter)
        {
            return filter == null ?
                this :
                new TypeCe(references.FilterBy(filter), Type);
        }
    }

    public class TypeSetCe : Ce
    {
        private IEnumerable source;

        public IEnumerable Source
        {
            get { return source; }
        }

        internal TypeSetCe(IEnumerable source)
        {
            this.source = source;
        }
        
        public override ReferencedTypesTypeSet References
        {
            get
            {
                var allReferences = from member in source
                                    from reference in member.References
                                    select reference;
                return new ReferencedTypesTypeSet(allReferences.Distinct(), null);
            }
        }

        public override Ce FilterBy(TypeFilter filter)
        {
            var newSource = source.Select(ceResult => ceResult.FilterBy(filter)).ToList();
            return new TypeSetCe(newSource);
        }
    }
}

Pegou a idéia?!

Era isso.

Tagged: FluentCodeMetrics

Primeiros passos com o AutoMapper

elemarjr — Thu, 17 May 2012 02:32:17 +0000

Olá pessoal. Tudo certo?!

Muitas vezes, precisamos “transportar” valores de um objeto (com um tipo) para outro objeto (com outro tipo). Um cenário comum para essa necessidade, é a criação de ViewModels. Essa atividade é conhecida como Mapping.

No post de hoje, mostro Learning Tests com AutoMapper – uma bibilieca que facilita muito essa atividade.

Como de costume, todo o código-fonte está no Github.

O que é o AutoMapper?

Segundo o site oficial:

AutoMapper is a simple little library built to solve a deceptively complex problem – getting rid of code that mapped one object to another. This type of code is rather dreary and boring to write, so why not invent a tool to do it for us?

Seu código-fonte está no Github.

Referências necessárias

Mais uma vez, estaremos desenvolvendo Learning Tests. Logo, além da referência para o AutoMapper, adicionamos também referência para o NUnit e para o SharpTestsEx.

Getting Started

Comecemos com um exemplo simples.

using NUnit.Framework;
using SharpTestsEx;

using AutoMapper;

namespace Learning.AutoMapper
{
    [TestFixture]
    public class GettingStarted
    {

        [Test]
        public void MappingIntPropertyToStringProperty()
        {
            Mapper.CreateMap();
            Mapper.AssertConfigurationIsValid();
            
            var source = new Foo {Data = 3};
            var destination = Mapper.Map(source);

            destination.Data.Should().Be("3");
        }

        [Test]
        public void MappingStringPropertyToIntProperty()
        {
            Mapper.CreateMap();
            Mapper.AssertConfigurationIsValid();

            var source = new Fee { Data = "3" };
            var destination = Mapper.Map(source);

            destination.Data.Should().Be(3);
        }

        [Test]
        public void MappingStringPropertyToIntProperty_SourceIsNull()
        {
            Mapper.CreateMap();
            Mapper.AssertConfigurationIsValid();

            var source = new Fee { Data = null };
            var destination = Mapper.Map(source);

            destination.Data.Should().Be(0);
        }


        class Foo
        {
            public int Data { get; set; }
        }

        class Fee
        {
            public string Data { get; set; }
        }
    }
}

Como pode perceber, há três etapas básicas na utilização AutoMapper:

Configuração – onde especificamos os tipos que desejamos mapear; Isso é feito, geralmente, na inicialização do sistema (ou site);
Verificação – O método AssertConfigurationIsValid garante que todas as propriedades no tipo “destino” tem um mapeamento para uma fonte de dados do tipo “origem”;
Mapeamento – Onde ocorre o mapeamento propriamente dito.

Perceba que a etapa 2 é opcional. Entretanto, fortemente recomendada.

Repare como o AutoMapper operacionaliza os castings automaticamente.

Flattening

Quando estamos trabalhando com ViewModels, geralmente o fazemos por querer trabalhar com modelos mais simples. Veja um exemplo:

using NUnit.Framework;
using SharpTestsEx;

using AutoMapper;

namespace Learning.AutoMapper
{
    [TestFixture]
    public class FlatteningSimple
    {
        [Test]
        public void HierarchyToFlattenObject()
        {
            Mapper.CreateMap();
            Mapper.AssertConfigurationIsValid();

            var source = new Person
            {
                Name = "Elemar Junior",
                Address = new Address
                {
                    Street = "St. Francis",
                    Number = 1024
                }
            };

            var destination = Mapper.Map(source);

            destination.Name.Should().Be(source.Name);
            destination.AddressStreet.Should().Be(source.Address.Street);
            destination.AddressNumber.Should().Be(source.Address.Number);
            destination.Salary.Should().Be(source.GetSalary());
        }


        class Address
        {
            public string Street { get; set; }
            public int Number { get; set; }
        }

        class Person
        {
            public string Name { get; set; }
            public Address Address { get; set; }
            public decimal GetSalary()
            {
                return 25;
            }
        }

        class PersonFlat
        {
            public string Name { get; set; }
            public string AddressStreet { get; set; }
            public int AddressNumber { get; set; }
            public decimal Salary { get; set; }
        }
    }
}

O AutoMapper reconhece os mapeamentos automaticamente em função do “regramento” no nome das propriedades.

Nesting Mapping

As vezes, queremos aplicar mapping em objetos filhos. Com AutoMapper isso é muito simples. Veja:

using System;

using NUnit.Framework;
using SharpTestsEx;

using AutoMapper;

namespace Learning.AutoMapper
{
    [TestFixture]
    public class NestedMappings
    {
        [Test]
        public void SrcToDst()
        {
            Mapper.CreateMap();
            Mapper.CreateMap();
            Mapper.AssertConfigurationIsValid();

            var source = new SrcParent()
            {
                Value = 3,
                Child = new SrcChild
                {
                    AnotherValue = 4
                }
            };

            var dest = Mapper.Map(source);
            dest.Value.Should().Be(source.Value);
            dest.Child.AnotherValue.Should().Be(
                source.Child.AnotherValue
                );
        }

        class SrcParent
        {
            public int Value { get; set; }
            public SrcChild Child { get; set; }
        }

        class SrcChild
        {
            public int AnotherValue { get; set; }
        }

        class DstParent
        {
            public int Value { get; set; }
            public DstChild Child { get; set; }
        }

        class DstChild
        {
            public int AnotherValue { get; set; }
        }
        
    }
}

Quando o Mapping automático não atende

Nem sempre teremos equivalência/compatibilidade de nomes nos objetos de origem e destino. Nesse caso, AutoMapper nos oferece algumas alteranativas. Veja:

using NUnit.Framework;
using SharpTestsEx;

using AutoMapper;

namespace Learning.AutoMapper
{
    [TestFixture]
    public class CustomResolver
    {
        [Test]
        public void SummarizeUsingCustomResolver()
        {
            Mapper.CreateMap()
                .ForMember(dst => dst.Total, opt => opt.ResolveUsing());

            Mapper.AssertConfigurationIsValid();

            var source = new Src {Value1 = 10, Value2 = 15};
            var dest = Mapper.Map(source);

            dest.Total.Should().Be(source.Value1 + source.Value2);
        }

        [Test]
        public void SummarizeUsingMapFrom()
        {
            Mapper.CreateMap()
                .ForMember(dst => dst.Total, opt => opt.MapFrom(src => src.Value1 + src.Value2));

            Mapper.AssertConfigurationIsValid();

            var source = new Src { Value1 = 10, Value2 = 15 };
            var dest = Mapper.Map(source);

            dest.Total.Should().Be(source.Value1 + source.Value2);
        }

        class TotalResolver : ValueResolver
        {
            protected override int ResolveCore(Src source)
            {
                return source.Value1 + source.Value2;
            }
        }

        class Src
        {
            public int Value1 { get; set; }
            public int Value2 { get; set; }
        }

        class Dst
        {
            public int Total { get; set; }
        }
    }
}

Acho que o código é auto-explicativo.

Concluindo…

Vejamos os testes:

AutoMapper ainda oferece recursos mais avançados, apropriados para cenários mais complexos. Mas, acho que o que mostrei aqui já cobre boa parte dos cenários de uso.

De qualquer forma, o código está no github. Qualquer coisa, dá um fork e amplia o projeto.

Era isso.

Tagged: AutoMapper, Learning Tests

Vou palestrar no MSDN Community BluDotNet

elemarjr — Wed, 16 May 2012 01:12:09 +0000

Olá pessoal. Tudo certo?!

Tive a honra de ser convidado para palestrar em um evento organizado pela comunidade BluDotNet, em Blumenau.

Será o MSDN Community BluDotNet. Ocorrerá no dia 23 de junho, sábado, no SENAI de Blumenau.

Inscrições serão abertas em breve.

Será muito bacana conversar e compartilhar conhecimentos com vocês.

Tagged: Aviso

Facilitando injeção de dependência com Ninject!

elemarjr — Wed, 16 May 2012 00:18:11 +0000

Olá pessoal. Tudo certo?!

Reduzir o acoplamento é fundamental para melhorar a qualidade do design de nossas aplicações. Uma das formas mais diretas de promover a redução de acoplamento éatravés a injeção de dependências (DI) e da inversão do controle (IoC).

Nesse post, apresento uma série de learning testes para o Ninject – um popular framework de injeção de dependências para .net. Será um post com “mais código e menos conversa”.

Todo o código-fonte desenvolvido está em um repositório no Github.

O que é Ninject?

Segundo o site oficial:

Ninject is a lightweight dependency injection framework for .NET applications. It helps you split your application into a collection of loosely-coupled, highly-cohesive pieces, and then glue them back together in a flexible manner. By using Ninject to support your software’s architecture, your code will become easier to write, reuse, test, and modify.

O código-fonte do Ninject está no Github.

Para aprender mais sobre DI e Ninject

Ninject possui uma excelente documentação online (o que é raro em projetos FOSS). Lá é possível aprender Ninject e conceitos fundamentais sobre DI.

Referências

Mais uma vez, estaremos desenvolvendo um Learning Test. Logo, além da referência para o Ninject, adicionamos também referência para o NUnit e para o SharpTestsEx.

Getting Started

Referências adicionadas, hora de por as “mãos na massa”. Veja:

using System;

using NUnit.Framework;
using SharpTestsEx;

using Ninject;


namespace Learning.Ninject
{
    [TestFixture]
    public class GettingStarted
    {
       
        [Test]
        public void BindIFooToFoo_GettingIFoo_ReturnsFooInstance()
        {
            var kernel = new StandardKernel();

            kernel
                .Bind().To();

            var result = kernel.Get();

            result.Should().Not.Be.Null();
            result.GetType().Should().Be(typeof (Foo));
        }

        [Test]
        public void BindIFooToFee_GettingIFoo_ReturnsFeeInstance()
        {
            var kernel = new StandardKernel();

            kernel
                .Bind().To();

            var result = kernel.Get();

            result.Should().Not.Be.Null();
            result.GetType().Should().Be(typeof(Fee));
        }

        [Test]
        [TestCase(typeof(IFoo), typeof(Foo))]
        [TestCase(typeof(IFoo), typeof(Fee))]
        public void BindingInterfaceToType_GettingInterface_ReturnsTypeInstance
            (Type @interface, Type concreteType)
        {
            var kernel = new StandardKernel();

            kernel
                .Bind(@interface).To(concreteType);

            var result = kernel.Get(@interface);

            result.Should().Not.Be.Null();
            result.GetType().Should().Be(concreteType);            
        }
    }

    public interface IFoo
    {
        string GetMessage();
    }

    class Foo : IFoo
    {
        public string GetMessage()
        {
            return "Hello from Foo";
        }
    }

    class Fee : IFoo
    {
        public string GetMessage()
        {
            return "Hello from Fee";
        }
    }
}

Aqui você pega a essência do Ninject. Basicamente:

Criamos um “kernel” que será o objeto responsável por “resolver” instâncias para os tipos que especificarmos;
Associamos implementações concretas para tipos (geralmente abstratos ou interfaces) que desejaremos resolver;
Usamos o “kernel” para carregar as instâncias.

Injetando dependências na inicialização

Com um Kernel configurado, podemos injetar dependências em nossos objetos de forma muito simples. Veja:

using System;

using NUnit.Framework;
using SharpTestsEx;

using Ninject;


namespace Learning.Ninject
{
    [TestFixture]
    public class Initialization
    {

        [Test]
        public void SingleCtor()
        {
            var kernel = new StandardKernel();

            kernel
                .Bind().To();

            var result = kernel.Get();

            result.Should().Not.Be.Null();
            result.Source.GetType().Should().Be(typeof(Fee));
        }

        [Test]
        public void TwoCtors()
        {
            var kernel = new StandardKernel();

            kernel
                .Bind().To();

            kernel
                .Bind().ToSelf();

            var result = kernel.Get();


            result.Should().Not.Be.Null();
            result.Source.GetType().Should().Be(typeof(Fee));
        }
    }

    public class Writer
    {
        public readonly IFoo Source;
        public Writer(IFoo source)
        {
            Source = source;
        }
    }

    public class Writer2
    {
        public readonly IFoo Source;
        [Inject]
        public Writer2(IFoo source)
        {
            Source = source;
        }

        public Writer2(Writer writer)
        {
            throw new NotImplementedException();
        }
    }
}

Repare que Ninject consegue “fornecer” valores adequados, especificados no construtor com mais argumentos, de acordo com os bindings que foram informados.

Repare também que quando há um “empate” entre construtores, resolvemos a “dúvidas” marcando o construtor “default” com o atributo Inject.

Injetando dependências através de métodos ou propriedades

Nem todas as dependências precisam estar explicitadas no consrutor. Veja:

using System;

using NUnit.Framework;
using SharpTestsEx;

using Ninject;


namespace Learning.Ninject
{
    [TestFixture]
    public class PropertyMethodInjection
    {

        [Test]
        public void PropertyInjection()
        {
            var kernel = new StandardKernel();

            kernel
                .Bind().To();

            var result = kernel.Get();
            result.FooInstance.Should().Not.Be.Null();
            result.FooInstance.GetType().Should().Be(typeof(Fee));
        }

        [Test]
        public void MethodInjection()
        {
            var kernel = new StandardKernel();

            kernel
                .Bind().To();

            var result = kernel.Get();
            result.GetDataType().Should().Be(typeof(Fee));
        }
    }

   class FooPropertyInjection
   {
       [Inject]
       public IFoo FooInstance { get; set; }
   }

    class FooMethodInjection
    {
        private IFoo data;

        [Inject]
        public void SetData(IFoo data)
        {
            this.data = data;
        }

        public Type GetDataType()
        {
            return data.GetType();
        }
    }
}

Como pode ver, basta marcar métodos ou propriedades para injeção de dependência com o atributo Inject.

Singleton

Todo mundo que começa lê o livro do GoF, pega uma doença: Singletite. Veja a versão Ninject dessa doença:

using System;

using NUnit.Framework;
using SharpTestsEx;

using Ninject;


namespace Learning.Ninject
{
    [TestFixture]
    public class Singleton
    {

        [Test]
        public void BindIFooToFooInSingletonScope_GettingIFooTwoTimes_ReturnsSameFooInstance()
        {
            var kernel = new StandardKernel();

            kernel
                .Bind().To().InSingletonScope();

            var resultA = kernel.Get();
            var resultB = kernel.Get();

            resultA.Should().Not.Be.Null();
            resultB.Should().Not.Be.Null();
            resultA.Should().Be.SameInstanceAs(resultB);
        }

        [Test]
        public void BindIFooToFooInstance_GettingIFooTwoTimes_ReturnsSameFooInstance()
        {
            var kernel = new StandardKernel();

            var source = new Foo();

            kernel
                .Bind().ToConstant(source);

            var resultA = kernel.Get();
            var resultB = kernel.Get();

            resultA.Should().Not.Be.Null();
            resultB.Should().Not.Be.Null();
            resultA.Should().Be.SameInstanceAs(resultB);
            source.Should().Be.SameInstanceAs(resultA);
        }
    }
}

Organizando a inicialização do Ninject usando módulos

Em uma aplicação real, é sempre uma boa prática organizar a inicialização do Ninject em uma “módulo”. Veja:

using System;

using NUnit.Framework;
using SharpTestsEx;

using Ninject;
using Ninject.Modules;


namespace Learning.Ninject
{
    [TestFixture]
    public class Modules
    {
        [Test]
        public void BindIFooToFooUsingModules_GettingIFoo_ReturnsFooInstance()
        {
            var kernel = new StandardKernel(new LearningTestModule());

            var result = kernel.Get();

            result.Should().Not.Be.Null();
            result.GetType().Should().Be(typeof (Foo));
        }
    }

    public class LearningTestModule : NinjectModule
    {
        public override void Load()
        {
            Bind().To();
        }
    }

}

Pegou a idéia, certo?!

Personalizando a inicialização de instâncias através de Providers

As vezes, a inicialização de objetos pode exigir um processo mais complexo. Para isso, podemos usar providers. Veja:

using System;

using NUnit.Framework;
using SharpTestsEx;

using Ninject;
using Ninject.Activation;


namespace Learning.Ninject
{
    [TestFixture]
    public class Providers
    {
        [Test]
        public void BindIFooToFooUsingProvider_GettingIFoo_ReturnsFooInstance()
        {
            var kernel = new StandardKernel();
            kernel.Bind().ToProvider(new FooProvider());

            var result = kernel.Get();

            result.Should().Not.Be.Null();
            result.GetType().Should().Be(typeof (Foo));
        }

        [Test]
        public void BindIFooToFooUsingMethod_GettingIFoo_ReturnsFooInstance()
        {
            var kernel = new StandardKernel();
            kernel.Bind().ToMethod(context => new Fee());

            var result = kernel.Get();

            result.Should().Not.Be.Null();
            result.GetType().Should().Be(typeof(Fee));
        }
    }

    class FooProvider : Provider
    {
        protected override IFoo CreateInstance(IContext context)
        {
            return new Foo();
        }
    }

}

Era isso.

Tagged: DI, IoC, Learning Tests, Ninject

Primeiros passos com Apache log4net

elemarjr — Tue, 15 May 2012 02:29:22 +0000

Olá pessoal. Tudo certo?!

Em muitos cenários, ter uma implementação efetiva de logging em nossas aplicações pode acelerar consideravelmente processos de depuração e/ou apoio ao cliente.

Implementar logging é uma tarefa relativamente simples. Entrentanto, trabalhosa. Além disso, é relativamente fácil implementar a “coisa errada”, causando prejuízo a performance do sistema.

No post de hoje, mostro os conceitos fundamentais do log4net. Uma biblioteca poderosa para logging.

Todo o código-fonte desenvolvido hoje está no meu github.

O que é log4net?

Segundo o site oficial:

The Apache log4net library is a tool to help the programmer output log statements to a variety of output targets. log4net is a port of the excellent Apache log4j™ framework to the Microsoft® .NET runtime. We have kept the framework similar in spirit to the original log4j while taking advantage of new features in the .NET runtime.

Trata-se de um projeto FOSS. Há um mirror de seu código-fonte no github.

Lógica de funcionamento

Para saber usar log4net, é importante entender seu modelo básico de funcionamento:

Para entender:

Logger – é a “interface” principal com o nosso código. Quando desejemos que alguma coisa entre no log, é para esse objto que enviamos mensagens;
Appender – é o responsável por “publicar” as informações enviadas para o logger. Um logger pode ter um ou vários appenders associados;
Filter – é usado para analisar a informação enviada ao logger e decidir se esta deverá ou não ser processada pelo appender. Um appender pode ter vários filters associados. Uma informação só será processada pelo appender se for “aprovada” for todos os filter;
Layout – "formata” a informação enviada ao logger em diferentes estilos.
ObjectRenderer – é uma espécie de “converter” para string de objetos.

log4net é extremamente flexíbel por permitir o ajuste fino de todos esses componentes. Isso pode ser feito tanto em código quanto em arquivos de configuração.

Referências necessárias

log4net possui pacote no GitHub.

Para o post de hoje, utilizei esse pacote junto com NUnit e sharpTestsEx. Veja:

Dois appenders para teste

Aproveitando a flexibilidade do log4net, desenvolvi dois appenders para facilitar testes. Em cenários reais, isso não seria necessário. log4net já possui um conjunto rico de appenders que permite, entre outras coisas: emitir informações no console, salvar informações em banco de dados, em arquivos texto e xml.

O primeiro appender que desenvolvi simplesmente acumula as informações em um StringBuilder. Veja:

using System.Text;

using log4net.Appender;
using log4net.Core;

namespace Learning.Log4Net.Appenders
{
    class StringAppender : AppenderSkeleton
    {
        private readonly StringBuilder buffer =
            new StringBuilder();

        public void Reset()
        {
            buffer.Length = 0;
        }

        protected override void Append(LoggingEvent loggingEvent)
        {
            buffer.Append(RenderLoggingEvent(loggingEvent));
        }

        protected override bool RequiresLayout
        {
            get
            { return true; }
        }

        public override string ToString()
        {
            return buffer.ToString();
        }
    }
}

Como pode ver, criar um Appender não é tarefa das mais difíceis. Abaixo, um appender que, simplesmente, conta a quantidade de vezes que é chamado.

using log4net.Appender;
using log4net.Core;

namespace Learning.Log4Net.Appenders
{
    public class CountingAppender : AppenderSkeleton
    {
        private int counter;

        public int Counter
        {
            get { return counter; }
        }

        protected override void Append(LoggingEvent loggingEvent)
        {
            counter++;
        }
    }
}

Getting Started

Para que você possa entender o funcionamento do log4net, considere os testes que seguem:

using Learning.Log4Net.Appenders;
using NUnit.Framework;
using SharpTestsEx;
using log4net;
using log4net.Config;
using log4net.Layout;

namespace Learning.Log4Net
{
    [TestFixture]
    public class GettingStarted
    {
        #region Setup/Teardown

        [SetUp]
        public void SetUp()
        {
            stringAppender = new StringAppender
            {
                Layout = new PatternLayout("%level - %message")
            };

            BasicConfigurator.Configure(stringAppender);
            log = LogManager.GetLogger(typeof (GettingStarted));

            log.Should().Not.Be.Null();
        }

        [TearDown]
        public void TearDown()
        {
            LogManager.GetRepository().ResetConfiguration();
            LogManager.GetRepository().Shutdown();
            ((log4net.Repository.Hierarchy.Hierarchy)LogManager.GetRepository()).Clear();
        }

        #endregion

        private ILog log;
        private StringAppender stringAppender;

        [Test]
        public void LogDebug()
        {
            const string msg = "Hello Log4Net, Debug";
            log.Debug(msg);
            stringAppender.ToString().Should()
                .Be("DEBUG - " + msg);
        }

        [Test]
        public void LogDebugFormat()
        {
            const string pattern = "Hello {0}, {1}";
            const string expected = "Hello Log4Net, Debug";
            log.DebugFormat(pattern, "Log4Net", "Debug");
            stringAppender.ToString().Should()
                .Be("DEBUG - " + expected);
        }

        [Test]
        public void LogError()
        {
            const string msg = "Hello Log4Net, Error";
            log.Error(msg);
            stringAppender.ToString().Should()
                .Be("ERROR - " + msg);
        }

        [Test]
        public void LogErrorFormat()
        {
            const string pattern = "Hello {0}, {1}";
            const string expected = "Hello Log4Net, Error";
            log.ErrorFormat(pattern, "Log4Net", "Error");
            stringAppender.ToString().Should()
                .Be("ERROR - " + expected);
        }

        [Test]
        public void LogFatal()
        {
            const string msg = "Hello Log4Net, Fatal";
            log.Fatal(msg);
            stringAppender.ToString().Should()
                .Be("FATAL - " + msg);
        }

        [Test]
        public void LogFatalFormat()
        {
            const string pattern = "Hello {0}, {1}";
            const string expected = "Hello Log4Net, Fatal";
            log.FatalFormat(pattern, "Log4Net", "Fatal");
            stringAppender.ToString().Should()
                .Be("FATAL - " + expected);
        }

        [Test]
        public void LogInfo()
        {
            const string msg = "Hello Log4Net, Info";
            log.Info(msg);
            stringAppender.ToString().Should()
                .Be("INFO - " + msg);
        }

        [Test]
        public void LogInfoFormat()
        {
            const string pattern = "Hello {0}, {1}";
            const string expected = "Hello Log4Net, Info";
            log.InfoFormat(pattern, "Log4Net", "Info");
            stringAppender.ToString().Should()
                .Be("INFO - " + expected);
        }

        [Test]
        public void LogWarn()
        {
            const string msg = "Hello Log4Net, Warn";
            log.Warn(msg);
            stringAppender.ToString().Should()
                .Be("WARN - " + msg);
        }

        [Test]
        public void LogWarnFormat()
        {
            const string pattern = "Hello {0}, {1}";
            const string expected = "Hello Log4Net, Warn";
            log.WarnFormat(pattern, "Log4Net", "Warn");
            stringAppender.ToString().Should()
                .Be("WARN - " + expected);
        }
    }
}

A rotina de TearDown é importante apenas para cenários de teste. Não é necessário que você conheça o processo no seu dia-a-dia.

Vamos ver a inicialização:

[SetUp]
public void SetUp()
{
    stringAppender = new StringAppender
    {
        Layout = new PatternLayout("%level - %message")
    };

    BasicConfigurator.Configure(stringAppender);
    log = LogManager.GetLogger(typeof (GettingStarted));

    log.Should().Not.Be.Null();
}

A configuração do appender a utilizar, bem como o Layout geralmente é feita no App.Config (veja o site oficial para ver exemplos efetivos). A linha importante aqui é a que carrega o logger (usando o objeto estático LogManager).

Como você pode ver, log4net ofecere cinco níveis diferentes de log: debug, info, warn, error, fatal.

Esses cinco níveis podem ser utilizados, entre outras coisas, como um primeiro filtro do que deve ser exibido. Além disso, podem receber formatação diferente.

Para ver um uso mais “prático” desses níveis, veja um exemplo fornecido pelo próprio log4net.

// Configure log4net using the .config file
[assembly: log4net.Config.XmlConfigurator(Watch=true)]
// This will cause log4net to look for a configuration file
// called ConsoleApp.exe.config in the application base
// directory (i.e. the directory containing ConsoleApp.exe)

namespace ConsoleApp
{
	using System;

	/// 
	/// Example of how to simply configure and use log4net
	/// 
	public class LoggingExample
	{
		// Create a logger for use in this class
		private static readonly log4net.ILog log = 
			log4net.LogManager.GetLogger(
				System.Reflection.MethodBase.GetCurrentMethod().DeclaringType
			);
		// NOTE that using System.Reflection.MethodBase.GetCurrentMethod().DeclaringType
		// is equivalent to typeof(LoggingExample) but is more portable
		// i.e. you can copy the code directly into another class without
		// needing to edit the code.

		/// 
		/// Application entry point
		/// 
		/// command line arguments
		public static void Main(string[] args)
		{
			// Log an info level message
			if (log.IsInfoEnabled) log.Info("Application [ConsoleApp] Start");

			// Log a debug message. Test if debug is enabled before
			// attempting to log the message. This is not required but
			// can make running without logging faster.
			if (log.IsDebugEnabled) log.Debug("This is a debug message");

			try
			{
				Bar();
			}
			catch(Exception ex)
			{
				// Log an error with an exception
				log.Error("Exception thrown from method Bar", ex);
			}

			log.Error("Hey this is an error!");

			// Push a message on to the Nested Diagnostic Context stack
			using(log4net.NDC.Push("NDC_Message"))
			{
				log.Warn("This should have an NDC message");

				// Set a Mapped Diagnostic Context value  
				log4net.MDC.Set("auth", "auth-none");
				log.Warn("This should have an MDC message for the key 'auth'");

			} // The NDC message is popped off the stack at the end of the using {} block

			log.Warn("See the NDC has been popped of! The MDC 'auth' key is still with us.");

			// Log an info level message
			if (log.IsInfoEnabled) log.Info("Application [ConsoleApp] End");

			Console.Write("Press Enter to exit...");
			Console.ReadLine();
		}

		// Helper methods to demonstrate location information and nested exceptions

		private static void Bar()
		{
			Goo();
		}

		private static void Foo()
		{
			throw new Exception("This is an Exception");
		}

		private static void Goo()
		{
			try
			{
				Foo();
			}
			catch(Exception ex)
			{
				throw new ArithmeticException("Failed in Goo. Calling Foo. Inner Exception provided", ex);
			}
		}
	}
}

Acho que você pegou a idéia.

Entendendo Levels

Os “levels” do log4net são extremamente importantes e servem como um primeiro filtro sobre o que deve, ou não, ser considerado pelo appender. Veja isso no seguinte bloco de testes:

using System;
using NUnit.Framework;
using SharpTestsEx;

using Learning.Log4Net.Appenders;
using log4net.Config;
using log4net;
using log4net.Core;
using log4net.Appender;

namespace Learning.Log4Net
{
    [TestFixture]
    public class Levels
    {
        [SetUp]
        public void SetUp()
        {
            appender = new CountingAppender();
            BasicConfigurator.Configure(appender);
            log = LogManager.GetLogger(typeof (GettingStarted));

            log.Should().Not.Be.Null();
        }

        [TearDown]
        public void TearDown()
        {
            LogManager.GetRepository().ResetConfiguration();
            LogManager.GetRepository().Shutdown();
            ((log4net.Repository.Hierarchy.Hierarchy)LogManager.GetRepository()).Clear();
        }

        private ILog log;
        private CountingAppender appender;
        [Test]
        [TestCase("All", 5)]
        [TestCase("Debug", 5)]
        [TestCase("Info", 4)]
        [TestCase("Warn", 3)]
        [TestCase("Error", 2)]
        [TestCase("Fatal", 1)]
        [TestCase("Off", 0)]
        public void TestLevel(string level, int expectedCount)
        {
            //(Level)Enum.Parse(typeof (Level), "All");
            var l = (Level) typeof (Level).GetField(level).GetValue(null);
            appender.Threshold = l;
            log.Debug("");
            log.Info("");
            log.Warn("");
            log.Error("");
            log.Fatal("");
            appender.Counter.Should().Be(expectedCount);
        }
    }
}

Pegou a ideia? Debug < Info < Warn < Error < Fatal.

Usando arquivos de configuração

log4net pode ser facilmente configurado através de arquivos xml. Veja um exemplo de arquivo de configuração:

Esse esquema é semelhante ao que seria utilizado no app.config. Abaixo, uma versão modificada do primeiro bloco de testes que carrega esse arquivo. Veja:

using System;
using System.Xml;
using NUnit.Framework;
using SharpTestsEx;
using log4net;
using log4net.Config;
using log4net.Layout;
using log4net.Repository;
using log4net.Appender;

namespace Learning.Log4Net
{
    [TestFixture]
    public class ConfigUsingXml
    {
        #region Setup/Teardown

        [SetUp]
        public void SetUp()
        {
            var log4NetConfig = new XmlDocument();
            
            log4NetConfig.Load(@"ConfigSamples\config-01.xml");
            
            ILoggerRepository rep = LogManager.CreateRepository(Guid.NewGuid().ToString());
            XmlConfigurator.Configure(rep, log4NetConfig["log4net"]);

            var appenders = LogManager.GetRepository(rep.Name).GetAppenders();
            appenders.Length.Should().Be(2);

            stringAppender = appenders[0];

            log = LogManager.GetLogger(rep.Name, typeof (ConfigUsingXml));
            log.Should().Not.Be.Null();
        }

        [TearDown]
        public void TearDown()
        {
            LogManager.GetRepository().ResetConfiguration();
            LogManager.GetRepository().Shutdown();
            ((log4net.Repository.Hierarchy.Hierarchy)LogManager.GetRepository()).Clear();
        }

        #endregion

        private ILog log;
        private IAppender stringAppender;

        [Test]
        public void LogDebug()
        {
            const string msg = "Hello Log4Net, Debug";
            log.Debug(msg);
            stringAppender.ToString().Should()
                .Be("DEBUG - " + msg);
        }

        [Test]
        public void LogDebugFormat()
        {
            const string pattern = "Hello {0}, {1}";
            const string expected = "Hello Log4Net, Debug";
            log.DebugFormat(pattern, "Log4Net", "Debug");
            stringAppender.ToString().Should()
                .Be("DEBUG - " + expected);
        }

        [Test]
        public void LogError()
        {
            const string msg = "Hello Log4Net, Error";
            log.Error(msg);
            stringAppender.ToString().Should()
                .Be("ERROR - " + msg);
        }

        [Test]
        public void LogErrorFormat()
        {
            const string pattern = "Hello {0}, {1}";
            const string expected = "Hello Log4Net, Error";
            log.ErrorFormat(pattern, "Log4Net", "Error");
            stringAppender.ToString().Should()
                .Be("ERROR - " + expected);
        }

        [Test]
        public void LogFatal()
        {
            const string msg = "Hello Log4Net, Fatal";
            log.Fatal(msg);
            stringAppender.ToString().Should()
                .Be("FATAL - " + msg);
        }

        [Test]
        public void LogFatalFormat()
        {
            const string pattern = "Hello {0}, {1}";
            const string expected = "Hello Log4Net, Fatal";
            log.FatalFormat(pattern, "Log4Net", "Fatal");
            stringAppender.ToString().Should()
                .Be("FATAL - " + expected);
        }

        [Test]
        public void LogInfo()
        {
            const string msg = "Hello Log4Net, Info";
            log.Info(msg);
            stringAppender.ToString().Should()
                .Be("INFO - " + msg);
        }

        [Test]
        public void LogInfoFormat()
        {
            const string pattern = "Hello {0}, {1}";
            const string expected = "Hello Log4Net, Info";
            log.InfoFormat(pattern, "Log4Net", "Info");
            stringAppender.ToString().Should()
                .Be("INFO - " + expected);
        }

        [Test]
        public void LogWarn()
        {
            const string msg = "Hello Log4Net, Warn";
            log.Warn(msg);
            stringAppender.ToString().Should()
                .Be("WARN - " + msg);
        }

        [Test]
        public void LogWarnFormat()
        {
            const string pattern = "Hello {0}, {1}";
            const string expected = "Hello Log4Net, Warn";
            log.WarnFormat(pattern, "Log4Net", "Warn");
            stringAppender.ToString().Should()
                .Be("WARN - " + expected);
        }
    }
}

Certo?!

Por agora, era isso. Em posts futuros, mostro mais detalhes sobre como escrever log de forma eficiente.

Tagged: Learning Tests, log4net

Qual é o seu estágio de desenvolvimento moral?

elemarjr — Sun, 13 May 2012 17:31:06 +0000

O Olá pessoal. Tudo certo?!

Nessa útltima semana, tive a oportunidade de conhecer, através dos meus amigos @renatolorandi e @jjrigotti, o excelente trabalho de Lawrence Kohlberg.

O centro do trabalho dele está no reconhecimento de que pessoas têm estágios de desenvolvimento moral diferentes. Logo, em função disso, reagem de forma diferente frente as questões do dia-a-dia.

Esse post fala desse trabalho.

A constatação de Lawrence Kohlberg

Lawrence Kohlberg constatou que há seis estágios de desenvolvimento moral, divididos em três grupos:

Pré-moral, ou pré-convencional
- Estágio 1 – Castigo e obediência
- Estágio 2 – Troca Instrumental
Convencional
- Estágio 3 – Conformidade interpessoal
- Estágio 4 – Lei e ordem
Pós-convencional, ou baseado em princípios
- Estágio 5 – Direitos básicos e contrato social
- Estágio 6 – Ética e princípos universais.

Ainda segundo o trabalho dele, todos passamos, naturalmente, por esses estágios. Ou seja, ninguém nasce no estágio 3, por exemplo. Todos nascemos com nosso desenvolvimento moral baseado em Castigo e Obediência.

Não há relação entre idade e desenvolvimento moral. Pessoas morrem sem chegar perto do Estágio 6.

Os estágios do desenvolvimento moral

Para entender melhor o que cada um desses estágios significa, vamos analisar cada um deles isoladamente.

Estágio 1 – Castigo e obediência

Quem está nesse estágio tem seu sistema de valores e auto-percepção onde as atittudes estão relacionados ao fato de haver, ou não, castigo.

Estando nesse estágio de desenvolvimento, não avançamos o sinal vervelho por termos medo de sermos flagrados por um policial. Entretanto, quando tivermos certeza de que não seremos punidos, avançamos.

Crianças costumam ter esse perfil. Por isso, inicialmente, precisam receber exatamente esse direcionamento.

Infelizmente, muitos adultos AINDA estão nesse estágio. Quantas pessoas conhecemos que, quando têm certeza da impunidade, agem de forma desonesta.

Pessoas nesse estágio de desenvolvimento moral precisam de comando e controle (provocando o @giovannibassi).

Esse estágio deveria ser superado ainda na infância, mas, quantos adultos conhecemos com padrões de comportamento que destacam essa linha de pensamento moral.

Estágio 2 – Troca Instrumental

Quem está nesse estágio persegue seus próprios objetivos e interesses deixando os outros fazerem o mesmo.

Nesse estágio, há “uma-mão-lava-a-outra”, o “jeitinho”, a lei de Jerson.

Infelizmente, esse estágio está associado diretamente a classe política, no Brasil. Percebendo que essa “classe” é apenas uma amostra da população, então, estatisticamente, podemos dizer que esse é o nível de desenvolvimento moral da sociedade brasileira.

O mais impressionante é que este estágio é “superior” ao anterior.

Repare, nesse estágio, toleramos as “infrações” dos outros por entender que eles também podem/devem tolerar as nossas.

Estágio 3 – Conformidade interpessoal

Nesse estágio, valorizamos, confiamos, cuidamos e somos leais a quem pertence ao nosso grupo. Este estágio de desenvolvimento moral implica na existência de um “nós” e “eles”. Onde, nós estamos certos, eles estão errados; Nós somos bons, eles são maus; Nós somos competentes …

O importante, aqui, é ser aceito. Quem está nesse estágio acata as opiniões do “partido”, da “panelinha”, do “grupo de discussão”, da “igreja” e condena qualquer coisa que venha de fora.

Estágio 4 – Lei e ordem

Nesse estágio, os julgamentos são baseados na ordem social, nas leis, na justiça e no dever. Quem está nesse estágio realmente acredita que a lei, a ordem social, a justiça e outros valores são reais, são partes do gênero humano.

Nesse estágio, na medida que evoluímos, entendemos que valores, direitos e princípios formam a base das leis e as transcendem. Entendemos que há algo maior que o grupo.

Estágio 5 – Direitos básicos e contrato social

Nesse estágio, entendemos qu valores são universais, que os conceitos de certo e errado não foram definidos para controlar a sociedade. Mas, são inatos.

Nesse estágio, procuramos o bem do todo e, por isso, questionamos as leis que não estão de acordo com esses direitos. São os loucos que “questionam o sistema”, pelo aperfeiçoamento do sistema em favor do bem comum.

Estágio 6 – Ética e princípios universais

Nesse estágio, indivíduo age movido por princípios universais baseados na igualdade e no valor da vida humana.

Pessoas nesse estágio buscam o bem comum. Ou seja, o melhor para todos.

Princípios do desenvolvimento moral

Ainda de acordo com Lawrence Kohlberg, o desenvolvimento moral obedece a determinados princípios. Veja:

O desenvolvimento por estágios é invariável. Ou seja, não se pode “pular” estágios. Não podemos sair do “Castigo e Obidiência” para “Lei e Ordem” diretamente.
Não podemos compreender o raciocínio moral que ocorre além do próximo estágio daquele em que estamos. Pessoas em estágios diferentes, ao discutir ética, tem interpretações muito diferentes.
Os indivíduos são cognitivamente atraídos por raciocínios um estágio acima do nível em que se encontram.
A evolução de um estágio para outro se verifica quando é criado um desequilíbrio cognitivo ou emocional. Isso ocorre quando nossa interpretação da vida já não é adequada para a solução de um determinado dilema moral.

O politicamente correto

Estamos em tempos do “politicamente correto”. Para mim, trata-se de uma encenação de “Ética e princípios universais” por parte de indivíduos que, na maioria dos casos, ainda vive “Troca Instrumental”. Consequência: estamos condenando o “falar errado”, mas estamos fazendo pouco a respeito do “fazer errado”.

O estágio de desenvolvimento moral e a ética

Ética é um conjunto de valores. Quando dizemos que uma pessoa, ou empresa, é ética, nos referimos a seus valores.

Se meus valores E MINHAS ATITUDES estão de acordo com determinado estágio de desenvolvimento moral, então, isso é ética.

Valores são observados a partir do estágio 4. Logo, antes disso, não podemos identificar como ética qualquer pessoa (ou empresa formada por pessoas) que estejam em estágios mais baixos.

Para pensar …

Identificar o estágio em que nos encontramos é uma excelente oportunidade para que possamos observar as características que norteiam o próximo estágio. É uma oportunidade de promover o tal “desequilíbrio cognitivo”.

Reconhecer o estágio de desenvolvimento moral nos outros é uma excelente oportunidade de encontrarmos referências para o nosso desenvolvimento. Ou ainda, perceber como “falar a língua” do outro – promovendo, no outro, o “desequilíbrio cognitivo” que ele precisa para evoluir.

O desequilíbrio cognitivo se dá pelo “questionamento moral”.

Afinal, qual é o seu estágio de amadurecimento moral?!

Era isso.

Tagged: carreira, filosofando