Continuando a série RIA – Silverlight, esse artigo visa demonstrar os procedimentos necessários para instalação e configuração adequada das ferramentas para se trabalhar com o Microsoft Silverlight.

Quais as ferramentas necessárias?

As duas principais ferramentas utilizadas no desenvolvimento de RIA com Silverlight 3 são o Expression Blend 3 e o Microsoft Visual Studio 2008. Existem algumas outras ferramentas complementares que auxiliam no trabalho como o Deep Zoom Composer e o Sketchflow.

Cada uma das ferramentas citadas tem suas importâncias e objetivos. O Expression Blend é a ferramenta apropriada para o desenho das interfaces e animações. Com uma interface muito prática e amigável pode-se criar interfaces bem elaboradas com pouca mão de obra, o que permite grande produtividade ao se trabalhar com Silverlight.

O Visual Studio 2008 não oferece toda essa facilidade ao trabalhar com o desenvolvimento de interface e animações, porém é a melhor ferramenta para a implementação e codificação dos eventos e processos da aplicação. Dessa forma as duas ferramentas são complementares.

O Deep Zoom Composer é utilizado para preparação de imagens de alta resolução para serem utilizadas pelo recurso Deep Zoom do Silverlight. O Deep Zoom permite a utilização de zoom em animações Silverlight com baixo peso e sem afetar a performance da aplicação.

Por último o Sketchflow que é uma ferramenta utilizada para criação de protótipos de interfaces. Através dessa ferramenta pode-se desenhar rapidamente o fluxo de telas de uma aplicação. Após o planejamento de todo o fluxo de telas no Sketchflow pode-se importar o trabalho para o Expression Blend e grande parte do trabalho de criação efetiva das telas do sistema já estará adiantado.

Em que site posso fazer os downloads?

Cada uma das ferramentas está disponível para download em uma área diferente do site da Microsoft. Para auxliá-lo a encontrá-las organizei os links para download de cada uma delas:

Microsoft Visual Studio 2008 (Trial 90 dias)
http://msdn.microsoft.com/en-us/vstudio/aa700831.aspx

Microsoft Expression Blend  + SketchFlow (Trial 60 dias)
http://www.microsoft.com/downloads/details.aspx?FamilyID=e82db5e2-7106-419e-80b0-65cce89f06bb&displaylang=en

Deep Zoom Composer
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=457b17b7-52bf-4bda-87a3-fa8a4673f8bf

Qual a melhor ordem de instalação?

Recomendo que siga a ordem abaixo:

1. Microsoft Visual Studio 2008
2. Microsoft Visual Studio Service Pack 1 (Recomendado)
3. Microsoft Expression Blend / Sketchflow
4. Deep Zoom Composer

Silverlight Toolkit

Agora que todo o ambiente para desenvolvimento já está instalado adequadamente você estará pronto para iniciar o desenvolvimento de aplicativos Silverlight. Mas eu gostaria de aproveitar esse post para sugerir alguns pacotes extras que podem ser interessantes e inclusive serão utilizados nos posts de sequência dessa série.

Assim como existe o Ajax Control Toolkit para utilização no ASP.NET, foi desenvolvido o Silverlight Toolkit, uma biblioteca de componentes para ser utilizada no Silverlight. Essa biblioteca contém controles e componentes que não fazem parte do pacote inicial do Silverlight mas que normalmente são bastante úteis nas mais variadas aplicações. Dessa forma é um recurso bastante útil e que vale a pena ser estudado.

Para baixar o toolkit utilize o link abaixo:
http://silverlight.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=36060

RIA Services

Outro assunto muito comentado quando se fala de RIA com Silverlight é o RIA Services. A principal idéia dessa tecnologia é simplificar a criação de aplicações N-Camadas em plataforma web. Esse tema será abordado mais adiante em nosso blog. Para utilizar esse recurso necessita-se instalar esse framework que está disponível para download no link abaixo:
http://www.microsoft.com/downloads/details.aspx?FamilyID=76bb3a07-3846-4564-b0c3-27972bcaabce&displaylang=en

Prontos para o trabalho

Essas são as principais ferramentas e recursos utilizados para desenvolvimento de RIA com Silverlight.

Caso encontre algum problema na instalação ou configuração sinta-se a vontade para comentar no post e farei o possível para ajudá-lo.

Dentro de alguns dias escreverei mais um artigo, dessa vez levando-o a sua primeira experiência prática com Silverlight.

Um grande abraço a todos.

Aubry Maciel
Siga-me no twitter: @aubrymaciel

O Patrick LeBlanc postou uma ótima e simples explicação sobre TVPs no SQL Server 2008. Clique aqui para ver o artigo orignal no blog original dele.

Este recurso é novo na versão 2008 do banco de dados. Antigamente as pessoas passavam para a procedure uma lista de valores separados por vírgula para depois, fazer um processo de extração dos dados da string e enfim, começar a lógica de negócios. Ou seja, nada produtivo! Outro exemplo clássico é a necessidade de inserir múltiplas linhas no banco de dados. Este tipo de tarefa é árdua e geralmente, os desenvolvedores acabam passando um XML ou então, chamando múltiplas vezes a mesma procedure para processar cada linha.

Com o TVP, podemos definir uma variável do tipo Tabela, que pode ser utilizada como uma tabela comum dentro de uma proc (somente como leitura), permitindo que o desenvolvedor inclusive, utilize esta variável em joins e lógicas mais complexas.

Para detalhes de como utilizar esta técnica no ADO.NET, recomendo muito que seja lido este artigo no MSDN que explica as diversas formas de utilização de TVPs.

Grande abraço!

Mário Meyrelles (http://twitter.com/mariomeyrelles)
Equipe Accendis

Visão Geral

Nos dias de hoje é comum visitarmos sites e aplicações construídas com recursos de interface visual bem trabalhados, sem posts visíveis HTTP (refreshs) e com conceitos de usabilidade inovadores. Esse tipo de recurso traz ao usuário final uma experiência de uso muito mais agradável sobre sua aplicação.

Em meio a esse novo cenário de aplicações para internet surge o termo RIA (Rich Internet Applications), assunto que abordarei com a profundidade adequada durante essa nova série de posts. Essa série, entitulada RIA, terá como foco o desenvolvimento de aplicativos RIA utilizando Silverlight.

Vamos iniciar a série com uma visão geral sobre RIA e Silverlight.

O que é RIA?

A sigla RIA vem do termo Rich Internet Applications. Esse tipo de aplicação é a nova tendência para aplicativos web. Considero RIA como uma tendência por ainda ser conceito pouco difundido. Porém acredito que exista uma grande probabilidade de se solidificar devido as suas inovações.

Esse conceito de aplicativo permite ao usuário uma navegação e utilização muito mais confortável do que os aplicativos web convencionais. Os recursos visuais podem ser explorados com muito mais facilidade. Pode-se criar animações e efeitos audio-visuais com qualidade e baixo “peso”, ideal para aplicativos de internet. Mas as principais vantagens não são essas. Na perspecção de sistemas em aplicativos web (aplicativos que não são apenas sites) ganha-se muito em recursos de usabilidade e poder no que diz respeito a relativa mudança na arquitetura.

Os aplicativos web tradicionais funcionam da seguinte forma:

Explicação de arquitetura cliente-servidor em web.

1. Toda vez que uma página é requisitada ao servidor, ocorre um processamento e uma resposta em HTML é enviada para o navegador (cliente). Essa resposta é renderizada e uma página é visualizada pelo usuário.
2. A cada nova interação do usuário com o sistema uma nova requisição é enviada ao servidor seguida por uma nova resposta. O navegador renderiza a página novamente. Esse refresh incomoda muito o usuário durante a utilização da aplicação.
3. Com o surgimento do AJAX, tornou-se possível a renderização parcial da página, o que diminui o tamanho das requisições e respostas, tornando os aplicativos muito mais rápidos. O uso do AJAX também evita o refresh e a necessidade de renderização da página inteira, o que torna a aplicação muito mais confortável para o usuário.

A arquitetura RIA funciona de maneira um pouco diferenciada, principalmente no que diz respeito a tecnologia Silverlight. Os detalhes de funcionamento da tecnologia estão descritos no próximo tópico desse post.

O conceito de RIA já existe a alguns anos, porém tornou-se conhecido no mercado brasileiro apenas no ano de 2009. Isso ocorreu pelas limitações de conexão de internet. Para trabalhar confortavelmente com aplicações RIA, necessita-se de melhores conexões de internet, coisa que se tornou realidade no Brasil apenas nos últimos anos.

Existem diversas tecnoligias para desenvolvimento de aplicações RIA. Dentre as principais estão: Adobe Flex + Flash e Microsoft Silverlight.

Como a Accendis é uma empresa especializada em tecnologia Microsoft, utilizaremos como tecnologia base de nossos artigos o Silverlight.

Conhecendo o Microsoft Silverlight

Conforme comentei no tópico anterior o Silverlight é a tecnologia da Microsoft para criação de aplicações RIA. O Silverlight deriva do WPF (Windows Presentation Foundation) e pode ser considerado uma versão mais compacta e leve para rodar na máquina do cliente sem a necessidade da instalação do Microsoft .NET Framework.

Para o funcionamento do Silverlight é necessária a instalação de um plugin, assim como é costumeiro se fazer com o Adobe Flash. A Microsoft disponibilizou esse plugin para ser instalado nos mais variados navegadores, dentre eles: Internet Explorer, Mozilla Firefox, Safari e outros.

A arquitetura básica de funcionamento de um aplicativo Silverlight é um pouco diferente dos aplicativos web convencionais conforme ilustrado pela figura abaixo:

Ilustração do funcionamento de um aplicativo Silverlight

1. Quando o usuário acessa o endereço do aplicativo web uma requisição é realizada e um processamento acontece no servidor, assim como acontece nos aplicativos web convencionais. Da mesma forma o servidor gera uma resposta em HTML que é recebida e renderizada em formato de página pelo navegador.
2. Em meio ao conteúdo da página está a referência para um objeto Silverlight, o que pode ser comparado as referências realizadas para animações criadas em Adobe Flash.
3. O navegador verifica se o plugin do Silverlight está instalado. Em caso negativo solicita o download e instalação para o usuário.
4. Se o Silverlight já está instalado na máquina do cliente o navegador inicia o download do aplicativo Silverlight que será exibido como parte do contéudo da página acessada.
5. O aplicativo baixado roda no contexto do cliente, e todos os eventos e ações da aplicação são processados no cliente. O servidor recebe novas requisições apenas quando são necessárias consultas a banco de dados ou objetos que se encontram nele. Dessa forma o processamento das funcionalidades de interface ocorre na máquina do cliente.

A primeira impressão que todo o desenvolvedor web tem ao analisar essa arquitetura é que o Silverlight terá acesso completo aos recursos da máquina cliente. Isso ajudaria a solucionar diversos problemas encontrados no desenvolvimento de aplicativos web, mas também traria uma exposição de segurança muito grande. Dessa forma o Silverlight tem acesso bem limitado aos recursos da máquina cliente, semelhante às restrições em aplicações que utlizam o Adobe Flash.

Quais ferramentas utilizar para desenvolver?

As ferramentas mais importantes no desenvolvimento de aplicativos Silverlight 3 são o Expression Blend 3 e o próprio Visual Studio 2008. O primeiro é mais apropriado para a criação do design, animações e telas da aplicação, enquanto o Visual Studio é mais apropriado para a implementação dos eventos e funcionalidades.

No próximo post que estará no ar dentro de poucos dias explicarei os procedimentos necessários para a preparação do ambiente de desenvolvimento Silverlight.

Quais as linguagens utilizadas?

Como o Silverlight é uma versão compacta do WPF (Windows Presentation Foundation) que faz parte do Microsoft .NET Framework as linguagens de desenvolvimento são as mesmas. A linguagem utilizada para a criação do design, efeitos e animações das telas é uma linguagem de markup conhecida como XMAL (lê-se zamel). Assim como no ASP.NET, os arquivos de codebehind podem ser criados nas linguagens suportadas pelo Microsoft .NET Framework: C# e VB.NET.

Hoje já existem bons livros e materiais falando sobre o assunto e tratando o conceito de RIA de forma bastante profissional.
A tecnologia ainda não tem popularidade para ser comparada ao ASP.NET, porém acompanha as tendências e evoluções da web e com certeza será de conhecimento fundamental para os desenvolvedores dos próximos anos.

Para aqueles que tiverem interesse em saber um pouco mais sobre a implementação de RIA com Silverlight a melhor fonte é o site oficial: www.silverlight.net.

Nos próximos dias darei continuidade a essa série com um post sobre configuração de ambiente de desenvolvimento Silverlight.

Um grande abraço a todos.

Aubry Maciel (http://twitter.com/aubrymaciel)
Equipe Accendis

Conforme visto neste link, a opção de Compressão de Backup disponível no SQL Server 2008 Enterprise otimiza o tempo de backup e restore de bancos pequenos e relativamente grandes também.

Veja os detalhes do teste de Denis no blog dele em http://blogs.lessthandot.com/index.php/DataMgmt/DBAdmin/MSSQLServerAdmin/testing-backup-compression-in-sql-server-2008.

A boa notícia, segundo ele, é que esta opção estará disponível também na versão Standard do SQL Server 2008.

Grande abraço!

Mário Meyrelles (http://twitter.com/mariomeyrelles)
Equipe Accendis

Introdução

Este artigo visa demonstrar alguns conceitos básicos para você que está começando a trabalhar profissionalmente com .NET e se encontra no seguinte momento da carreira: “Vou começar um projeto do zero, qual é a melhor forma de se trabalhar?”

Vamos apresentar alguns tópicos interessantes sobre o conceito de camadas e noções de arquitetura de sistemas empresariais comuns. Vamos discutir de forma simplificada como os conceitos se relacionam, para que de fato, você consiga ter um norte para começar a desenvolver um projeto. E por fim, vamos demonstrar como tudo isso acontece organizando os projetos no Visual Studio 2008. No final do artigo temos o exemplo completo para download.

Conceitos Iniciais: Perguntas e Respostas

1. Ouço muito falar em desenvolvimento n-camadas. Mas exatamente o que são camadas?
   É praticamente um consenso no mercado a separação do software em camadas. Para saber quais são as camadas físicas da aplicação, basta fazer a seguinte pergunta: “Em quais máquinas meu sistema irá rodar?”. Como respostas comuns, a vasta maioria das aplicações em .NET rodam em um servidor Web com o auxílio de um servidor de banco de dados. Portanto, temos 3 camadas físicas rodando em 2 máquinas: Apresentação (servidor web), Regras de negócio (servidor web) e Persistência (servidor de banco de dados e servidor web).

   Outras correntes de pensamento julgam que o número de camadas é proporcional ao número de componentes que podem rodar independentemente. Por exemplo, no caso acima, se tivéssemos também um Windows Service com o qual a parte web se comunicasse, teríamos uma quarta camada. Mesmo que o serviço rode na máquina da web.  Ou seja, na prática, o que vale mesmo é o número de “pedaços de software independentes” que fazem alguma coisa. Podemos dizer que a camada de negócios é independente pelo fato que ainda é possível rodar apenas a lógica de negócios sem a necessidade da camada de apresentação através de técnicas simples como testes unitários, por exemplo.

   Camadas lógicas são grupos de funcionalidade geralmente reutilizáveis, mas que não conseguem rodar dentro de um contexto isoladamente. Por exemplo, podemos falar em camada de acesso a dados: tal camada lógica pode ser chamada de um serviço do WCF, de uma aplicação Web clássica ou então, de uma aplicação Windows comum. Uma camada física pode conter várias camadas lógicas. Por exemplo, a camada de negócios pode conter uma camada de regras de negócio, outra camada de controle de segurança, etc…  Mas necessariamente estão no fluxo de dados principal da aplicação.

   Resumindo, camada é todo o “pedaço de software” que participa do fluxo de dados principal da aplicação. Caso o “pedaço de software” não participe mandatoriamente do fluxo de dados principal, mas é sempre utilizado de alguma forma, provavelmente estamos em vista do que chamamos de componente.

2. O que são componentes na prática?
   Componentes são conjuntos de classes e funções agrupados por funcionalidade similar, que podem servir a qualquer tipo de propósito e podem ser chamados por qualquer outra camada, componente ou mesmo, várias camadas e componentes. Geralmente  os componentes são pensados com o reuso em mente. Inclusive, geralmente vemos que as empresas se preocupam mais em criar componentes do que camadas reutilizáveis. Na prática, ao criar uma camada de acesso a dados, não temos como reutilizar em outro projeto totalmente diferente. Porém, um componente de controle de exceções ou componente de envio de e-mail é sempre reutilizável.
3. O que são aplicações corporativas na prática
   Aplicações corporativas são aquelas onde a sua razão de existir se justifica pela real necessidade de resolver um problema da empresa. Simples assim. Ela serve para otimizar algum processo interno, podendo ter uma criticidade alta e também, podendo ser responsável por causar grandes prejuízos à empresa caso ela não esteja no ar. Podemos afirmar que na prática, todas as aplicações corporativas trabalham com banco de dados em algum momento. Aplicações não-corporativas são aquelas que na prática são úteis apenas para uma pessoa e não para um conjunto de pessoas ou então, no caso de jogos, servem para diversão. Tais aplicações podem ser muito mais complexas ou muito mais simples do que aplicações corporativas e quase sempre são pensadas de formas totalmente distintas de uma aplicação corporativa.

Cuidados importantes

O desenvolvimento em múltiplas camadas exige que o desenvolvedor/arquiteto tenha muito senso de organização. Nós da Accendis já presenciamos vários equívocos. Vamos a eles:

1. Não exagere no número de camadas! Utilize o mínimo de camadas necessário para que a aplicação funcione hoje e amanhã, quando for preciso criar novas funcionalidades. Quanto maior o número de camadas, maior será a lentidão da aplicação, pois os dados deverão atravessar mais obstáculos do que o necessário.
2. Não tenha medo de separar em camadas! Há uma grande quantia de sites que usam apenas um projeto Web para fazer tudo do sistema. Tudo! Outras equipes usam o mesmo Windows Service (.exe) para colocar todas as regras de negócio do sistema, tornado-o impossível de debugar. O maior erro dos desenvolvedores é não pensar na testabilidade do código, isto é, provar de jeito simples que o código funciona. E depois, o Visual Studio é bem prático para se trabalhar com vários projetos. Como outras vantagens, temos maior clareza e organização, e no caso onde há controle de versão, quanto maior o número de arquivos e projetos, mais divisíveis são as tarefas.
3. Evite adotar padrões de projeto prontos que são facilmente encontrados na web. Não é por que parece ser lindo usar alguns tipos de elementos de arquitetura que você realmente precisará usar. O exemplo mais clássico disso é o fato de se usar uma camada de regras de negócio que na prática, só serve pra chamar a camada de acesso a dados.
4. Não confunda os papéis das camadas! Evite colocar regras de negócio nas páginas de code-behind. Evite colocar nas regras de negócio componentes que podem ser reutilizáveis… Enfim, use o bom senso!
5. Use e abuse do conceito de Namespaces. Separe classes similares em pastas. Esta dica é especialmente importante para código VB.NET, onde a lógica de namespaces é confusa para os recém-chegados.
6. Geralmente se cria 01 projeto para cada camada lógica da aplicação. Não se recomenda juntar camadas num mesmo projeto (isto é, uma DLL com mais de uma função geral). Não se recomenda também criar vários projetos para um propósito similar.
7. Cuidado ao utilizar padrões novos/avançados de projeto, como por exemplo, inversão de controle, arquitetura de plugins ou suporte a script. Use tais recursos somente se for absolutamente necessário e se todos os riscos de fracasso estiverem controlados. O mesmo vale para arquiteturas Web 2.0, como RIAs, MVC, etc… Atualmente, a escolha da tecnologia da camada de apresentação acarreta em alterações profundas na arquitetura do sistema com um todo. O fluxo de dados se modifica radicalmente. O maior risco é a falta de conhecimento dos desenvolvedores, que já são obrigados a absorver as novidades tecnológicas em uma velocidade estonteante. Mas, sempre esteja informado sobre novidades arquiteturais, pois as mesmas podem causar uma drástica redução da carga de trabalho. Um grande exemplo é o uso do Entity Framework ou NHibernate.
8. Refactoring não é crime! Não tenha medo de alterações grandes no seu projeto! Projetos são feitos para resolver o problema do business. Como o problema a ser resolvido pode mudar com o tempo, seu projeto e sua arquitetura também podem ser influenciados. Por exemplo, podemos ter uma página da web com alguma funcionalidade que precise também estar presente em aparelhos móveis. Obviamente as mudanças são necessárias no número de camadas, nas formas de trocas de mensagens, etc. Outro exemplo pode ser a remoção de uma camada de acesso a dados antiga feita em ADO.NET clássico para evoluir com o LINQ ou NHibernate. Outras vezes, você ser surpreendido com a necessidade de suportar mais de um banco de dados na mesma aplicação. As coisas mudam. Não seja resistente a mudanças. Aproveite!

Arquitetura básica de um projeto Web em ASP.NET

Os projetos web de hoje em dia são relativamente complexos. E projetos de grande porte geralmente acompanham serviços, executáveis e demais acessórios para realizar tarefas diversas que não sejam apenas respostas a requisições da Web.

Porém, de alguma forma tais aplicações estendem ou imitam o padrão. Basicamente, quando se usa .NET, a receita de bolo é a seguinte, mas não necessariamente a mais “profissional” ou “correta”:

1. [Camada de apresentação] Crie um projeto do tipo “Web Application” no Visual Studio. Não crie o projeto como “Web Site” pois esta decisão acarreta em várias dificuldades em criar funcionalidade comum a todas as páginas e causa dificuldades grandes ao referenciar dlls de outros projetos.
2. [Camada de negócios] Para a camada de negócios, geralmente se cria um projeto do tipo “Class Library” para conter regras de negócios e outra “Class Library” para conter as entidades da aplicação. Portanto devem ser criados 2 projetos. Vale relembrar que os projetos do tipo “Class Library” são bibliotecas que quando compiladas viram DLLs comuns.
3. [Camada de acesso a dados / Persistência] No mínimo sua aplicação terá que acessar os dados de alguma forma. Os dados podem ser expostos pelo banco em forma de tabelas, views ou stored procedures. Para isso, você terá que escrever ou usar outra solução que automatize o processo de criação de métodos para se comunicar com o banco. Crie um projeto do tipo “Class Library” para o projeto de acesso a dados também.
4. [Componentes] Crie uma biblioteca de componentes utilitários. Este projeto deverá conter componentes úteis para todas as camadas. No caso real, pode haver mais projetos de componentes.
5. [Testes Unitários] Crie uma biblioteca para guardar testes unitários. Para isso, é preciso ter alguma versão do Visual Studio que suporte a criação de testes unitários ou então, usar o NUnit para criar os testes.

Com isso, vamos acabar com uma solution com 6 projetos, ainda isolados entre si. Vamos discutir sobre como referenciar os projetos dentro da solution.

1. Todas as camadas devem referenciar a DLL de entidades da aplicação.
2. O projeto de testes unitários deverá referenciar todos os projetos da aplicação, com exceção do projeto Web.
3. O projeto Web referencia a DLL de negócios.
4. O projeto de negócios referencia a DLL de acesso a dados.
5. Todos os projetos, inclusive o de testes unitários, poderão referenciar a DLL de componentes, à medida da necessidade.

O diagrama conceitual da Solution do Visual Studio fica com o mostrado nas figuras abaixo. Como nós da Accendis já passamos por vários projetos em várias empresas, uma das tendências que encontramos foi a nomenclatura em inglês de namespaces, classes e métodos. Mas na prática, muitas pessoas acabam misturando as nomenclaturas para que o nome fique o menor possível. O maior argumento para usar nomenclatura em inglês é o fato de haver chances de vender o sistema para algum comprador internacional, tendo como premissa que o cliente final deverá ter condições de manter o código.

Na imagem abaixo estão os detalhes de cada projeto a ser criado:

Lista de todos os projetos a serem criados no Visual Studio

Nesta imagem abaixo, podemos ver um desenho mostrando as dependências entre cada projeto:

Relacionamento entre os diversos projetos da Solution do Visual Studio

Conclusão

Com esta noção inicial de como organizar um projeto, como referenciar projetos e soluções, você está pronto para começar a entender ou mesmo criar um projeto empresarial Web comum de médio porte. Entretanto, este modelo muitas vezes pode ser estendido com mais pedaços de software, como Web Services, Windows Services e mesmo, alguma camada de aplicação RIA, como Silverlight ou Flex.

Antes de encerrar este artigo, queremos deixar claro que quase sempre compensa fazer este tipo de solução, com componentes separados em camadas. O que se vê por aí é que o projeto começa pequeno, cresce desordenadamente e fica impossível de se trabalhar com o tempo. Logo, o tempo inicial para montagem da solução compensa o esforço de refactoring futuro.

Para baixar esta solução de exemplo, clique aqui para obter a solução em formato zip, utilizando Visual Studio 2008 Team System e compilado em .NET Framework 3.5 SP1. No projeto de testes, referenciamos a DLL NUnit.Framework.

Dúvidas, Sugestões, Reclamações ou Dicas? Comente!

Grande abraço!
Mário Meyrelles (http://twitter.com/mariomeyrelles)
Equipe Accendis