Ontem um amigo gerente de projetos divulgou no Twitter um post realizado por Daniel Sousa e Silva que está publicado no IMasters. Para quem quiser conferir o link é: http://imasters.uol.com.br/artigo/16629

Esse POST detalha de forma muito clara os principais motivos que levam a maioria dos projetos de TI ao fracasso.
Segundo o artigo 24% dos projetos são cancelados antes de sua conclusão ou entregues sem nunca serem utilizados. Outros 44% são entregues com atraso ou com orçamento estourado.

No artigo o autor foca principalmente nos problema que dizem respeito à gestão dos projetos, que com certeza provocam a maioria dos problemas.

Gostaria nesse artigo de falar sobre um outro aspecto: a desqualificação dos profissionais que atuam na área de TI.

Durante minha carreira como desenvolvedor participei de diversos projetos. Tive o prazer de trabalhar em equipes fantásticas, mas infelizmente na maioria das vezes me vi no meio de equipes extremamente desqualificadas. O resultado não preciso nem comentar: projetos atrasados e problemáticos.

De quem é o erro nesse caso? Da equipe técnica ou da gestão?

Em minha opinião ambas as partes são responsáveis pelo problema.

Na equipe técnica todos querem se destacar nas organizações, receber promoções e melhores salários, mas poucos se preocupam em estudar e acompanhar a evolução da TI.

São raros os profissionais com quem trabalhei que realmente tinham conhecimento técnico para desempenhar suas funções. A grande maioria dizia saber de tudo, mas no fundo são extremamente dependentes do Google. Quando surge um determinado problema em que a solução não se consegue encontrar no Google os grandes profissionais rapidamente entravam em desespero. Não estou falando apenas de profissionais juniores, mas sim de seniores que deveriam ter pleno domínio sobre as tecnologias com que trabalham.

Para que os projetos possam ser entregues os “recursos” precisam ter condições de realizar as atividades com qualidade, afinal quando o projeto é planejado conta-se com isso. Essa deficiência que existe no mercado de TI pode ser uma grande oportunidade para aqueles que desejarem se empenhar e estudar, e com certeza conseguirão seguramente se destacar com facilidade nas empresas que trabalham.

Agora do outro lado estão os gestores. Será que os gestores não conhecem os profissionais desqualificados que possuem em suas equipes? Ou será que fazem vista grossa, cruzando os dedos e torcendo para que o projeto seja entregue com sucesso? Gerir um projeto não é a mesma coisa que torcer para que o seu time de futebol vença uma partida. Diferente da torcida pelo time, na gestão do projeto pode-se realmente tomar decisões corretas que interferem diretamente no resultado final.

É papel dos gestores identificarem as deficiências técnicas de sua equipe, e sempre que possível disponibilizarem treinamentos de qualificação. A meu ver as empresas e seus gestores muitas vezes se cegam pelo conceito do lucro máximo e se esquecem de investir nos principais recursos necessários para os projetos de TI: os profissionais envolvidos.

Com base nessas informações conseguimos perceber que ambas as partes tem sua culpa nos resultados negativos obtidos nos projetos de TI, mas cabe a cada uma delas tomar as providências ao seu alcance para sanar os problemas e melhorar a cada dia.

Um grande abraço,

Aubry Maciel

Introdução

Com o recém-lançado Visual Studio 2010, o C# passou por diversas melhorias. E para quem trabalha com automação do Excel utilizando VSTO (Visual Studio Tools for Office), a situação melhorou muito para o desenvolvedor C#. Até a versão anterior simplesmente não compensava o esforço de se fazer add-ins para Office utilizando C#. Por ser uma linguagem fortemente tipada e com tipagem estática, ao acessar os objetos COM do modelo de objetos do Office, era necessário realizar múltiplos casts para objetos em .NET existentes nos PIAs (Primary Interop Assemblies). Os PIAs, contêm o modelo de objetos de cada aplicação Office (Excel, Word, etc…) representados por “cópias” em .net de objetos COM. Para trabalhar com o modelo de programação do COM o VB.NET sempre foi melhor, permitindo parâmetros opcionais, variants e etc…, coisas até então inexistentes em C#.

O C# 4.0 agora suporta o sistema de tipagem conhecido por “tipagem dinâmica”. A tipagem dinâmica permite que o você chame métodos e propriedades que serão apenas resolvidos em tempo de execução, similar ao que acontece em Javascript. Essa resolução em tempo de execução é mais arriscada, mas, quando você bem o modelo de objetos, permite um código muito limpo, com quase nenhum cast desnecessário.

Na prática, com o C# 4.0, temos o mesmo poder de criar customizações para o Office utilizando a plataforma .NET que o VB.NET já oferecia. Com grande simplicidade, podemos criar aplicações muito legais e mais baratas, afinal, é possível usar todas as vantagens do Excel para manipular meus dados, sem a chatice de criar páginas em Web só para isso…

Nosso Exemplo

Este exemplo tentará ser um pouco mais completo. Vamos utilizar várias tecnologias para conseguir atingir nossos objetivos. Como ferramentas, utilizamos o VS2010 final, o Excel 2010 e o SQL Server 2008. Vamos realizar os seguintes passos:

1) Instalar os bancos de dados de exemplo do SQL Server 2008

2) Utilizar o Entity Framework para mapear os dados para a minha aplicação

3) Criar o serviço WCF que retorna a lista de produtos

4)Realizar testes simples do modelo e serviço

5) Adicionar a referência do serviço WCF ao Excel

6) Trazer os dados para o Excel

7) Trabalhar com os dados utilizando o C# e VSTO

Vamos detalhar cada passo com imagens, resolução de dúvidas mais recorrentes e vamos explicar tudo passo a passo. Vamos pra cima então!

Instalando o AdventureWorks para o SQL Server 2008

Atualmente os bancos de exemplo estão no CodePlex. O link para baixar os bancos de exemplo é: http://msftdbprodsamples.codeplex.com/releases/view/37109. Vale notar que para o exemplo temos instalado o SQL Server 2008 e não o R2, que saiu recentemente. Os bancos de exemplo são criados para cada versão do SQL Server e é importante instalar a versão adequada. Para esse teste, funciona qualquer versão do SQL Server.

Ao instalar, a dica é liberar antes o FILESTREAM para a instância do SQL Server 2008. Se não fizer isso antes, o instalador não coloca todas as versões do AdventureWorks. O instalador é bem inteligente e já faz a instalação de todas as versões do AW. Entre elas, tem uma versão Light, que é a que utilizamos no exemplo deste post.

Criando o modelo de dados com o Entity Framework

O EF nesta versão do .NET está com mais funcionalidades, entre elas, a possibilidade de criar modelo de dados em .NET e depois criar o banco de dados. Mas como já temos o banco de dados pronto, vamos criar um modelo de dados da forma mais simples possível, utilizando as opções padrão.

Antes de começar, criamos um projeto do tipo Class Library contendo uma pasta chamada BusinessEntities. Adicionamos a esta pasta um modelo de dados do EF:

Criamos uma conexão com o banco de dados AdventureWorksLT2008.

Utilizamos estas tabelas do modelo:

O modelo de dados ficou desta maneira:

Até aqui nada demais. Estamos usando o EF para automatizar o acesso a dados, sem grandes mistérios.

Criando o Serviço WCF que retorna a lista de produtos

Para este caso vamos hospedar o serviço no próprio IIS, utilizando as opções padrão do WCF. No caso vamos apenas renomear o serviço e as classes/interfaces para facilitar o uso deste serviço pelos clientes.

Após renomear os serviços, a solução ficou próxima disso:

O nome do serviço é ProductService e o método que traz todos os produtos se chama “GetAllProducts”. Veja o detalhe do código abaixo:

O método retorna uma lista de produtos que é trazida da biblioteca onde está guardado o modelo de dados do EF. Neste caso, abrimos o contexto que contém as entidades, obtemos os dados com o select e com o ForEach das listas genéricas, presente desde o .NET 2.0, utilizamos uma lambda expression que solicita que cada item da lista seja “desatachado” do contexto de dados do EF. Com isso, eu consigo passar a lista de produtos para os clientes remotos. Se eu não fizer o Detach, acontecerão vários erros ao trabalhar com os itens da lista de produtos, como por exemplo, tentativas de se conectar ao store de dados diretamente do cliente.

Vale lembrar que a string de conexão ao model deve ser declarada no arquivo de configuração do serviço. O construtor do AdventureWorkdLT20008Entities, objeto de contexto do EF responsável por controlar as operações com as entidades, sempre olha o arquivo de configuração para realizar a abertura da conexão. A imagem abaixo mostra o web.config com a informação de string de conexão ao modelo de dados do EF.

E finalmente, o serviço funcionando de forma padrão fica assim:

Na prática este é o jeito mais simples possível de se criar um serviço WCF. Não temos muitos segredos até o momento…

Testando o modelo de dados e o serviço WCF

Embora opcional, este passo consideramos muito importante para o desenvolvimento de qualquer coisa, desde um simples exemplo a uma complexa aplicação. Vamos realizar testes unitários muito simples capazes de indicar que o sistema está pronto para ser chamado do Excel. Não será preciso apelar para TDD neste caso pois nossos métodos são extremamente simples de serem testados. E não vamos contar com falhas como eventuais quedas do banco e do serviço, pois afinal, estamos querendo trabalhar mesmo é o com o Excel neste artigo. Vamos usar a estratégia de testes conceituais para este exemplo.

Crie um projeto usando o template de testes do VS2010. Adicione referência ao projeto contendo o DataModel. Adicione também uma referência ao serviço criado no passo anterior. As imagens mostram como referenciar o serviço ao projeto de testes. Basicamente o VS2010 identifica nos projetos da solução onde há um serviço WCF existente e puxa suas informações públicas, mostrando-as para nós.

Na guia “Advanced”, costumamos utilizar o List ao invés do Array para trabalhar com conjuntos de entidades por ser muito mais prático. Mas isso é opcional. Nós renomeamos a referência para ProductServiceReference para ficar mais legível no código final, pois este namespace que guardará o proxy do serviço WCF.

Com isso, vamos para o teste do modelo de dados:

Neste primeiro testes, conseguimos provar que o modelo funciona. E para comprovar, inicialmente coloquei um trace para que o teste escreva na janela de output o código e o nome de cada produto existente no banco. E o teste também contém um asserção para provar que há dados no banco para os testes. O teste executou ok. Fizemos o mesmo para o método que testa se o serviço realmente retorna dados.

Este teste realmente demorou mais para passar. Tínhamos nos esquecido de desatachar os objetos do contexto e por isso os dados nunca vinham. Outro erro que acontecia era o tamanho do conjunto de dados. O arquivo de configuração vem por padrão com um tamanho reduzido de bytes de tamanho da resposta. Tivemos que aumentar o tamanho do pacote no app.config do projeto de testes.

Vale lembrar que é recomendável sempre fechar o proxy do serviço WCF. Com o fechamento, o WCF libera os recursos como threads e alocações de memória que ele prepara para cada conexão ativa no serviço. E quando estamos trabalhando com o conceito de sessões no WCF, o fechamento indica o término de uma sessão. Abaixo mostramos o resultado final da tela de testes que o Visual Studio mostra quando os testes passam:

Como sempre, podemos debugar o teste, e no debug, podemos passar do cliente para o servidor na mesma execução. Com o F10, posso andar em cada método que é executado, e, se o cliente chama o servidor, o debug vai para o servidor e continua a execução, permitindo que tenhamos pleno controle da situação. Colocando o breakpoint tanto no servidor como no cliente, você sempre terá a informação de quem chamou quem e o que aconteceu durante as chamadas.

Criando uma customização de uma planilha do Excel 2010 com o VS2010

É possível customizar tanto documentos como a própria aplicação. Neste exemplo não é necessário criar uma customização do Excel, apenas é preciso adicionar novas funcionalidades a apenas uma planilha. Com isso, vamos optar pelo template de projeto Excel 2010 Workbook:

Ao prosseguir, teremos um projeto e um documento criado. Teremos algumas classes em .NET representando cada planilha do documento:

Como podemos ver, na prática um projeto com VSTO é muito similar a um projeto comum em .NET. Podemos adicionar novos itens, outras classes, referenciar outros projetos e muito mais. Neste exemplo, a referência ao serviço já foi adicionada ao projeto. Também por padrão é adicionado um certificado temporário para que o projeto possa ser aceito pelo Office.

Antes de prosseguir é preciso esclarecer alguns pontos – vamos focar esta seção mais no Excel, mas as perguntas e respostas são válidas para outros programas.

1. O que é o VSTO? O VSTO nada mais é do que o conjunto de ferramentas necessário para se trabalhar com o Excel utilizando o .NET. É composto de bibliotecas de classes, ferramentas gráficas e customizações do Excel necessárias para que o Add-in seja reconhecido e corretamente visualizado no Excel. Também é responsável por se comunicar com os objetos COM do modelo do objetos do Excel e realizar adequadamente as ações desejadas. E por fim, o VSTO possui um conjunto interessante de eventos trazidos do Excel para o .NET, de forma que é possível saber no .NET quando por exemplo, alguém altera uma determinada célula da planilha.
2. Como eu faço para conhecer o modelo de objetos do Excel? Para trabalhar com a automação é necessário ter noção de como se cria macros no VBA. Uma macro do Excel pode ser transcrita para o C# com certa simplicidade.  O modelo de objetos está muito bem documento na ajuda do VBA. Para mostrar a tela do VBA do Excel, use ALT + F11. Finalmente, use o Gravador de Macros do Excel para ir aprendendo os comandos e sintaxe mais comuns do Excel.
3. Vejo alguns namespaces que estão me confundindo. Para se trabalhar com o Excel, temos as bibliotecas principais representadas por Microsoft.Office.Interop.Excel e Microsoft.Office.Core. Essas bibliotecas contêm basicamente uma representação em .NET do que o Excel contém. Elas são os famosos PIAs. Se na tela do VBA você achar um objeto denominado Chart, no objeto equivalente em .NET você provavelmente também encontrará o Chart. Vale notar que as traduções em .NET são feitas com interfaces e não classes concretas em .NET. Mas na prática, você conseguirá controlar o objeto da mesma forma, chamando os métodos com os mesmos nomes e parâmetros vistos no VBA. Porém, existe um outro namespace que mora em outra biblioteca do VSTO denominada Microsoft.Office.Tools.Excel. Este último namespace guarda objetos em .NET que representam os principais recursos do Excel em .NET, melhorados de forma a se tornarem particularmente úteis. Eles contém uma representação bacana do Workbook, Worksheet, ListObject, NamedRange e alguns outros elementos. Tais elementos podem ser criados diretamente do .NET usando o designer do Visual Studio, muito similar à criação de um controle utilizando Windows Forms. Com isso, o desenvolvedor tem como referenciar de forma simplificada os objetos importantes de sua planilha.
4. Qual o melhor jeito de começar com os testes simples? O ideal é trabalhar com o Globals. Esta classe contém uma referência para todos os objetos do Tools.Excel de forma simples. Para acessar a planilha1, basta pedir Globals.Sheet1 e por aí vai… vamos mostrar na prática como funciona a referência a tais objetos. Brinque com o Range, com o Offset, modifique os conteúdos da célula… Para rodar basta utilizar o F5 comum para fazer os testes. O add-in é carregado e o Visual Studio consegue se atachar ao código .NET que está executando na planilha. Logo, é possível colocar breakpoints no VS2010 e olhar o que está em cada variável. Também é possível utilizar janelas como Immediate Window para realizar testes preliminares sobre a validade de suas expressões. O desenvolvimento para Office exige uma carga adicional de tentativa e erro para realizar uma determinada tarefa. E com o Visual Studio você tem total suporte a isso. Recomendamos que você tenha calma pois muitas vezes poderá acontecer um erro de COM impossível de descobrir pelo fato de não se ter um modelo legal de controle de erros como o .NET. Não se assuste. Vá por partes. Tenha certeza que cada pedaço da expressão funcionou. Lembre-se de não usar índice zero com o Range e laços For. Use e abuse do Immediate Window. Use Listas e Named Ranges – evite lógica com o número/nome da range. Por fim, domine o Excel.
5. E o Ribbon? Como trabalhar com ele? O Ribbon, que é o menu inovador lançado no Office 2007, também continua presente no Office 2010. Na verdade, ele foi ligeiramente modificado no Office 2010 – foi criado um “Backstage Ribbon” no 2010, que contém opções que geralmente ficariam no menu Arquivo. Esse backstage ribbon se chama File na versão americana do Office. No .NET, é um controle que pode ser adicionado ao projeto, com um code-behind contendo eventos convenientes. No designer do VS2010 é possível arrastar e soltar itens para o Ribbon e amarrar eventos a cada botão de forma normal, como se fosse em Windows Forms. Para o desenvolvedor, o Ribbon é uma aba que fica no dentro do menu Add-ins do Excel. E para o desenvolvedor, o Ribbon nada mais é que um form cheio de controles comuns. Simples e prático de usar. O Ribbon pode ser criado mesmo em customizações de documentos. Não necessariamente vale só para customização de aplicações.

Antes de prosseguir com a customização, fizemos um teste básico para ver se realmente era possível chamar o WCF de dentro do Excel. Embora isso pareça ser óbvio, não necessariamente tudo acontece conforme o esperado. No evento que é chamado quando o arquivo abre, colocamos o seguinte teste:

Entretanto, ocorreu um erro. Ao dar F5, o Excel tenta abrir:

Mas em seguida surgiu uma mensagem de erro:

Conforme esperado, o conjunto de dados era maior do que o padrão (conforme visto nos testes). Deixamos este erro acontecer para demonstrar que quando o erro acontece você pode parar, debugar e continuar com a execução. Não recomendamos que você mate o processo dando stop na depuração. Sempre continue com F5 e só então termine a execução. As falhas podem acontecer e quando acontecem, o Excel lança o erro neste formato mostrado acima e continua normalmente a rodar, sem cair.

Finalmente acertamos o config da aplicação e testamos novamente com sucesso.

Trazendo dados do WCF para o Excel

Tendo a certeza de que o WCF estava trazendo os dados e que o Excel é capaz de mostrar os dados, vamos para o próximo passo: mostrar os produtos na planilha do Excel.

Para isso, crie uma nova tabela na planilha principal com 2 colunas. Assuma que as colunas terão um header. Como as tabelas devem ter um nome, nós alteramos para tblProdutos:

Esta funcionalidade se chama “Tabela” no Office 2007 em diante. No Office 2003 esta funcionalidade se chama “Lista”. Por isso que no .NET ela também se chama ListObject. Com o uso de tabelas, os dados ficam muito mais organizados do que em planilhas comuns, sendo uma forma muito inteligente de trabalhar com dados no Excel, mesmo quando não estamos fazendo coisas tão avançadas como Macros e customizações com .NET.

O próximo passo é criar o Ribbon, que será mostrado ao usuário final e terá alguns itens para podermos realizar nossos exemplos. Ao escolher a opção Add New Item do projeto Excel, no VS2010 aparecerá vários itens. Vá no subgrupo Office e escolha a opção Ribbon (Visual Designer). É possível criar um Ribbon editando um arquivo XML específico diretamente – modo avançado de se trabalhar com o Ribbon.

O editor visual mostra o Ribbon vazio. Devem ser adicionados os controles ao Ribbon usando o designer visual por ser mais prático.

Com o Ribbon pronto, vamos fazer o código busca a lista no WCF e faz o databind com o ListObject do VSTO/Table do Excel. O código que executa é um evento do click do botão de dentro do Ribbon. Logo, ele não está em nenhuma planilha. Portanto é preciso referenciar os objetos de interesse utilizando a classe Globals. Vejamos como fazer isso:

A classe Globals é gerada automática pelo template do VS2010 e representa como propriedades estáticas os objetos importantes do documento Excel. O Sheet1 é uma representação melhorada da planilha para uso em .NET e não o Sheet do Interop. O tblProdutos é um campo do objeto .NET Sheet1.

O método SetDataBinding permite fazer o databind com qualquer conjunto de dados comum do .NET. No caso, este método possui a capacidade de escolher quais colunas podem ser mostradas ou não. O segundo parâmetro está vazio, mas por exemplo, poderia ser o nome da tabela que esteja dentro do Dataset no caso de múltiplas tabelas.

Com o databinding, eu consigo colocar os dados na lista sem ter que me preocupar com o número de linhas na lista, redimensionamento e sem ter que usar um laço For para processar cada registro. Muitos incômodos a menos. Com isso a lista preenchida fica conforme mostra a figura abaixo. O Ribbon tem mais 2 botões que serão úteis para os testes seguintes em cima da lista preenchida. Note que o Ribbon que montamos ficou dentro da aba Add-Ins. Nesta aba ficam também os outros add-ins de fabricantes diversos.

Trabalhando com os dados obtidos no Excel utilizando C# 4.0

A nossa Ribbon agora deverá ter mais dois botões conforme mostrado na tela acima. No designer ela fica assim:

O botão “Trabalhar com Lista” irá mostrar os 10 primeiros registros da lista. Desta forma poderemos ver algumas novidades que o C# 4.0 tem para nos ajudar nesta tarefa.

Antes de mostrar o método completo temos que comentar sobre os objetos dinâmicos do C#. Veja a imagem abaixo extraída do Intellisense:

Se você observar bem, o objeto correspondente a uma Range específica é do tipo dynamic. Isto é, não precisamos fazer um cast para o objeto exato do Interop para poder trabalhar com o objeto desejado. Note também que em C# antes era obrigatório passar o Type.Missing para os parâmetros opcionais e agora não é mais – ele já vem com o valor pré-fixado para nossa conveniência.

Para ser mais completo na explicação, o Range possui um indexer com o parâmetro coluna e linha opcionais. Isso significa que posso ter vários tipos de seleção de conjunto de células e na prática, vários tipos de retornos do mesmo indexer. Para isso é conveniente a assinatura com parâmetros opcionais e retorno dinâmico, pois mais tarde o desenvolvedor, que já espera qual será o retorno adequado, pode trabalhar com o resultado esperado sem se preocupar em tempo de compilação. Abaixo segue a assinatura do indexer da classe Range do Interop.Excel – o Range normal não foi evoluído no Tools.Excel. Só o NamedRange.

Voltando então ao exemplo, decidimos deixar o método mais prolixo para explicitar o uso do dynamic do C# 4.0:

Neste caso, embora não fosse necessário para este exemplo, fizemos com que a cada iteração do For, o Range equivalente à linha da lista de produtos ficasse guardado numa variável dinâmica. A partir deste momento, tudo o que for feito com a variável x também se torna dinâmico, permitindo que eu chame métodos e realize atribuições sem saber exatamente o que tem em x com a ajuda do Intellisense. Se eu quisesse chamar uma propriedade x.Teste, só iria dar erro em tempo de execução. O compilador, ao lidar com variáveis dinâmicas, não tem como descobrir quais são os métodos e propriedades de x. Mas como conhecemos o modelo de objetos, as variáveis valorColuna1 e valorColuna2 ficarão com os valores adequados. Finalmente, o método Append do StringBuilder saberá qual overload usar para inserir o número ou o nome do produto.

Finalmente, com um último exemplo mais prático, vamos mostrar todos os código de produto recebidos pelo serviço num MessageBox. Com isso vamos mostrar que também é possível iterar com foreach de forma mais prática em alguns casos. Podemos usar dynamic diversas situações como mostra a figura a seguir.

Executando os dois exemplos temos os seguintes resultados:

a) Primeiros 10 itens da lista:

b) Todos os códigos de produto recebidos do serviço:

Com isso conseguimos concluir como mostrar e trabalhar com dados no Excel, concluindo assim o exemplo.

Conclusão

Com esta pequena demonstração conseguimos mostrar como trabalhar com fontes de dados modernas como web services, por exemplo. O uso de VBA, embora seja bastante válido e muito poderoso, não permite que se use arquiteturas mais modernas nem ferramentas de desenvolvimento mais atualizadas para se criar aplicações atuais para a plataforma Microsoft Office.

O uso da plataforma Office está crescendo muito e os desenvolvedores hoje precisam entender que nem todo sistema precisa ser Web! Muitas vezes, uma solução muito mais complicada em Web pode ser facilmente resolvida utilizando o Office com inteligência.

O uso de .NET e Visual Studio 2010 também favorece muito o desenvolvimento de aplicações baseadas em Sharepoint, o que torna o uso do Excel, do Word e do Outlook particularmente importante como plataforma de desenvolvimento de aplicações corporativas. Com vários templates para Sharepoint, é possível criar solução altamente integradas com custos muito menores de desenvolvimento, utilizando ferramentas que os information workers conhecem há mais de 10 anos – a plataforma Microsoft Office.

Sobre Nós

A Accendis é uma consultoria que presta serviços utilizando a plataforma de desenvolvimento Microsoft. Conheça mais sobre o nosso trabalho www.accendis.com.br. Se você precisar de treinamento para você, sua empresa, alocação de profissionais em formato body shop e consultoria para resolver problemas mais complexos, estamos aqui para te ajudar.

Grande Abraço

Equipe Accendis

Introdução

A Accendis lança no mercado um curso intensivo e totalmente inovador destinado a pessoas que trabalham há algum tempo com o .NET e que costumam desenvolver aplicações corporativas comuns.

Com este modelo de treinamento, nós buscamos trazer para os desenvolvedores, líderes e gerentes de equipes de desenvolvimento uma visão mais moderna de como arquitetar e implementar aplicações .NET de forma mais objetiva e atual. Tudo isso em apenas 5 dias ou 10 noites! As aulas são todas realizadas em C#. Este curso está disponível também em versão in-company, permitindo que seus funcionários tenham um treinamento intensivo e qualificado sem custos com transportes e acomodação.

Vamos detalhar agora o que você aprenderá em cada aula.

Parte 1 – Conceitos modernos de orientação a objetos com C#

Conhecendo melhor o LINQ to Objects e LINQ to XML

Nesta parte do curso, após conhecermos melhor o que o C# tem a oferecer, vamos investir no conhecimento do LINQ em si. Vamos entender sobre o que faz o LINQ, quais suas aplicações e suas revolucionárias formas de se trabalhar com dados. Vamos também lidar com arquivos XML utilizando LINQ to XML, que por si só já é outra forma revolucionária de se trabalhar com dados XML.  Vamos falar sobre tipos anônimos, IEnumerable, IEnumerable<T>, IQueryable<T> e LINQ providers para quaisquer tipos de fonte de dados.

Coleções genéricas e concorrência

Você aprenderá sobre coleções genéricas com .NET, como filas, listas e pilhas. Para acrescentar ao tema, vamos explicar também sobre como usar estas listas utilizando múltiplas threads e também, aprenderá sobre as novas coleções que suportam concorrência, recém-surgidas no .NET 4.0. Você verá exemplos de múltiplas threads manipulando os mesmos objetos tanto para leitura como escrita simultânea. Vamos mostrar também operações que possam ser realizadas utilizando o PLINQ, isto é, paralelismo utilizando LINQ. Também serão expostas práticas comuns para criar coleções customizadas a partir de coleções existentes no framework.

Tipos genéricos e Herança

Vamos explicar sobre design de tipos genéricos, como classes, métodos, interfaces e delegates. O aluno receberá uma aula de cultura geral destinados mostrar o que é e o que não é legal fazer quando se trata de montar uma estrutura de classes. Vamos ver boas práticas ao montar herança, polimorfismo, eventos e muito mais!

Novidades no C# no Framework 3.5 e 4.0

Vamos fazer uma caminhada desde o C# do .NET Framework, explicando a teoria de métodos anônimos, uso de delegates e suas aplicações até chegar nas novidades que surgiram no .NET 3.5, como lambda expressions, delegates genéricos, utilização de LINQ, selectors, tratamento de coleções e enumerações, utilização de Extension Methods e suas implicações tanto ao utilizar LINQ como para outros tipos de situações. Vamos demonstrar novidades do C# no .NET 4.0 como métodos nomeados e introdução a linguagens dinâmicas.

Organização e boas práticas do dia-a-dia

Com todo o conhecimento adquirido, vamos fechar este módulo do curso falando sobre boas práticas no design de classes, métodos, eventos e boas práticas utilizando LINQ, Herança e todas as funcionalidades do C# disponíveis. Vamos mostrar como criar projetos organizados e como evitar que os projetos virem uma bola de neve. Este tema será revisto nos módulos seguintes.

Parte 2 – Arquitetura N-Camadas e Engenharia de Software

Este módulo é o coração deste curso. O treinamento deverá expor para os alunos noções básicas de engenharia de software, clarificando pontos-chave do processo de criação de sistemas modernos como a divisão/necessidade de camadas, testes, protótipos, provas de conceito e não menos importante, opções de projeto considerando requisitos não-funcionais como performance, segurança, escalabilidade e demais requisitos.

Conceito de camadas e fluxo de dados

Vamos abrir o segundo módulo deste treinamento tocando em um tema que invariavelmente todos os desenvolvedores de aplicações corporativas precisam conhecer: a organização do software em camadas. Vamos falar sobre fluxo de dados, processos, criação de componentes, responsabilidades de área do sistema. Vamos falar sobre testabilidade, modelagem de classes, provas de conceito e muito mais.

Acesso a dados

Aqui nós explicamos as funções das camadas de acesso a dados assim como explicamos também a necessidade de ferramentas ORM e também, explicamos sobre transações no banco de dados e também, boas práticas no design de camadas de acesso a dados. Os exemplos são apresentados com o SQL Server 2008. Também falaremos sobre as ferramentas ORM mais comuns.

Regras de negócio

Nesta parte do curso nós focamos na construção de uma camada de negócios forte, reutilizável e concentrando todo o domínio da aplicação. Utilizaremos conceitos de Domain-Driven Design. O aluno aprenderá sobre como construir o domínio e os processos que utilizam este domínio.

Camadas de Serviços

Nesta parte o aluno aprende a expor as regras e processos de sua aplicação para o mundo exterior através da exposição de serviços. Vamos falar sobre troca de dados entre sistemas, web services, WCF, formas de comunicação entre módulos e sistemas, entre outros conceitos. Vamos estabelecer as bases para a criação de sistemas distribuídos modernos, onde poderemos ter múltiplos tipos de aplicações acessando os mesmos serviços expostos. Vamos falar sobre SOA, mas não entraremos em detalhes sobre extenso assunto.

Camadas de apresentação

O aluno terá entendimento sobre o papel das interfaces de usuário nos sistemas, considerando toda a arquitetura do sistema. Vamos levar a discussão para o modelo de software orientado a serviços, onde é necessário que a camada de apresentação contenha apenas o mínimo de regras de negócio. Vamos mostrar falar sobre tecnologias atuais para se montar a camada de apresentação, como ASP.NET,ASP.NET MVC, Silverlight, WPF, Windows Forms e Compact Framework.

Construção de bibliotecas utilitárias

Aqui o workshop estimula o aluno a pensar sobre a criação de componentes de uso geral, tanto no projeto como em vários projetos. Com estes conceitos o aluno também aprende a não misturar lógica reutilizável com as camadas da aplicação.

Guia para testes unitários

Vamos explicar como criar testes unitários de forma prática, mostrando ferramentas que já vêm instaladas no Visual Studio e também, utilizando ferramentas de terceiros. Vamos apresentar conceitos sobre testes unitários simples, testes com banco de dados, teste de camadas de negócios. Não vamos abordar o teste automático de interface pois é um tema relativamente extenso, que não cabe numa proposta de workshop. Vamos falar também sobre criação de mocks e stubs. Vamos explicar também sobre a importância de testes unitários para o ciclo de desenvolvimento da aplicação, tornando-o como uma ferramenta importantíssima na gestão do software como um todo.

Endereçando requisitos diversos

Neste ponto o treinamento de volta para opções comuns de solução encontradas no ecossistema .NET para vários tipos de situação como segurança, caching, log, auditoria, performance, etc… O treinamento busca trazer para a sala de aula situações vividas em grandes projetos e claro, lessons-learned de nossa experiência de mercado.

Frameworks de uso geral disponíveis no mercado

O aluno conhecerá alguns dos frameworks úteis mais famosos como o Enterprise Library, NUnit e Telerik. Com isso, o aluno poderá evitar a reinvenção da roda ao utilizar bibliotecas prontas.

Parte 3 – Entity Framework

As ferramentas ORM são muito utilizadas no mundo das aplicações corporativas pois aceleram o desenvolvimento de sistemas simples a moderadamente complexos. Com este tipo de ferramenta o desenvolvedor não precisa ficar escrevendo explicitamente o código para manipular um banco de dados específico.

Com o surgimento do LINQ, o desenvolvedor ganhou a possibilidade de escrever código similar a consultas SQL dentro do .NET. Como conseqüência direta, a Microsoft criou o Entity Framework para mapear tabelas do banco de dados em objetos do .NET, de maneira automática. O NHIbernate já faz isso há algum tempo. A primeira versão do EF foi particularmente ruim para se trabalhar, embora ainda seja um grande auxílio para o desenvolvedor. O .NET 4.0 trouxe grandes evoluções nesta ferramenta, que agora torna muito mais fácil atuar em situações onde seja necessário lazy-loading, model-first development (seguindo assim uma prática do Domain-Driven Design) e também, facilidades na hora de salvar e alterar objetos ou grafos de objetos.

Vamos aprender a lidar com todos os cenários comumente encontrados como manipulação de tabelas simples, relações 1-N, N-N e também, as conseqüências do uso do Entity Framework na sua camada de negócios. Você verá que o uso do EF poderá ser uma excelente forma de economizar na construção do seu aplicativo e com isso, entregar seu projeto de forma mais rápida.

Os exemplos já serão mostrados utilizando o Visual Studio 2010 e o .NET Framework 4.0. Com isso, você terá em suas mãos o que há de mais moderno de tecnologia Microsoft para realizar acesso a dados.

Parte 4 – Windows Communication Foundation (WCF)

Este módulo é mais do que a simples explicação do que é o WCF. Antes de tudo, visamos motivar o aluno a ganhar mais cultura, expondo sobre o que são serviços e aplicações modernas, que hoje em dia não rodam apenas num mesmo tipo de cliente, mas podem rodar de diversas formas simultaneamente.

Vamos apresentar idéias e opções para o aluno de forma que ele tenha em suas mãos a total capacidade de decidir sobre como e qual tecnologia usar para resolver um determinado problema. Queremos passar ao aluno o senso crítico de como criar aplicações realmente escaláveis, distribuídas e simples de serem criadas.

Vamos entrar no detalhe da criação de serviços, exposição de serviços e dicas de construção e organização do serviço. O aluno poderá atender cenários Windows e não-Windows em suas aplicações. Suas soluções poderão conversar com serviços feitos tanto em uma linguagem .NET como outra como Java, por exemplo.

Finalmente, vamos contemplar cenários onde as camadas de apresentação fazem acesso ao serviço, mostrando o poder do uso da tecnologia .NET atual. Também vamos expor sobre tecnologias novas que a Microsoft está lançando para complementar o WCF e com isso, acelerar o ciclo de desenvolvimento de novos sistemas. E obviamente, vamos demonstrar alguns conceitos de SOA para que o aluno consiga seguir adiante nesta linha arquitetura de sistemas.

Parte 5 – Práticas estendidas com aplicação Real

Com tudo o que foi lecionado até o momento, os alunos terão este módulo para desenvolver em conjunto com os professores uma aplicação de exemplo com situações reais de integração, usando tudo o que foi mencionado até o momento. Vamos fazer uma aplicação que utilize Entity Framework, SQL Server 2008, WCF, utilizando uma arquitetura em camadas. E como exemplo de clientes, vamos utilizar o ASP.NET e também, um cliente Silverlight para demonstrar outras possibilidades com o .NET 4.0.

Grande Abraço!

Equipe Accendis

Introdução

Este artigo visa demonstrar como o uso de serviços em aplicações .NET podem te ajudar a criar aplicações distribuídas modernas.

Para uma idéia de como funcionam aplicações web modernas, veja o artigo anterior que mostra como criar começar a organizar a sua solução para começar a trabalhar.

Vamos falar sobre Web Services, Windows Communication Foundation, configurações típicas para sistemas Web e aplicações distribuídas. Vamos também falar um pouco sobre as tendências da Microsoft para a exposição de dados na forma de serviços modernos.

Onde Estamos?

Você criou uma aplicação Web. Ela entrou em produção na sua empresa. Você ganhou reconhecimento e notoriedade no ambiente de trabalho devido ao aumento de velocidade na obtenção de métricas. Muitos ficaram sabendo que as informações que o seu sistema gera são confiáveis. Outras áreas concorrentes viram outras oportunidades de redução de custos operacionais. Um e-mail chega:

“Olá! Nós precisamos muito de sua ajuda! O sistema ABC que você criou está nos economizando muito tempo, porém, ainda tenho que fica digitando o resultado dos seus cálculos no sistema XYZ que você criou no ano passado… Não tem como você fazer com que os dados apareçam automaticamente?”

Atualmente o sistema se apresenta para o cliente no formato Web clássico. Ele é muito útil, porém, é útil para seres humanos compreenderem as informações. Entretanto, outro sistema não consegue entender e processar os dados gerados nos seus relatórios. E agora o que fazer?

Para você que já está no mercado, a solução é quase óbvia: por que não usar Web Services?

Web Services

Web Services são lugares públicos conhecidos na rede (na internet, intranet, porta tcp local) que são capazes de expor uma informação com base num pedido. No caso acima, o sistema XYZ, que usa os dados do sistema ABC, deveria fazer uma requisição ao Web Service hospedado em algum endereço conhecido do sistema ABC. O sistema ABC recebe a requisição e dá a resposta em um formato combinado entre as partes.

Aí você que está começando pode se perguntar: “Não entendi bem, afinal, qual é a diferença entre um site normal da Web e um Web Service?”. A resposta prática para esta questão é a seguinte: um site comum da web retorna tudo o que pode aparecer no browser, como imagens, HTML, animações e demais itens. O Web Service funciona da mesma forma, usando os mesmos protocolos de rede e os mesmos caminhos, mas retorna apenas, no caso geral, um XML contendo os dados de interesse. Ambos possuem um endereço na internet/intranet. Neste exemplo, é possível ter o site, www.abc.suaempresa.com.br para hospedar o site correspondente ao sistema ABC. Para hospedar o Web Service do sistema abc, seria possível criar um endereço na intranet de nome www.abc.suaempresa.com.br/webservice.

Assim como browsers conseguem ler HTML, sistemas feitos .NET, Java e demais linguagens conseguem traduzir tudo o que está exposto no Web Service e com isso, conseguem se comunicar com o mesmo. Existe um protocolo padrão da indústria para a comunicação utilizando Web Services, que é o SOAP. Ao definir um Web Service, podemos definir as operações (posso receber comandos) e posso definir o tipo de dados o Web Service utiliza (por exemplo, podemos definir entidades complexas como por exemplo, a classe Pessoa). Também é possível definir outros parâmetros diversos, como a obrigatoriedade de certos parâmetros/valores, etc..

O processo de “tradução” do conteúdo de um Web Service geralmente é automático em todas as tecnologias da atualidade – inclusive em .NET. O Visual Studio consegue ler o que está no Web Service e gerar métodos e classes “proxy", que imitam o que o serviço faz dando a impressão para o desenvolvedor de que a chamada de um certo método é local.

Em várias plataformas de desenvolvimento, a comunicação entre sistemas utilizando Web Services é a forma padrão de se integrar sistemas diversos. E quando falamos de integração entre sistema de diversos fornecedores com diversas tecnologias, a forma mais simples de se conseguir uma integração é utilizando Web Services mesmo. Porém, para os desenvolvedores que utilizam a plataforma .NET., esta tecnologia é considerada obsoleta a partir do surgimento do .NET Framework 3.0 e 3.5, que trouxeram e consolidaram no mercado uma maneira mais completa de se trocar dados entre sistemas que rodam em Windows: Windows Communication Foundation.

Windows Communication Foundation

A Microsoft sempre disponibilizou para seus desenvolvedores um grande conjunto de opções para realizar quase sempre árdua tarefa de fazer 2 sistemas trocarem dados entre si. Com o advento do WCF, a Microsoft unificou e simplificou todos os tipos de tecnologias numa única tecnologia mais completa, simplificada e muito madura no momento da escrita desde post, Janeiro de 2010.

Com o WCF temos algumas boas vantagens:

• Não somos obrigados a comunicar utilizando SOAP via HTTP
• Qualquer aplicação pode ser servidor para o WCF, isto é, não preciso de um servidor Web para nenhum tipo de tarefa
• Posso contar com recursos do Windows para ativar o serviço com a chegada de uma nova mensagem
• Temos grande liberdade para determinar como será a passagem de mensagens de um lado para o outro. Temos controle sobre a segurança, formato das mensagens, transações, confirmação de recebimento de uma mensagem, filas de mensagens e também, podemos interferir diretamente sobre a mensagem recebida ou enviada. Podemos ter comunicações em 2 sentidos, coisa que nem sempre é fácil de ser implementada.
• Flexibilidade para configurar o serviço, muitas vezes, evitando que qualquer linha de código seja escrita.
• Não é necessário aprender Remoting, COM+, Enterprise Services, etc… – basta aprender o conceito de Web Services e o WCF em si.

Na prática, a maior parte das pessoas utilizam e utilizarão WCF para trocar mensagens SOAP via HTTP. A grande vantagem que vemos no uso do WCF é a possibilidade de se criar um projeto “Windows Service” (*.exe) para hospedar o meu serviço em WCF. Com isso, ganha-se a possibilidade de controle total, ainda mais quando o sistema tem chances de cair. Um serviço WCF hospedado no IIS, em alguns casos, pode ser prejudicial em caso de falha. Mas cada situação é diferente e para cada caso é necessário realizar uma análise completa da arquitetura para enfim decidir a melhor forma de hospedagem.

Qualquer tipo comum de projeto pode hospedar o WCF e quase qualquer tipo de aplicação .NET consegue fazer referência a um servço existente. Até mesmo aplicações como Office, Silverlight e Sharepoint trabalham bem com WCF.

Camadas de serviços modernas

Para o caso de aplicações atuais, o WCF é peça fundamental na arquitetura de um sistema orientado a serviços ou mesmo, para aplicações distribuídas.

Utilizando um mesmo serviço (ou conjunto de serviços) você pode fazer com que o sistema atenda a diversos tipos de clientes tais como Windows, Web, Celulares, Aplicações RIA (Flash / SIlverlight), Office, etc… Todos eles conseguem se conectar à mesma fonte de informação de forma uniforme, centralizando num único ponto as fontes de dados e possivelmente, de regras de negócio da aplicação como um todo.

Ao adicionar um serviço à solution do Visual Studio, você está na prática adicionando uma camada de serviços à sua aplicação. Como já falamos anteriormente, é preciso ter atenção e evitar qualquer camada desnecessária interferindo no fluxo de dados principal da aplicação. Mas, após as devidas análises terem sido feitas, você estará construindo uma aplicação com a possibilidade de ser distribuída, isto é, você ganha a capacidade de criar vários clientes para acesso dos mesmos dados. No caso de aplicações RIA, não há outra forma de se fazer acesso a dados sem ser por intermédio de uma camada de serviços, por questões de segurança da Web.

Consideramos como moderna uma camada de serviços criada sem restrições quando à forma de hospedagem, forma de lidar com as mensagens e principalmente, com a forma de passar os dados pelo “channel” ou canal de informações. Em .NET, somente o WCF consegue oferecer este tipo de capacidade para o desenvolvedor. Com o uso de WCF, o cliente pode referenciar o serviço da mesma forma que é referenciado um Web Service hoje em dia.  Porém para ser moderna a camada de serviços também precisa ser capaz de expor os dados de forma atualizada. Isto significa que os serviços de “hoje em dia” devem expor os dados em formato REST também. Outra funcionalidade também é a utilização de dados em formato JSON, XML e mesmo, serializados conveniente de forma binária para otimização de banda. O WCF possui tecnologia para endereçar todos estes requisitos. A Micrososft está adotando o padrão de acesso e manipulação de dados OData (Open Data Protocol), que basicamente uniformiza a forma de acessar e recuperar dados entre as diversas fontes de dados da internet de hoje em dia.

Tecnologias que devemos considerar para criar camadas modernas de serviços

Entity Framework

O EF foi lançado na versão 3.5 SP1 do .NET Framework. Ele é voltado para acelerar e mesmo, revolucionar aplicações que utilizam o banco de dados SQL Server. Como uma ferramenta ORM, ele evita que seja necessário criar um camada de acesso a dados formal para fazer operações do dia-a-dia. O EF gera um modelo de dados que é então utilizado pelas aplicações que o utilizam para realizar consultas utilizando o LINQ para gerar consultas diretamente ao modelo. Com esta consulta ao modelo, o EF gera o SQL e retorna / modifica os dados desejados. É possível utilizar stored procedures dentro do modelo de dados.

O EF no .NET Framework 4.0 está foi radicalmente melhorado, com suporte a cenários n-camadas melhorado e com muito mais funcionalidade para auxiliar os desenvolvedores a gerar modelos de dados customizados, lazy loading, suporte a entidades simples (sem o overhead do controle de alterações do EF) e ampliado suporte a mapeamento em cenários mais complicados que foram sugeridos pelos clientes. E finalmente, será possível desenhar primeiro o modelo de entidades da aplicação para então gerar o banco de dados correspondente, coisa que é possível com o NHibernate há tempos.

A grande desvantagem na época da escrita deste artigo, Janeiro/Fevereiro de 2010, é que não há providers gratuitos para quem trabalha com Oracle, Postgree e MySQL ainda. O que se sabe é que há chance de surgir um provider gratuito para MySQL. Há empresa que oferecem providers pagos, mas não conhecemos ninguém que utilize os mesmos (por favor me corrijam se eu estiver errado).

O Entity Framework é a tecnologia base para tecnologias que também utilizam o WCF como transporte, a saber: WCF RIA Services e o WCF Data Services.

WCF Data Services (antigo ADO.NET Data Services)

O Data Services serve para expor um modelo de dados do Entity Framework através de uma interface REST. O DS é uma extensão do WCF (isto é, pode ser hospedado como qualquer serviço WCF). É uma tecnologia que visa facilitar o acesso a dados tanto de aplicações Web comuns como AJAX, como Silverlight e .NET.

Para expor os dados via WCF Data Services, é preciso que se tenha uma fonte de dados que suporte consultas utilizando LINQ, isto é, que implemente IQueryable/IUpdatable. Resumidamente, a aplicação pede um endereço para o serviço, e este endereço é traduzido como uma consulta LINQ para que então, o provedor de dados retorne os dados de interesse.

Na prática, o DS serve para facilitar muito a vida de quem programa e cria serviços usando WCF. Com o WCF puro, é possível fazer tudo. Com o Data Services, temos uma facilidade muito maior para manipular os dados de forma que não seja necessário invocar métodos específicos para atualizar cada entidade do modelo de dados. E na prática, esta facilidade é conseguida criando um modelo de dados com o Entity Framework e expondo-o com o WCF Data Services.

Esta tecnologia, existe há mais de 2 anos, está evoluindo bastante e virá com novas features como por exemplo, paginação e ordenação via servidor. Considera-se que para que seja o padrão dos desenvolvedores ainda há um caminho a ser percorrido.

WCF RIA Services

O RIA Services é uma tecnologia que surgiu com o Silverlight 2 para simplificar o acesso das aplicações feitas em Silverlight a um serviço WCF. Por segurança, as aplicações RIA (Flash e Silverlight) só podem acessar um serviço caso o mesmo esteja no mesmo domínio da aplicação web que hospeda a aplicação RIA.

Uma aplicação web hospeda a aplicação Silverlight em um domínio. Geralmente o serviço não está no mesmo projeto da Web, isto é, está em um outro projeto, ou mesmo, outra solução do Visual Studio. Neste caso é preciso que o serviço permita que a aplicação Silverlght o acesse utilizando um arquivo de permissões (crossdomain.xml e/ou clientaccesspolicy.xml, por exemplo). Isto é, o servidor onde mora o serviço do WCF a ser acessado precisa ter estes arquivos configurados.

Com o uso do RIA Services, consegue-se um middle-tier de modo que o serviço acabe ficando no mesmo domínio da aplicação Silverlight. Mas esta não é a única vantagem. A tecnologia é muito semelhante ao WCF Data Services. É possível disparar do cliente queries usando LINQ, processar e retornar os dados definidos em um modelo de dados do Entity Framework. Com o RIA Services, o desenvolvedor Siverlight consegue quase tudo o que precisa para entregar um projeto e coloca-lo rapidamente no ar. Ele possui facilidades como paginação, ordenação, filtragem, validação, coisas que facilitam muito para o desenvolvimento.

O RIA Services é destinado quase que exclusiva ao uso de clientes Silverlight e por enquanto não houve a convergência com o Data Services. Mas a intenção da Microsoft parece ser o investimento no ecossistema de tecnologias destinadas a serviços da web, pois afinal, a web está mais focada em serviços do que nunca.

Opções de projeto com o Visual Studio

Uma das grandes vantagens de se usar o WCF quando você criar a solução completa, isto é, os clientes e os serviços, é que você pode compartilhar bibliotecas entre as diversas camadas. Esta possibilidade permite que você use as mesmas classes do serviço, no cliente. Ou seja, a entidade “Pessoa” é sempre definida na mesma dll, que é chamada tanto de uma aplicação web como de um serviço WCF. Isto pode ser bom em situações onde o domínio é mais rico e contém métodos, herança e demais complicadores que podem não ser corretamente expostos pelo serviço em si.

Porém, este tipo de técnica é mais benéfica em aplicações web do que em aplicações mais ricas, como WPF, Windows e Silverlight. O grande problema de compartilhar os objetos de negócio é a necessidade de distribuição das dlls todas as vezes que a versão muda. E para aplicações distribuídas, é recomendável manter a regra de negócios no lado do serviço já que todo o código que roda no cliente pode ser de alguma forma visto e pode sofrer processo de engenharia reversa. Numa aplicação ASP.NET, a lógica da aplicação ainda fica no servidor, impedindo que a lógica da aplicação circule pela internet, vindo para o cliente apenas código Html/CSS e Javascript.

Com o surgimento do Entity Framework, surgem novas opções de projeto. Podemos simplificar as coisas de modo que a Solution do Visual Studio fique flexível para atender a diversas situações.

Vamos propor aqui uma solução mais purista na parte de serviços. Desta forma, vamos evitar dependências com tecnologias que ainda estejam mudando, como é o caso do WCF RIA Services e do WCF Data Services. Vamos utilizar o Entity Framework como tecnologia de acesso a dados, e vamos também, propor alguns clientes que fazem acesso à camada de serviços.

Vamos lá!

Camada de acesso a dados:

Não será necessário criar a camada de acesso a dados de forma clássica. O Entity Framework expõe ao modelo de dados para as camadas de negócio e assume a responsabilidade de invocar a infraestrutura do ADO.NET (e por conseguinte, tabelas,views e procedures do banco de dados SQL Server 2005/2008). Vale lembrar ao usar Oracle ou outro banco de dados, faz mais sentido usar outra ferramenta como o NHibernate. O mesmo vale para aplicações multi-banco de dados. Há a opção com do LINQ to NHIbernate, que pode ser uma boa saída para manter os benefícios de se usar LINQ contra o modelo de dados mapeado pelo NHibernate.

Camada de negócios:

Nesta proposta de separação de camadas, vamos simplificar um pouco as coisas. Como já vamos utilizar o Entity Framework para fazer o acesso a dados, vamos centralizar na mesma biblioteca as regras de negócios e as entidades da aplicação. As entidades do sistema são as mesmas geradas pelo EF. Caso o modelo de dados não forneça todas as propriedades necessárias, ou caso seja necessário adicionar métodos às nossas entidades geradas pelo modelo, iremos utilizar classes parciais para complementar as entidades da aplicação.

Na mesma dll mas em pastas diferentes, poderemos definir as regras de negócio e algumas classes utilitárias. Claro que para projetos maiores e mais complexos pode fazer sentido quebrar essa camada de negócios em mais bibliotecas.

Vale ressaltar aqui que, com o lançamento do EF do .NET 4.0, você tem a capacidade de controlar o mapeamento e a geração de classes automática do EF, permitindo que se use modelos de dados cada mais inteligentes nos mapeamentos. Também será possível criar o banco e dados a partir da definição do modelo de dados, tudo isso de dentro do Visual Studio.

Camada de serviços:

Vamos utilizar a camada de serviços como o ponto de encontro da nossa aplicação. Ela acessará a camada de negócios, fazendo o meio-de-campo entre os dados do servidor e as solicitações dos clientes diversos, que acessarão o serviço WCF. Neste projeto, vamos pensar numa arquitetura mais robusta e portanto, vamos hospedar o serviço em um Windows Service, para ter total controle sobre o que acontece com o serviço. O IIS7 possui várias funcionalidade interessantes para a parte de serviços, mas nossa experiência mostra que quando o serviço está propenso a erros ou quando ele exige uma quantidade maior de memória e processamento, o servidor Web pode não ser o host mais adequado. Porém, como muitos de nós utiliza hospedagem compartilhada, a hospedagem em IIS pode ser a única opção.

Clientes: ASP.NET, Silverlight e WPF

Os clientes poderão fazer referência direta apenas ao serviço neste modelo de solução proposto. Eles não poderão ter acesso a mais nenhuma dll das camadas acima. Para a utilização de Silverlight em aplicações de negócios, recomenda-se também o padrão de projetos MVVM, que busca criar aplicações mais testáveis e com lógica de negócios mais separada possível da lógica de apresentação.

Para o caso de aplicações ASP.NET clássicas ainda acreditamos que faz sentido criar uma DLL compartilhada entre o serviço e a Web. Neste caso específico, não temos grandes problemas com deploy e local de armazenamento da regra de negócios no caso simples, onde o serviço e a web estão na mesma solution e fazem parte do mesmo processo de Deploy.

Conclusão

O uso de WCF ainda está sendo descoberto pelas empresas não só do Brasil, mas do mundo. Há muita coisa pronta feita em Web Services “normais” do .NET e inclusive, novos projetos ainda hoje são criados são criados usando esta tecnologia considerada legada pela Microsoft, mas não ainda pelo mercado. O grande argumento para a não migração é a falta de pessoal capacitado para utilizar esta nova tecnologia. Entretanto, é preciso que os arquitetos connheçam esta importante opção de projeto principalmente, quando o simples não é o suficiente para uma determinada situação.

Para nós da Accendis, o uso de WCF é mainstream nos projetos em que atuamos e consideramos que esta é a tecnologia base para várias inovações da Microsoft em um horizonte de 1 a 3 anos.

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

Introdução

Periodicamente vamos publicar este tipo de post para responder a algumas questões que surgem no nosso dia-a-dia, nos nossos treinamentos ou mesmo, ao conversar com profissionais de diferentes áreas de conhecimento.

Neste post vamos falar sobre como é trabalhar com .NET. Você saberá o que é preciso para começar a aprender, caminhos de aprendizado, tendências, comparação com outros frameworks concorrentes, ferramentas e dicas diversas. Vamos lá!

1. O que é a plataforma .NET?

Falando de forma resumida, a plataforma .NET é um conjunto de ferramentas e infraestrutura para executar código geralmente escrito em C# ou Visual Basic.NET. Na prática, usa-se .NET em vários contextos, como Websites dinâmicos, programas para Windows Forms e aparelhos móveis como celulares e dispositivos móveis diversos que contenham sistemas embarcados.

2. Qual é a linguagem de programação para usar com .NET?

Basicamente, temos o C# e o VB.NET. O C# é a linguagem com o maior suporte na comunidade e com a maior quantidade de exemplos. Sua sintaxe é limpa, absorvendo a parte boa de linguagens Java e C++ e até mesmo, absorve conceitos de linguagens mais modernas. A linguagem VB.NET possui compatibilidade total em termos de funcionalidade com a linguagem C#. Ela é usada normalmente por empresas que já utilizavam alguma tecnologia baseada em VB6. No Brasil seu uso é muito difundido e em projetos de migração de ASP 3.0 para ASP.NET, por exemplo, em quase 100% dos casos a migração termina com VB.NET. Como nossa opinião , recomenda-se o uso do C#, pois o mesmo nasceu para a plataforma .NET e a Microsoft jamais a tirará do mainstream. A maioria das consultorias que usam o C# como linguagem padrão e até mesmo, impedem formalmente o uso de VB.NET. O mercado também, embora de forma velada, demonstra certo preconceito contra programadores de VB/VB.NET, já que é possível programar sem regras tão rígidas como as do C#.

3. O que é preciso para começar a aprender .NET?

Na prática, todos nós aprendemos .NET e tecnologias correlatas, como Javascript e linguagem SQL para conseguir criar aplicações que acessam dados. Para se trabalhar com .NET é preciso utilizar ferramentas que não são gratuitas. Embora seja possível trabalhar com ferramentas gratuitas, na prática, as ferramentas gratuitas não permitem que você crie aplicações profissionais como por exemplo, aplicações de várias camadas no mesmo projeto. Os investimentos da Microsoft são realizados apenas para o Visual Studio e todos os fabricantes de plugins só consideram a existência do Visual Studio.

Para começar o ideal é conseguir uma versão trial tanto do Visual Studio como uma versão trial do SQL Server 2005/2008. Com isso o aprendiz já tem a capacidade de criar coisas profissionais e já tem a visão de como se trabalha no dia-a-dia com .NET e SQL Server. Outra opção é conseguir uma máquina virtual configurada. Isso isola completamente o ambiente de desenvolvimento, mas em compensação, há o custo de HD, CPU e memória extra a ser considerado nesta opção. Para usar tranquilamente uma máquina virtual recomenda-se 4GB de memória e CPU de 2 ou mais núcleos.

Porém, além das ferramentas acima, não é preciso mais nada. Não é preciso conseguir plugins, componentes de terceiros ou nada a mais em especial para começar a desenvolver aplicações comuns, diferentemente de Java, que obriga o desenvolvedor a ter que procurar ferramentas diferentes para tipos diferentes de projeto – ou pior(?!) – permite que o mesmo trabalho seja feito com diferentes ferramentas. Entretanto, com o passar do tempo você poderá instalar algumas extensões para o Visual Studio, como por exemplo, um conjunto de controles visuais profissional, como o oferecido pelo Telerik.

4. Quais são os tipos mais importantes de aplicações .NET?

No Brasil, a maioria esmagadora de vagas exige o conhecimento de ASP.NET, que é a criação de páginas dinâmicas com .NET. A construção de páginas em ASP.NET na prática exige mais do desenvolvedor, como conhecimento em SQL Server, ADO.NET, Javascript, CSS e mais recentemente, tecnologias Ajax. Nas exigências de conhecimento em banco de dados, as empresas exigem que o desenvolvedor saiba criar procedures, functions, triggers e views. Logo, para quem está querendo lugar no mercado de desenvolvimento, basicamente é preciso que se saiba apenas a parte Web. Pode ser necessário também conhecer o desenvolvimento de Webservices e mais recentemente, serviços do WCF.

Entretanto, há muitas empresas que desenvolvem para Windows Forms e também, desenvolvem Windows Services. Este conhecimento é importante mas não é tão necessário para o mercado, embora os mesmos sejam até mais simples para se trabalhar.

Outro ramo que surge com crescente interesse é o desenvolvimento de aplicações para celulares e dispositivos móveis, tanto para Windows (aplicações para um celular como por exemplo um gerenciador de contatos comum) como para ASP.NET (por exemplo, um site de banco).

As áreas de desenvolvimento para Office e Sharepoint estão crescendo mas ainda não são tão importantes como o desenvolvimento Web. O .NET só ganhou grande importância e grande quantidade de usuários devido ao seu modelo de programação para aplicações Web.

5. Comparação de .NET com PHP e Java (J2EE)

O PHP possui também um grande mercado e grande parte de suas ferramentas são livres. O Java também. Entretanto, o PHP é uma tecnologia exclusivamente desenhada para sites Web (por favor me corrijam se eu estiver errado neste ponto!) e não serve para aplicações desktop ou de outros tipos comuns. Logo, não se usa PHP para aplicações empresariais complexas. O .NET foi criado pela Microsoft para concorrer com a Sun no disputado mercado de linguagens de programação.

Após ambas tecnologias chegarem à maturidade atual, é difícil apontar algo que não seja possível criar com as versões máximas de cada tecnologia, com qualquer tipo de ferramenta a disposição e com orçamento ilimitado. Quem trabalha com .NET poderá ter dificuldade de criar aplicações modernas para Linux, já que é preciso utilizar o Mono para compilar o código. Já quem utiliza Java poderá ter dificuldade de conseguir criar os designs estonteantes que o WPF (Windows Presentation Foundation) permite criar.

Na prática, aplicações empresariais são criadas hoje em dia apenas com Java (J2EE) ou com .NET. A escolha da tecnologia é geralmente moldada pelas necessidades do cliente final, como a hospedagem, licenças disponíveis e etc. Quanto aos custos de aprendizado, ambos são similares. Quanto aos custos de se usar tais tecnologias, o custo tanto dos desenvolvedores como os de software podem variar muito. Muitas vezes a variável que acrescenta custo ao projeto é externa, como por exemplo, o custo maior do banco de dados Oracle em relação ao SQL Server. O .NET segue mainstream na Microsoft e o Java pertence à Sun, que até o momento da escrita deste post está para ser comprada pela Oracle. Acreditamentos que o desenvolvimento de melhorias para as tecnologias baseadas em Java continuarão a todo vapor.

Para quem está começando, recomendamos o uso do .NET atual, que está muito maduro, possui uma excelente linguagem de programação, excelente suporte e principalmente, um ecossistema de tecnologias e fornecedores muito simplificado. É sempre o mesmo servidor web, sempre a mesma forma de instalar, sempre a mesma forma de desenvolver a aplicação web – sem grandes dificuldades em termos de infraestrutura. Para quem está na faculdade ou numa empresa de desenvolvimento, há chances de haver uma chance de parceria com a Microsoft para fornecimento de sistemas operacionais e ferramentas de desenvolvimento, tornando o custo inicial de adoção e aprendizado menor. Por exemplo, a Accendis conta parceria da Microsoft tendo acesso a grande parte dos seus produtos para desenvolvimento de aplicações.

6. Quem ganha mais? Um desenvolvedor Java ou .NET?

Essa questão é realmente complicada de responder. Mas conversando com os nossos colegas de mercado tanto de Java como .NET, vimos a notar que de fato, os salários são similares. Acredita-se que o mercado de desenvolvedores Web é maior para quem trabalhar com tecnologia .NET. Já para quem trabalha com Java, acredita-se que o mercado é maior para quem trabalha com aplicações empresariais ligadas a processos de negócio. Para vagas sênior de São Paulo, salários CLT tanto de .NET como Java pagam de 5.000 a 7000 reais, dependendo das necessidades de skill da vaga e se realmente, você for apenas programar e no máximo, liderar uma equipe – isto é – se você não for gerenciar projetos. Para vagas de pleno temos uma faixa de 3.000 a 5.000 reais e para júnior, até 3.000 reais. Os valores são válidos para São Paulo e região.

7. Em resumo, quais são as coisas que um desenvolvedor típico de .NET precisa saber?

Em resumo um desenvolvedor completo de .NET precisa saber:

• C# ou VB.NET (orientação a objetos, construções, arquitetura de eventos, etc…)
• ASP.NET (ciclo de uma páginas web, arquitetura cliente-servidor)
• ASP.NET Ajax
• HTML
• Javascript
• CSS
• Webservices/WCF
• SQL Server (linguagem T-SQL)
• Criação de Windows Services
• Noções de separação de camadas da aplicação
• Compreensão de diagramas da UML

Outros tipos de skill podem ser cobrados de forma mais específica, com por exemplo, conhecimento em Business Intelligence, conhecimentos matemáticos, edição de imagens e conhecimento em design,  Windows Workflow Foundation, Sharepoint, Integração com Office e mais.  Porém o que as pessoas mais valorizam numa empresa comum (isto é, sem ser uma consultoria de software) é a capacidade de transformar regras de negócio em melhorias para a empresa. O desenvolvedor que aprende a regra de negócios, que consegue gerar documentos adequados e consegue fazer com que seu time gere valor com o software tem grandes chances de subir em sua carreira. Pessoas assim não são só apenas programadores, mas sim, analistas de sistemas e mais tarde, gerentes de equipe, gerentes de TI e eventualmente, assumem posições com capacidade de decidir sobre a evolução do business.

8. Ok! Como fazer para começar com o aprendizado?

Realmente, o melhor jeito de começar é lendo algum livro e começar pelo caminho do auto-aprendizado. As faculdades atualmente não ensinam o .NET na sala de aula e portanto é preciso procurar por tutoriais, livros, revistas e mesmo cursos. O importante é que você já precisa conhecer programação para começar a aprender .NET, Java ou demais tecnologias atuais.

Há inúmeras fontes de informação e após ler os conceitos básicos da linguagem, use seu tempo e crie por exemplo, um cadastro simples e depois um sistema completo um pouco menos simples – com essa experiência você conseguirá ter uma real noção dos problemas que acontecem como erros de todos os tipos.

Dependendo do projeto, das experiências vividas na empresa e aplicação do desenvolvedor, diz-se que é possível ver uma pessoa chegar a um nível pleno em 12 meses. E vale lembrar que mesmo que você já conheça alguma tecnologia, você sempre será iniciante em uma tecnologia mais nova. Por exemplo, se você já conhece ASP.NET não necessariamente será bom em Silverlight sem estudar, sem se aplicar e sem ter horas de vôo na tecnologia em questão. Evite estudar/adotar tecnologias muito novas que ainda não possuem o devido grau de suporte e aceitação no mercado.

Grande Abraço

Equipe Accendis.