Qual será o destino do LINQ to SQL?

Essa semana, o time do ADO.NET publicou um Roadmap para os frameworks de acesso a dados LINQ to SQL e Entity Framework.

Dois trechos me chamaram muito a atenção. O primeiro deles foi pelo lado positivo, pois a MS está trabalhando muito na evolução do Entity Framework e já está recomendando para soluções de acesso a dados.

“We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios”

Por outro lado, eu não esperaria muitas novidades no LINQ to SQL daqui pra frente. No máximo algumas ferramentas para tornar o desenvolvimento mais fácil e correções de bugs.

“We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.

Bom, se o pai da criança está recomendando utilizar o EF, não serei eu que vou contrariá-lo, correto? 🙂

Abraços
André Dias

Iniciando com o Windows Workflow Foundation

Pra quem está interessado em iniciar seus estudos no Windows Workflow Foundation (WF) ou simplesmente entender como “encaixar” esse recurso em sua aplicações, uma boa fonte é o site de arquitetura para Workflow & Business Processes em http://msdn.microsoft.com/en-us/architecture/aa699452.aspx.

Lá você encontrará ferramentas, webcasts e artigos sobre engines de workflow, orquestração de serviços, monitoração e principalmente como desenvolver e integrar tudo isso. É um prato cheio de informação pra quem trabalha ou quer trabalhar com workflows.

[]s
André Dias

O que significa ser arquiteto?

Uma discussão que freqüentemente vem à tona em fóruns, posts ou até mesmo num bate papo informal é: Qual o verdadeiro papel de um arquiteto?

Já ouvi versões dizendo que um arquiteto é um programador experiente, outras dizendo que é uma pessoa que consegue projetar softwares que atenderão todos os requisitos do cliente, porém visando uma aplicação fácil de manter, com boa performance, etc.

A minha opinião é de que um arquiteto tem que ter um conhecimento amplo de tecnologia e saber utilizá-las em cenários adequados visando resolver o problema proposto. Nem mais, nem menos. Apenas o problema proposto.

O arquiteto tem que ter a sensibilidade de identificar a real necessidade de negócio do cliente e lhe propor a melhor solução e também soluções alternativas que poderão, de fato, viabilizar o negócio, já que nem sempre a melhor solução é a mais viável.

Como esse assunto dá muito pano pra manga, recomendo uma leitura na última edição do The Architecture Journal. Essa última edição aborda exatamente o papel do arquiteto e também oferece um espaço para você dar a sua opinião e conferir o que os outros arquitetos pensam sobre o assunto. Confiram o fórum de discussão em http://msdn.microsoft.com/en-us/architecture/cc460196.aspx

Abraços
André Dias

Novos Exames de ADO.NET e ASP.NET liberados

Boa notícia para quem já vem acompanhando as novas tecnologias do .NET Framework 3.5. A Microsoft liberou recentemente mais dois exames betas para as tecnologias ADO.NET e ASP.NET.

Eu, como adoro o assunto de acesso a dados, fui procurar o conteúdo da prova e para a minha surpresa, além do ADO.NET tradicional cairá também LINQ e o Entity Framework que está atualmente em versão CTP.

Na prova de ASP.NET, não vi muitas novidades para as provas anteriores. Os pontos que me chamaram a atenção foram : Chamada de serviços WCF, AJAX e criação de páginas para dispositivos móveis.

Uma outra boa notícia é que já há promo codes disponíveis para a realização FREE do exame. Os promo codes das provas são:

  • 70-561: TS: Microsoft .NET Framework 3.5, ADO.NET Application Development
    Promo Code: 561B1
  • 70-562: TS: Microsoft .NET Framework 3.5, ASP.NET Application Development
    Promo Code: 562B1

Ainda não foi publicado o conteúdo oficial das provas, mas no Blog Microsoft Certifications você poderá encontrar um rascunho do que deverá cair.

ADO.NET: https://blogs.msdn.com/gerryo/archive/2008/03/13/get-ready-for-the-ado-net-3-5-mcts-exam.aspx

ASP.NET: http://blogs.msdn.com/gerryo/archive/2008/03/13/get-ready-for-the-asp-net-3-5-mcts-exam.aspx

Boa sorte!!

Erros e dúvidas comuns entre desenvolvedores de aplicações orientadas a objetos

Há alguns anos atrás eu mantinha um site chamado EnterpriseGuys cujo objetivo era retratar a tecnologia no mundo corporativo, onde aplicações .net se integram com java, metodologias ágeis trabalham lado a lado com processos mais “formais”, a qualidade de software ajuda a garantir o sucesso das aplicações. E todos os artigos tinham relacionamentos entre sí.

Infelizmente, tive que abandonar o site, mas a boa e velha internet fez o favor de guardar alguns conteúdos que ainda são totalmente atuais e eu gostaria de compartilhar com vocês uma entrevista que fiz no EnterpriseGuys (EG) com o Dr. Spock. Confiram:

Erros e dúvidas comuns entre desenvolvedores de aplicações orientadas a objetos

Orientação a Objetos: Alguns dizem que é um conceito simples, que possuem um domínio sobre ela, enquanto outros tem pavor só de ouvir o termo. A verdade é que a OOP não é tão trivial quanto parece e para nos ajudar a entender esse conceito tão polêmico convidamos um especialista no assunto. Aproveitem essa grande aula do Dr. Spock.

Dr. Spock
Consultor e arquiteto de software que desenvolve sistemas para a Web com tecnologias OO, banco de dados e Java desde 1996. Um teckno-freak, apaixonado e evangelista das novas tecnologias e arquiteturas para o desenvolvimento de sistemas complexos de software.

EG: Spock. Antes de tudo, gostaria de agradecer por ter aceitado o nosso convite e gostaria que você falasse um pouco da sua experiência no desenvolvimento de softwares, com o que está trabalhando atualmente e as suas áreas de interesse.

Dr. Spock: Sou um desenvolvedor que começou a trabalhar com as novas tecnologias e o desenvolvimento de aplicações para a Web por volta de 96. Comecei neste período num provedor de internet. Programei várias aplicações para a Web desde essa época. Mas, aos poucos fui migrando de tecnologia para o desenvolvimento de aplicações Web até ter contato com processos, metodologias e a orientação a objetos, culminando com uso do Java e da arquitetura J2EE.
Atualmente estou investindo muito no aprendizado das técnicas de modelagem orientadas a objetos com o uso de frameworks que disponibilizam o uso racional de Design Patterns, componentização e serviços distribuídos e transacionais. Mas, desde 99 venho programando aplicações com Java, OO, Design Patterns e J2EE.

EG: Com a sua experiência, você já deve ter passado por várias empresas e dado de frente com várias arquiteturas de sistemas. Gostaria de saber qual a sua impressão sobre essas arquiteturas. As empresas têm se preocupado mais com a produtividade utilizando ferramentas RAD ou optado por um modelo realmente orientado a objetos garantindo a alta coesão e baixo acoplamento?

Dr. Spock: A verdade é que muitos ainda estão aprendendo a orientação a objetos e os gestores estão tentando resolver os problemas de gerenciamento. A grande preocupação das empresas, e com razão, está na profissionalização da gestão de projetos. Sem uma gestão de projetos adequada e sem saber lidar com pessoas, de nada vai adiantar dominar a tecnologia se for necessário apagar constantes incêndios por falta de um planejamento ou por prazos insanos. Com isso, os desenvolvedores estão sendo pressionados pelos prazos e urgências irreais. Assim, muitos acabam tentando resolver os problemas usando, sem maturidade, as ferramentas RAD para adquirir produtividade e tentar atender as pressões. E no fim acabam, por falta de experiência, conhecimento ou pressão dos prazos, negligenciando um bom modelo OO.

EG: Muitos analistas acabam desenhando um modelo de objetos que é um espelho das tabelas do banco de dados. Essa abordagem é correta? Quais as vantagens e desvantagens desta abordagem?

Dr. Spock: Novamente, a maioria dos desenvolvedores está aprendendo OO e a programar aplicações com este paradigma. Enquanto isso, ainda é necessário obter requisitos com o cliente e estabelecer o modelo para o quê e para o como o sistema será implementado. Normalmente quem realiza estas tarefas são os analistas de sistemas mais antigos e “experientes” que já não tem tanto “jeito” para programar com as novas tecnologias. Como muito destes analistas aprenderam a programar construindo um modelo de entidades e relacionamentos para os dados, acabam fazendo aquilo que sabem quando se defrontam com o desafio de modelar um sistema OO: desenhando um modelo de dados que é um espelho das tabelas! O problema dessa abordagem é que a distância entre o modelo relacional, que estabelece a idéia de normalização, e o modelo orientado a objetos têm um grande abismo conceitual que os separam. Na orientação a objetos existem vários conceitos que poderíamos aplicar, tais como a herança, polimorfismo, padrões de projetos, interfaces e outras técnicas OO, que ao fazer uma modelagem que privilegia o modelo de dados deixamos de aplicar. Essa abordagem acaba resultando no que alguns chamam de aplicações que nada mais são do que “janelas para tabelas”. Essa limitação traz a tona todos os problemas e deficiências da abordagem estruturada, além de toda a complexidade da orientação a objetos sem usufruir os seus benefícios.

EG: Há alguns mitos sobre a OOP dizendo que esse modelo degrada a performance da aplicação, aumenta o tempo de desenvolvimento e a complexidade do sistema. Até que ponto isso é verdade?

Dr. Spock: Faço minhas as palavras da gangue dos quatro (GoF) citadas no livro clássico sobre padrões de projetos: “Projetar software orientado a objetos é difícil, e projetar software orientado a objetos re-usável é mais difícil ainda”. Por conta dessa dificuldade é uma verdade afirmar que o tempo de desenvolvimento é maior quando comparado com as técnicas mais antigas e que a complexidade é maior. Contudo, este é o investimento necessário para obter o que a orientação a objetos tem para nos oferecer: reuso, facilidade de manutenção e evolução, agilidade para atender novos requisitos ou mudanças nos requisitos e custos menores de manutenção e evolução. Portanto, aplicar a OO e a OOP significa um investimento inicial, e não um preço a pagar, para obter um retorno (ROI) a médio e longo prazo num projeto. Porém, o que acontece na maioria dos projetos que vemos por aí é que este investimento se torna rapidamente um prejuízo porque não tem uma boa gestão.

EG: Uma dúvida muito freqüente nas empresas em que passei é sobre como devemos empregar a OOP na geração de relatórios. Devemos utilizar apenas as entidades previamente definidas ou criar objetos DataHolders(Views) específicos para cada relatório?

Dr. Spock: Este problema, como muitos outros, não é um problema simples ou fácil de resolver. Mas, vejo que a solução depende dos requisitos que nos são apresentados. Como tudo o que desenvolvemos! Se precisarmos de flexibilidade e agilidade para atender mudanças ou novos layouts dos relatórios, podemos desenvolver um modelo OO para representar as entidades envolvidas na definição do objeto chamado “relatório”. Se os requisitos exigem performance, podemos fazer uso de recursos que são disponibilizados pelos gerenciadores de bancos de dados para delegar parte do processamento para estes gerenciadores. Portanto, não existe mágica. Contudo, para nossa sorte, já existem disponíveis na comunidade ‘open source’ boas soluções OO para este problema recorrente.

EG: Atualmente, tanto a Sun quanto a Microsoft estão disponibilizando bibliotecas para efetuar o acesso a dados diretamente da camada de apresentação. Isso não fere os princípios da OOP? Qual a razão desta abordagem?

Dr. Spock: Este tipo de abordagem não chega a ser um crime. A exigência pela separação da camada de apresentação da camada de negócio é mais uma boa prática que existe há muito tempo por causa do padrão de projeto chamado MVC (Model-View-Controller), do que por causa OO em si. Mais uma vez, a solução será determinada pelos requisitos. Portanto, podemos nos deparar com a necessidade de acessar recursos da camada de persistência de dados diretamente da camada de apresentação porque sob certas condições e requisitos esta seria a melhor solução. Por outro lado, sob outras condições ou requisitos a melhor solução seria separar em camadas com responsabilidades bem definidas como sugere o MVC. Geralmente, adotamos esta última estratégia porque desejamos flexibilidade e generalidade no modelo em detrimento de um tempo muito menor de desenvolvimento. O que não podemos fazer é nos privar de adotar a melhor solução para o problema com que nos deparamos porque a “estratégia da moda” a considera uma heresia!

EG: Lazy Loading: Herói ou vilão?

Dr. Spock: Não existe certo ou errado absoluto neste mundo virtual. Usar ou não a abordagem de “Lazy Loading” numa aplicação que acessa grande volumes de dados vai depender do contexto do problema que estamos tentando resolver. Por exemplo, montar uma página Web com o resultado de uma consulta que devolve 50 mil registros é uma insanidade. Mas, num processamento na camada de negócio, que normalmente é executada num servidor e acessado remotamente, usar “Lazy Loading” para trazer os mesmos 50 mil registros que seriam usados num processamento ou cálculo para gerar poucos resultados intermediários também significa uma insanidade. Porque neste último caso nos depararíamos com o problema dos “n+1” acessos ao repositório de dados enquanto seria mais eficiente acessar as informações fazendo “fetch” para obter os pacote de dados como resultado de uma única consulta.

EG: Muitos autores dizem que a melhor forma de modelar um sistema é primeiro definir o modelo de classes e a partir dele criar o MER, porém sabemos que atualmente é praticamente impossível começar um sistema totalmente do zero sem ter que integrar com alguma base de dados já existente. Qual a melhor maneira de contornar essa situação?

Dr. Spock: Desta questão podemos derivar duas situações. A primeira se refere à necessidade de uma aplicação para a manutenção dos dados que já existem nos banco de dados legados. Para este caso, porque não estabelecer um modelo de classes para manipular estes dados? Apesar de que o melhor seria usar algum framework de mapeamento objeto/relacional que seja orientado a SQL, tal como o iBatis. A segunda situação está relacionada à construção de uma solução para um problema onde poderíamos fazer uma modelagem de domínio com a definição de objetos e as suas respectivas classes que precisariam ter o seu estado persistido em tabelas previamente existentes ou simplesmente alguns dos dados que compõem o estado destes objetos seriam obtidos ou persistidos nas bases de dados. Para este caso, não precisaríamos nos dirimir de fazer um bom modelo OO para representar as entidades de domínio. Contudo, precisaríamos fazer uso de algum framework de mapeamento objeto/relacional orientado a objetos, ou seja, algum framework que implemente o idioma da OO e ao mesmo tempo transforme para o modelo relacional, tal como o Hibernate. Porém, ainda sim, poderíamos ter a primeira situação coexistindo com a segunda se encapsularmos a primeira situação numa camada interna da aplicação que seria acessada por uma camada mais externa que representaria o modelo de domínio da aplicação com a sua concepção baseada no melhor estilo da OO.

EG: Há alguns anos, tínhamos a OOP como a “solução para todos os problemas”. Hoje já temos a AOP (programação orientada a aspecto) como uma “estensão” que veio para suprir os problemas trazidos pela OOP. Você acredita que podemos ter uma substituição deste modelo a curto prazo?

Dr. Spock: A verdade é que o aspecto complementa o conceito de objeto, e não uma solução para problemas oriundos da programação OO. Existem características que vários objetos compartilham mesmo sendo de natureza (classe) diferente. A deficiência da OO reside no fato de que os conceitos de herança e interfaces não são suficientes para flexibilizar e generalizar estas características (aspectos) que estes vários objetos possuem. Então, como uma forma de capturar estas características como um novo elemento de modelagem e implementação na OO, surge o conceito e o artefato chamados de “aspecto”. Além disso, o “aspecto” vem sendo implementado nas linguagens como um recurso que é conectado dinamicamente aos objetos, tal que torna a herança de estruturas e comportamentos um recurso dinâmico que antes era estático e definido em tempo de projeto. Ou seja, uma vez o código compilado não muda mais!
Por isso, não encaro a AOP como um substituto a OOP. A verdade é que muitas tecnologias e plataformas estão migrando para o paradigma OO. Podemos tomar como exemplos o Java, desde a sua concepção, e o .NET, dentre outras plataformas e linguagens. Portanto, não consigo vislumbrar, através da minha visão limitada e “além do alcance”, uma mudança de paradigma que nos obrigue a uma mudança como foi da abordagem estruturada para o paradigma OO.

EG: Pra encerrar, quais são as dicas que você deixa para elaborarmos um bom modelo orientado a objetos?

Dr. Spock: Como disse Morpheus para o Neo em Matrix: “Free your mind”. Este é o primeiro passo para aprender OO. Então, obviamente, o segundo passo é: efetivamente aprenda OO e use-a sem medo e com responsabilidade, ou seja, saiba o que está fazendo. Além disso, não tenha medo de se esborrachar lá embaixo! O resto é experiência que só se adquire com o tempo, paciência e aplicando as melhores soluções que muitos já experimentaram e estão documentadas e disponíveis no mundo virtual.

Entity Framework para Oracle, DB2 e outros bancos

Há alguns meses, eu publiquei um post sobre o LINQ to SQL (até então conhecido como DLinq) trabalhar exclusivamente com SQL Server e falando que a tendência era de que a Microsoft iria disponibilizar um Object Model para parceiros estenderem.

Pois bem, parece que a tendência se confirmou e hoje o David Sceppa, Program Manager do ADO.NET, divulgou uma lista de parceiros que estão trabalhando em providers do Entity Framework para Oracle, DB2, MySQL e muitos outros. Confira a lista completa dos parceiros e providers abaixo:

  • Core Lab – fornecendo drivers para Oracle, MySQL, PostgreSQL e SQLite
  • IBM – fornecendo drivers para IBM DB2 data server e Informix Dynamic Server (IDS)
  • MySQL AB – fornecendo drivers para MySQL
  • Npgsql – fornecendo drivers para PostgreSQL database versões 7.3+ e 8.x
  • OpenLink Software – fornecendo drivers para Oracle, Informix, Ingres, Sybase, MySQL, PostgreSQL, DB2, Progress e Microsoft SQL Server, e qualquer data source acessível via OpenLink ODBC ou JDBC bridge drivers
  • Phoenix Software International – fornecendo drivers para SQLite databases
  • Sybase – fornecendo drivers para SQL Anywhere databases
  • VistaDB Software – fornecendo drivers para to VistaDB databases
  • Firebird – fornecendo drivers para Firebird

Pena que alguns deles são pagos, mas acredito que teremos em breve bons providers free.

Abraços
André Dias

Está realmente mais fácil desenvolver software?

Apesar de não ser muito velho, eu tive a oportunidade de escrever alguns programinhas em linguagens procedurais como o Cobol e Clipper. Para fazer esses programinhas, que ainda vemos em padarias e farmácias, eu não usava mais que um Edit do MS-DOS, um compilador e um link editor.

Eu escrevia as dezenas de .PRGs, não tinha que saber nada além da linguagem e quando queria “abusar” um pouquinho, usava no máximo uma biblioteca gráfica chamada CLBC.

Bons tempos! Eu era feliz e não sabia!

Há duas semanas, eu participei do TechEd 2007, um evento fantástico, muita coisa nova, mas uma afirmação que vi em várias palestras me fez para para pensar um instante. Está realmente mais fácil desenvolver softwares?

Antes mesmo de escrever uma linha de código, eu tenho que ler caso de uso, entender o diagrama de classes, ver o comportamento dinâmico através do diagrama de sequência, analisar o MER, dar uma passada pelo documento de requisitos não funcionais e ver o que vai se aplicar ao caso de uso que irei desenvolver, planejar testes unitários, só para citar alguns.

E na hora de codificar, o que irei usar? Silverlight, WPF, ASP.NET Ajax, ADO Entity Framework, LINQ, WCF, WF, ASP.NET MVC, .NET Framework 3.5, SQL 2008, DSL. Isso listando apenas tecnologias Microsoft. Se abrirmos o leque para outras empresas ou open source, a coisa fica ainda pior (ou melhor?).

O que mais chama a atenção disso tudo, é que são produtos / tecnologias que não possuem mais que dois anos de vida, sem contar que algumas nem foram lançadas oficialmente. E o VB6, DAO, RDO, ADO, ActiveX, ASP 3, DTS, COM+, Remoting, ASP.NET WebServices que eu usava até algum tempo atrás?

Tenho notado que a cada 2 anos em média, eu tenho que reaprender a fazer software para não ficar desatualizado. E nem sempre você tem a possibilidade de se tornar especialista num produto / tecnologia para utilizá-lo, ou seja, você acaba perdendo muito tempo em erros bobos que acabam consumindo todo o tempo que você “ganharia” utilizando a nova tecnologia.

É, a cada dois anos eu aprendo um monte de tecnologias novas para resolver problemas que as tecnologias do passado diziam que resolveria :-)..

Concluindo, se está mais fácil desenvolver eu não sei, quando eu usava Clipper eu não tinha toda a integração e necessidades que temos hoje, mas que está cada vez mais complicado acompanhar essa evolução tecnológica, está!!! Sabe o que é pior? EU ADORO ISSO!!!

Viva a tecnologia :-p

Abraços
André Dias

Liberação do primeiro CTP do ASP.NET MVC

Semana passada, Scott Guthrie anunciou em seu blog a liberação do primeiro CTP do ASP.NET 3.5 Extensions. Esse novo pacote de extensão do ASP.NET contém os seguintes componentes:

  • ASP.NET Ajax Improvements
  • ASP.NET MVC
  • ASP.NET Dynamic Data Support
  • ASP.NET Silverlight Support
  • ADO.NET Data Services

Como a minha praia é mais arquitetura de software e acesso a dados, de todo esse conjunto de componentes, os que mais me interessam são ASP.NET MVC e ADO.NET Data Services.

Se você também está interessado em aprender um pouco sobre o design pattern Model-View-Controller (MVC), seguem abaixo alguns links que te darão uma boa base de como implementar essa arquitetura em sua aplicação:

ASP.NET MVC Framework (Part 0): What is it?
ASP.NET MVC Framework (Part 1): Building an MVC Application
ASP.NET MVC Framework (Part 2): URL Routing
ASP.NET MVC Framework (Part 3): Passing ViewData from Controllers to Views
ASP.NET MVC Framework (Part 4): Handling Form Edit and Post Scenarios
Scott Hanselman’s ASP.NET MVC First Look Screencast
TDD and Dependency Injection with the ASP.NET MVC Framework
Writing Unit Tests for Controller Actions

É, parece que alguns anos após abandonar o Java e o Struts, voltarei a programar com esse conceito na veia (nem vem com aquela história de que ASP.NET já implementa MVC com Page Controller desde a versão 1.0, que não cola) 🙂

Abraços
André Dias

DLinq só funciona com SQL Server?

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

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

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

[]s
André Dias