DLinq só funciona com SQL Server?

Tenho visto em alguns fóruns muitas pessoas afirmarem que o DLinq será utilizado especificamente para SQL Server. Embora essa afirmação seja verdadeira hoje, o DLinq dará suporte sim a outros bancos de dados.

Segundo um post de Dinesh Kulkarni, Program Manager do Linq, a dificuldade de dar suporte ao Oracle e a outros bancos de dados é que não há nenhum DB realmente SQL-ANSI e mesmo que houvesse, vários bancos tem recursos específicos que devem ser tratados pelo próprio fabricante. Com isso, eles estão trabalhando em um provider model que permitirá ISVs e a própria comunidade escrever implementações para um banco de dados específico.

Meu sentimento é que mesmo a Microsoft disponibilizando apenas um provider model, deveremos ter, junto com o lançamento do Linq, providers para os principais bancos de dados do mercado, como já ocorreu com outras versões do Visual Studio e o ADO.NET.

[]s
André Dias

Um pouco mais sobre ADO Entity Framewrok

Como eu escrevi no post anterior, essa semana eu baixei o CTP de junho do Orcas para dar uma olhada no produto, na verdade, o meu real interesse é ver como está a evolução do LINQ e e em particular do ADO Entity Framework (EF).

Pra quem não conhece, o EF será o novo framework de mapeamento ORM da Microsoft, uma espécie de concorrente do NHibernate.

Bom, após analisar os exemplos do EF, confesso que fiquei muito confuso. Não entendi muito bem porque eu tinha que fazer o mapeamento tanto em arquivos XML e também decorar as minhas entidades (DTO, Model, etc) com vários atributos com as mesmas informações que já estavam no XML.

Postei essa dúvida no fórum do MSDN (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1824146&SiteID=1 ) e algumas pessoas do time me responderam que é isso mesmo. A arquitetura do produto até agora te obriga a fazer uma herança na sua entidade, decorar suas propriedades com atributos e ainda por cima fazer o mapeamento com XML.

Ok, ok.. O visual studio faz boa parte do trabalho pra você, mas e o tal dos conceitos de persistence ignorance, POCO? Poxa, eu não quero que o meu model fique fortemente acoplado com um framework. Alguns podem falar que é purismo, que é frescura, mas não é. Eu simplesmente quero deixar meu model, minhas entidades de negócio desacopladas pra poder usar um outro framework sem muitos problemas se eu quiser.

No entanto, o pessoal do time de dev do produto disseram que a cada release eles estão trabalhando para chegar mais próximo do POCO (Plain Old CLR Objects), ou seja, uma classe .net que não herde de ninguém, não tenha nenhum atributo, umas classe pura e sem metadados. Isso é ótimo, mas me disseram também que isso não estará nem na primeira release que deve sair no meio de 2008.

Legal, então vou ter que esperar até 2009 pra ter um framework da Microsoft pra ORM que aplique conceitos básicos de orientação a objetos e que faça o que muitos frameworks (como o NHibernate, por exemplo) já fazem há algum tempo?? É isso aí !!

Estranho né?? Nem tanto, achei talvez uma explicação para isso. Parece que um dos Devs do produto não acha (ou pelo menos achava) isso importante e só começou a estudar isso agora, pois a comunidade está pedindo muuuito e ele achou que deveria ter uma razão pra isso :-)

Vamos ao comentário dele: "I have devoted real time to studying agile design principles and domain driven design........ Initially I thought that some of the requests for *complete* persistence ignorance were the products just of dogma rather than fully informed and reasoned arguments, but when so many people give such passionate feedback it was clear that I needed to investigate more before I could claim to have any sort of an informed opinion. The product of my research is that I am now truly convinced of the importance of complete persistence ignorance for some scenarios. As a result, the team is now working on a series of product changes aimed at ensuring that a later move to complete persistence ignorance will not be a fundamental breaking change."

O post completo pode ser lido em: Persistence Ignorance: OK, I think I get it now.

Bom, pelo menos fico feliz que o time da Microsoft começou a olhar outras alternativas de arquitetura e estudar um pouco de Design Patterns. (Que coisa não??)

Vou ficando por aqui esperando ansiosamente o próximo CTP pra ver o que teremos de melhoria no Entity Framework, mas enquanto não me convencerem que o EF é melhor, vou continuar com o bom e velho NHibernate, feito pela comunidade e com código aberto :-)


André Dias

Entity Framework só depois do Orcas

Essa notícia é meio velhinha, mas acho que ainda é atual.

Essa semana a MS liberou o CTP de Junho do Orcas e junto com ele novidades sobre o Entity Framework. Até aí legal, deu um trabalhinho pra instalar no Vista, mas depois de montar uma máquina virtual e instalar pela segunda vez, funcionou.

Baixei os Samples do Entity Framework comecei a rodar e parece ser bem interessante. Fiquei com algumas dúvidas e numa das pesquisas nos fórums do MSDN descubro que o negócio só será lançado após o Orcas como um update lá pro meio de 2008.

Será que é tão difícil assim construir um framework ORM? Se não estou enganado a MS começou a falar disso em 2001 num PDC onde o framework era chamado de "Orca", depois disso anunciaram o ObjectSpaces que viria no Visual Studio 2005. Chegaram até a adicionar no beta 1, mas removeram no Beta 2 e falaram que seria lançado com o WinFS.

Aí mataram o projeto do ObjectSpaces, anunciaram que ele seria descontinuado e tempos depois anunciaram o LINQ e o tal do Entity Framework. Pensei eu: "Finalmente agora vou ter um framework da MS pra trabalhar com ORM".

E não é que adiaram de novo... Olha a notícia aí:
http://blogs.msdn.com/adonet/archive/2007/04/28/ado-net-entity-framework-update.aspx

Tô vendo que vou continuar com o bom e velho Hibernate :-p

Abraços
André Dias

Teste Unitário e Code Coverage com Visual Studio

Ultimamente tenho visto muita gente falar sobre testes unitários, metodologias ágeis, garantia de qualidade, mas implementar o tal do teste unitário que é bom mesmo, são poucas empresas que conheço que fazem isso de verdade.

Quando digo que são poucas, não estou me refirindo a você abrir o Visual Studio, criar um projetinho de teste e criar um método simples para testar apenas o "caminho feliz" do seu método, estou falando de você planejar os seus testes unitários antes e criar vários métodos de testes para cobrir todas, ou pelo menos a maioria, das situações que o seu método possa executar.

Isso engloba em testar range de valores, parametros opcionais, se as exceções são levantadas corretamente e por aí vai. Se for preciso utlizar Mock Objects, ótimo, vamos fazer isso também, mas é extremamente importante que você faça métodos de testes que sejam eficientes e não apenas para dizer que está utilizando testes unitários na sua aplicação.

Um recurso muito útil presente no Visual Studio (edições pra Developer e Tester) é o Code Coverage. Esse recurso ligado junto com os testes unitários permite ao usuário acompanhar visualmente quais trechos do código foram testados ou não.

Vamos ver um exemplo de como ele funciona:

1. Vamos criar um projeto do tipo Class Library e adicionar uma classe Calculadora como o exemplo abaixo:

public class Calculadora
{
    public static float Dividir(float d1, float d2)
    {
        if (d2 == 0)
        {
            throw new DivideByZeroException();
        }
        else
        {
            return d1 / d2;
        }
    }

    public static int Soma(int a, int b)
    {
        return a + b;
    }
}

2. Em seguida , vamos adicionar um projeto do tipo Test Project e adicionar uma classe chamada CalculadoraTest com o seguinte código:

[TestClass]
public class CalculadoraTest
{
    [TestMethod]
    public void DivisaoComumTeste()
    {
        float resultado = Calculadora.Dividir(6, 3);
        float esperado = 2;

        Assert.AreEqual(esperado, resultado);
    }
}

Veja que a classe de teste possui apenas um método e não está cobrindo a situação de divisão por zero, e nem o método Soma. Isso não quer dizer que o método não funcione, mas ele não foi testado.

Se rodarmos esse teste, teremos o seguinte resultado:

Até aí nada de muito interessante, a janela mostra apenas que o teste foi executado com sucesso. O grande barato é quando ligamos o Code Coverage o colamos os testes unitários para rodar junto.

Para habilitar o Code Coverage, vá no arquivo localtestrun.testrunconfig da sua solução e você verá a seguinte tela:

Marque o Assembly CodeCoverageSample.dll e mande rodar os testes novamente. Quando terminar os testes, acesse o menu Test/Windows/Code Coverage Results e veja que coisa linda :-)

O Visual Studio te dá a porcentagem de código testado agrupados por métodos, classes, namespaces e assemblies e além disso marca no código por quais trechos ele passou ou não.

Dessa forma fica muito fácil visualizar que temos que escrever mais métodos de testes para testar a situação da divisão por zero e para garantir que o método de soma está funcionando corretamente.

Agora que já conhecemos o Code Coverage, é só definirmos uma meta para o nosso projeto (80, 90, 100% de cobertura) e brigar com o seu gerente pra ele alocar tempo para você criar métodos de testes que cubram todo o seu código :-)

Um grande abraço

André Dias