Programaticamente falando

Templates T4 são largamente usados para acessar o banco de dados e gerar código de acordo com os objetos(tabelas e etc). Vamos ver como podemos acessar o SQLServer usando templates tt.Antes de ver o código precisamos baixar ums dlls

1-Importar os assemblies

   1: <#@ assembly name="Microsoft.SqlServer.ConnectionInfo" #>

   2: <#@ assembly name="Microsoft.SqlServer.Smo" #>

   3: <#@ assembly name="Microsoft.SqlServer.Management.Sdk.Sfc" #>

   4: <#@ assembly name="Microsoft.SqlServer.SqlEnum" #>

   5: <#@ import namespace="System.IO" #>

   6: <#@ import namespace="Microsoft.SqlServer.Management.Smo" #>

2-Estabelecer a conexão

   1: <#

   2:     Server server = new Server("NomeDaMaquina\\NomeDaInstancia");

   3:     Database database = new Database(server, "NomeDoDatabase");

   4:     database.Refresh();

   5: #>

3- Gerando uma classe para cada tabela do banco

   1: <#

   2:     foreach (Microsoft.SqlServer.Management.Smo.Table item in database.Tables)

   3:     {

   4: #>

   5:     public class <#=item.Name#>{}

   6:     <# SaveOutput(item.Name+".cs");

   7:     }

   8: #>

4- Usamos um método SaveOutput que está em outro tt que foi incluido no início do arquivo

   1: <#@ include file="SaveOutput.tt" #>

5- Código do SaveOutput.tt

   1: <#@ template language="C#" hostspecific="true" #>

   2: <#@ import namespace="System.IO" #>

   3: <#+

   4:   void SaveOutput(string outputFileName)

   5:   {

   6:       string templateDirectory = Path.GetDirectoryName(Host.TemplateFile);

   7:       string outputFilePath = Path.Combine(templateDirectory, outputFileName);

   8:       File.WriteAllText(outputFilePath, this.GenerationEnvironment.ToString());

   9:

  10:       this.GenerationEnvironment.Remove(0, this.GenerationEnvironment.Length);

  11:   }

  12: #>

Download do código fonte

Hoje muito se ouve na comunidade .NET sobre templates T4.Não vou entrar no mérito de falar o que é pois vários blogs já o fizeram, você pode obter referências aqui, aqui e aqui. Eu mostrar um exemplo de como podemos gerar código sem conhecer muito do T4.

A ferramenta que vou usar é o VS2010 beta 2 com o add-on tangible t4 editor que pode ser baixado diretamente do visual studio.Para iniciar vamos criar uma solução clas library e adicionar um arquivo chamado

No exemplo abaixo vamos criar uma classe com o crud de uma entidade chamada pessoa. vamos usar LINQTOSQL para facilitar o exemplo.

Após criar o banco com a tabela pessoa vamos adicionar um arquivo t4 chamado crud.tt .

vs2010:Selecionar  a opção general nos tipos de arquivos e selecionar o arquivo text template.

vs2008:Adicionar um arquivo com extensão .tt.

1-Vamos começar alterando a opção extension na tag  output, vamos colocar .cs.

2- declarar variáveis para armazenar os dados que serão utilizados várias vezes pelo template

3- Adicionar os namespaces que serão utilizados pelo nosso CRUD

4- Declarar a classe responsável pelo CRUD

Galera, já temos nosso código CRUD básico, para gerar o mesmo código para outra classe basta mudar a variável NomeDaClasse e pronto!

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4:

   5: namespace BlogT4

   6: {

   7:     public class PessoaCRUD

   8:     {

   9:

  10:         BlogT4DataDataContext db;

  11:

  12:         public PessoaCRUD()

  13:         {

  14:             db = new BlogT4DataDataContext();

  15:         }

  16:

  17:         public void Inserir(Pessoa entidade)

  18:         {

  19:             db.Pessoas.InsertOnSubmit(entidade);

  20:             db.SubmitChanges();

  21:         }

  22:

  23:         public IQueryable<Pessoa> RecuperaTodasAsPessoas()

  24:         {

  25:             return db.Pessoas;

  26:         }

  27:

  28:     }

  29: }

no proximo post sobre T4 vamos melhorar as coisas e gerar código de maneira mais elegante! Até o próximo..

ps: o wordpres+ live writer estão sacaneando minha formatação..

Fala galera, desta vez  vamos falar sobre a responsabilidade de validação dos dados. Quem deve validar, a função que está sendo chamada ou a função que chama?Acho que este é um assunto defendido de diversas maneiras por nós, programadores. Eu não fazia a mínima idéia antes de conhecer o design por contrato(DBC). No DBC contratos são realizados e todas as partes  envolvidas devem respeitar o contrato. Se você ainda não conhece o DBC pode olhar um pouco aqui e aqui. Basicamente o contrato é estabelecido indicando o que a função precisa receber(validade dos parâmetros) e o que ela vai retornar quando recebe os parâmetros necessários. Os contratos podem ser feitos com ferramentas como o CodeContracts ou até com comentários,Vamos olhar um exemplo usando comentários

   1: public class Calculadora

   2:     {

   3:

   4:         /// <summary>

   5:         /// Realiza a divisão entre dois numeros

   6:         /// </summary>

   7:         /// <param name="dividendo">Pode ser qualquer valor</param>

   8:         /// <param name="divisor">Pode ser qualquer valor exceto 0</param>

   9:         /// <returns></returns>

  10:         public static Decimal Dividir(Decimal dividendo, Decimal divisor)

  11:         {

  12:             return dividendo / divisor;

  13:         }

  14:     }

Bem, na pior das hipóteses o desenvolvedor sabe  que a validação deve ser feita antes de chamar a função apresentada, além disso sabe que se passar os parâmetros corretos vai obter uma resposta valida. As coisas ficam mais legais quando você está usando ferramentas como o CodeContracts.

Além da notificação ao usuário da função fica relativamente mais fácil de escrever testes para validar o contrato da função,  temos em mente quais contratos devem ser respeitados e quais não devem. Uns exemplos de testes contra o contrato.

   1: [TestClass]

   2:     public class CalculadoraTeste

   3:     {

   4:

   5:         [ExpectedException(typeof(DivideByZeroException))]

   6:         [TestMethod]

   7:         public void TesteDividir_DividindoPorZero()

   8:         {

   9:             Calculadora.Dividir(10, 0);

  10:         }

  11:

  12:         [TestMethod]

  13:         public void TesteDividir_ValorMaximo()

  14:         {

  15:             Assert.AreEqual(1, Calculadora.Dividir(Decimal.MaxValue, Decimal.MaxValue));

  16:         }

  17:         public  void  TesteDividir_parametrosSimples()

  18:         {

  19:             Assert.AreEqual(10, Calculadora.Dividir(100, 10));

  20:

  21:         }

  22:

  23:     }

Bem, com o DBC aprendi este modelo de desenvolvimento onde na maioria das vezes o cliente deve fazer a validação antes da chamada do método. Os principais benefícios desta abordagem são relacionados à separação de responsabilidades. Quando o cliente valida os dados é possível criar por exemplo uma camada Fachada responsável pelas validações e isolar o Núcleo do sistema que agora não se preocupa mais com códigos de validação. O legal do facade é quando você ainda consegue aproveitar ele em diversos ambientes diferentes, por exemplo trabalho em um projeto onde o Facade é utilizado via Ajax, assim a validação cliente e servidor não fica duplicada.

Outro beneficio legal é a maior facilidade de propagar erro e invalidade dos dados, afinal de contas você vai estar uma camada mais próxima do cliente, não precisa ficar propagando erros por N camadas.

Concluindo, O DBC me ensinou uma maneira legal de validar os dados. Nos projetos em que trabalho gosto da idéia do projeto fachada apesar de ter que escrever mais código ficou feliz em eliminar a duplicidade de validações.

Adicional: você ainda pode gerar testes beaseados em contratos, olhe esta ferramenta.

Fala Galera, Como todos já escutaram falar muitas das metodologias ágeis como XP são baseadas na idéia de design incremental. Utilizando o design incremental podemos fornecer software em curtos espaços de tempo (release) e receber a opinião do cliente rapidamente. A grande parte dos livros de metodologias ágeis retrata mais ou menos o que eu disse acima, sendo assim a maioria dos desenvolvedores tem uma visão distorcida do design incremental. Vou mostrar um caso abaixo e duas abordagens diferentes de design incremental.

Caso:

Você está trabalhando em um sistema de cadastro de aplicações de T.I em educação, sendo assim o cliente informa que o mais importante é o cadastro de aplicação. Nós desenvolvedores sabemos que também é necessário trabalhar no controle de acesso. Logo antes do projeto iniciar o cliente informa que na verdade muitos outros cadastros serão desenvolvidos, o sistema vai trabalhar com todo e qualquer tipo de contribuição acadêmica, mas o mais importante continua sendo o cadastro de aplicação de T.I em educação.

Solução1 :

O desenvolvimento começa pelo cadastro de contribuição de T.I em educação, após 1 mês os desenvolvedores possuem este módulo funcionando perfeitamente utilizando técnicas AJAX, validação client-side e controle de modificações de registros. Após isso a equipe trabalha no controle de acesso e fornece apenas o cadastro de usuário com todas as validações necessárias para este tipo de cadastrado e sendo assim o release está terminado e o cliente pode testar a aplicação.

Solução 2 :

A equipe sabe que deve trabalhar no cadastro de aplicação de T.I em educação, para isso desenvolve o cadastro da maneira mais simples possível, o cadastro não possui nenhuma validação e nenhum código Ajax. Simplesmente client-side e Server-side. Após isso um controle de acesso básico é criado apenas como login e senha para que a validação de usuário possa ser habilitada. Nesta versão liberada pela equipe o usuário não tem mensagens legais e nenhum tipo de validação, ele simplesmente pode observar o comportamento seco da aplicação.A solução 2 é duas semanas mais rápida que a solução 1, sendo assim o usuário testa a aplicação e libera seu feedback. O usuário escolhe se é mais importante continuar com a construção simples(esqueleto) ou é o momento certo de aplicar css, realizar validações e habilitar mensagens de erro.

Conclusão:

O ponto comum entre as duas soluções é a vontade de ser ágil, no entanto a solução 2 oferece ainda mais poder de escolha para o cliente, ele que deve determinar se um css é mais importante que mais funcionalidades.Não considero a primeira solução errada, mas acho que a segunda solução tem uma “cara” mais XP. Espero que tenham entendido o ponto deste post, até mais..

Fala galera,

Desculpe pela ausência nas ultimas duas semanas, eu gastei grande parte do tempo configurando meu novo PC com o Windows 7 além de estudar para as provas da faculdade.Hoje vamos falar de um assunto que deveria ser debatido mais vezes nos blogs e grupos de discussão, estou falando dos testes unitários.Estou trabalhando num projeto com ASP.NET MVC, como você pode imaginar estou utilizando testes unitários(MVC+Testes unitários = agilidade). Eu estou usando um FakeController que pode ser obtido no blog do Stephen Walther. O código fornecido trabalha com um método SetUp  que inicializa o FakeControllerContext no controller que está sendo testado. O método SetUp no NUnit é disparado antes da execução de cada teste, então a cada novo teste um novo FakeControllerContext é criado.Até ai não existe problema, A situação fica complicada quando é necessário compartilhar dados entre testes distintos usando como exemplo o objeto applicationContext.Para resolver este problema  você precisa realizar apenas uma pequena alteração no método setUp, as mesmas mudanças explicadas para o SetUp são validas. Vamos olhar um exemplo que deixa a ordem de execução mais clara.

   1: [TestFixtureSetUp]

   2:     public void ClassSetUp()

   3:     {

   4:         //A lista de produtos e o gerente de produtos podem ser utilizados para todos os métodos

   5:         // sendo assim, não é necessário inicializar os membros antes de cada método

   6:         gerenteProduto = new GerenteProdutos();

   7:         produtos = new List<Produto>();

   8:         produtos.Add(new Produto() { Nome = "Iphone", Preco = 300 });

   9:         produtos.Add(new Produto() { Nome = "PSP", Preco = 180 });

  10:         produtos.Add(new Produto() { Nome = "VSTS", Preco = 500 });

  11:

  12:

  13:

  14:     }

  15:     [SetUp]

  16:     public void SetUp()

  17:     {

  18:         // esta variável deve ser inicializada antes de cada execução - exemplo simples para explicação

  19:         ssomatorio = 0;

  20:     }

  21:

  22:     [Test]

  23:     public void TestSomaValorDosProdutos()

  24:     {

  25:         ssomatorio = gerenteProduto.SomaValorDosProdutos(produtos);

  26:         Assert.AreEqual(980, ssomatorio);

  27:     }

  28:

  29:     [Test]

  30:     public void TestSomatorioDosProdutosComTaxas()

  31:     {

  32:         ssomatorio = gerenteProduto.SomatorioDosProdutosComTaxas(produtos);

  33:         Assert.AreEqual(1078, ssomatorio);

  34:     }

Como você pode ver no exemplo o atributo [TestFixtureSetUp] indica que um método será executado apenas uma vez, durante a inicialização da classe. O atributo [SetUp] indica que um método será executa antes de cada teste.

Espero que você escreva muitos testes e que os atributos SetUp e TearDown sejam úteis.

código fonte completo

Fala galera,

Como eu já havia contado a vocês, no início da semana ocorreu o Dev In Rio. O Dev In Rio foi um evento  com foco em desenvolvimento de software e metodologias.Foi legal participar, uma penca de coisas foram discutidas.Os principais assuntos foram: Java,RoR e agile. Você pode estar se perguntando o que é um desenvolvedor .NET está fazendo neste tipo de evento, a resposta é facil quando você pensa em comunidade e esquece um pouco de linguagens e frameworks. Eu acho que é muito interessante para um desenvolvedor ser parte ativa da comunidade de software. Este tipo de evento(não .NET) é ainda melhor pois é possível ver o que está sendo debatido e realizado pelo pessoal que utiliza outras tecnologias.O evento ainda trouxe palestras sobre OpenSource e métodologias ágeis. Assim que sobrar um tempo vou postar sobre as coisas legais que aprendi.

Tudo que posso dizer é que certamente participarei no proximo ano abraços!

Hi folks,

Last week I made a post about good practices X "difficulties to develop". In this last post I inquire about documentation in software development. I read one interesting phrase in a software book, this phrase means “Only code reflects code”. Calm down I’m not saying that you can’t write documentation, I’m saying that almost ever documentation I see don’t reflect code.

How I said in my last post I’m thinking in use other ways for make people understand my code. If you read my blog you now I like Extreme programming, and this approach suggests using automated tests. I come up with to use just tests to help people to understand my code.So, and you what do you think? Do you agree?

Boas Práticas e o peso no código

Olá todo mundo. Desta vez vamos falar sobre um assunto que esta me gerando certa duvida no planejamento do novo projeto que participarei. Pelo titulo do post pode-se imaginar que eu vou questionar as boas práticas de desenvolvimento de software porém não sou louco de fazer isso! A prática em questão é o /** Comentário no código **/ bem, eu já li muita coisa diferente sobre esta pratica durante o desenvolvimento de software, vou colocar algumas abaixo.

1º Remover comentário e criar método auto-explicativo

Não lembro se é realmente este o nome que o Martin Fowler atribuiu a refatoração de remover comentário e criar um método auto-explicativo. M.Fowler diz que quando não é possível entender claramente o objetivo do código o mesmo deve ser refatorado, Sendo assim se você está executando uma operação e necessitou de um comentário é porque o código não esta bom!

2º Somente o código reflete o código

Bem, esse pensamento é do Kent Beck em seu livro: Programação extrema acolha as mudanças.Ele diz que é complicado ter muita coisa que reflete o código pois a alteração do mesmo acaba sendo uma atividade chata e demorada. Ele usa o principio de “Só carregue consigo o que for extremamente necessário” com esse principio você deixa de lado tudo que se torna pesado e acaba prejudicando o desenvolvimento

3ºCoding Standards

Esses são aqueles padrões para escrever código inteligível por outros programadores. Bem eu não li muita coisa sobre o assunto mas o pouco que lí(1 livro e 1 tutorial, sendo ambos da MS)falam que os comentários são realmente necessários para o código. Um bom exemplo de uso de comentários no .NET e informar que um método pode gerar uma exceção, infelizmente não temos os mesmos recursos do Java e declarar um método e definir as exceções geradas pelo mesmo.

4º Insert Duplication

Este é o termo usado no livro Programador Pragmatico

para falar sobre o Mal da duplicação. Neste caso o autor utiliza o principio DRY para falar sobre um comentário que fala a mesma coisa que o código. O autor ainda fala que os programadores são instruídos a documentar, mas ninguém os conta sobre o porque documentar, no casso a documentação serve para explicar um código ruim.

5º Gerar documentação de maneira ágil

Aqui eu levo em consideração a possibilidade de gerar um manual de navegação pelo sistema usando os comentários embutidos no código. Este caso é útil em uma abordagem ágil como o XP pois podemos gerar documentação com alguns cliques em uma ferramenta.

Bem eu sei que existem muuitos outros pontos de vista sobre a documentação no sofware, entretanto relato os mais comuns. Minhas duvidas abordam as teorias acima, pois desde pequeno fui instruído a comentar código e acho isso uma coisa legal, mas também acho que a documentação pode se tornar algo pesado para a equipe. Alem disso temos os testes, Será que os testes não substituem esta documentação no código? Ou será que o ideal é utilizar as duas maneiras? Confesso que estou tentado a deixar a documentação de lado e basear-me apenas nos testes.

• Aplicar padrões complexos cedo demais:Padrões de projeto são excelentes soluções para os problemas encontrados no desenvolvimento,mas será que o padrão é realmente necessário? pode ser que o problema possa ser resolvido de maneira mais simples então porque usar um padrão?
• Criar Arquiteturas em excesso para suportar requisitos futuros.O ego dos desenvolvedores pode falar mais alto que sua razão,Se isso acontecer eles irão construir o “Sistema final”.Ou então criar uma arquitetura paralela visando um possível requisito.Todas essas praticas podem deixar o código complexo visando algo que pode nunca ser usado.M.Fowler criou o principio YAGNI(you ain’t gonna need it – você não vai precisar disso).Fowler diz que a probabilidade de errar é a mesma de acertar,portanto não vale a pena apostar e sacrificar o simplicidade do código.
• Desenvolver uma infra-estrutura complexa: É um erro comum entre as equipes de desenvolvimento utilizarem os recursos iniciais para desenvolver uma infra-estrutura como bibliotecas, frameworks ou um sistema de tratamento de erros. Ao invés disso é mais interessante que as equipes invistam em funcionalidades para o usuário.Neste problema podemos aplicar o YAGNI, dessa maneira vamos criar infra-estrutura quando for realmente necessário