Waldemir Cambiucci - Solutions Architect - Microsoft Brasil : Entity Framework

Leitura Recomendada: artigos sobre Entity Framework

wcamb — Fri, 04 Sep 2009 02:59:00 GMT

Olá pessoal, tudo certo?

Depois de uma semana bem agitada com Tech-ed Brasil, palestras e até uma General Session para variar um pouco, esta semana tivemos algumas discussões com equipes de projetos em empresas grandes.

Uma dessas reuniões tratou de aspectos de Entity Framework e o uso de uma camada de persistência de dados em aplicações Web.

Imagine um cenário de aplicação Web na intranet de uma empresa, com mais de 3000 usuários previstos, 350 usuários simultâneos, uma análise de 1500 pontos de função e um modelo de dados em torno de 450 tabelas.

Esse cenário é até comum no mercado e podemos considerar o desenho abaixo uma bela simplificação, posicionando alguns componentes interessantes:

Aqui, aproveitei um desenho da sessão do Condé (DAT301) do último Tech-ed Brasil, valeu Condé! :)

Veja que já estou apondando algumas decisões para o projeto, como o uso de ASP.NET MVC para a interface Web, serviços WCF para as regras de negócio e uma camada de persistência com Entity Framework, implementando vários EDMX, um para cada domínio de dados que participará da aplicação.

Para fundamentar a camada de dados com Entity Framework, alguns artigos são interessantes pelos exemplos fornecidos, veja:

Criando um modelo de dados de entidade
By John Papa
Ref.: http://msdn.microsoft.com/pt-br/magazine/cc163286.aspx

Acesso a dados flexível com LINQ to SQL e Entity Framework
By Anthony Sneed
Ref.: http://msdn.microsoft.com/pt-br/magazine/dd263098.aspx

Obtenha uma modelagem de dados flexível com o Entity Framework
By Elisa Flasko
Ref.: http://msdn.microsoft.com/pt-br/magazine/cc700331.aspx

Expor e utilizar dados no mundo de serviços web
By Elisa Flasko e Mike Flasko
Ref.: http://msdn.microsoft.com/pt-br/magazine/cc748663.aspx

N-Tier Application Patterns
By Daniel Simmons
Ref.: http://msdn.microsoft.com/pt-br/magazine/ee321569.aspx

EF v2 and Data Access Architecture Best Practices
By Tim Mallalieu
Ref.: http://msdn.microsoft.com/pt-br/magazine/ee236639.aspx

Para esse projeto, ainda outros aspectos serão importantes, como:

segurança de mensagens e de transporte
validação de parâmetros e métodos dos serviços WCF
caching de dados
tratamento de exceção
hosting de serviços WCF
administração do ambiente em produção
transferência de dados entre camadas, via DTO – Data Transfer Object, entre outros…

Mas como eu gostaria de destacar apenas as questões de Entity Framework, fica aqui uma última dica de leitura, o blog do Danny Simmons, gerente de produto do Entity Framework, que tem mantido um excelente blog sobre EF.

Danny Simmons’s Blog
Ref.: http://blogs.msdn.com/dsimmons/

Bastante coisa para ler, bons exemplos para testar!!!

Por enquanto é só! Até o próximo post :)

Waldemir.

Construindo soluções com Entity Framework e arquitetura em múltiplas camadas.

wcamb — Mon, 22 Dec 2008 20:17:00 GMT

Olá pessoal, tudo certo?

Esse assunto tem sido recorrente desde julho, retornando em algumas discussões com empresas de diversas áreas: Como organizar uma arquitetura de solução usando Entity Framework? Como representar as entidades de negócio, as interfaces de serviços e como passar esses dados entre as várias camadas de uma aplicação?

Para começar, tenho recomendado olhar a parte IV do AppArchGuide 2.0, que anunciamos semana passada, aqui:

patterns & practices : Application Architecture Guide 2.0
Ref.: http://blogs.msdn.com/wcamb/archive/2008/12/19/patterns-practices-application-architecture-guide-2-0.aspx

Uma arquitetura de referência interessante é a organização de uma aplicação desktop (Rich Client Application), como vemos a seguir:

Note que na camada de negócios, temos os Business Workflows, Business Components e os Business Entities bem definidos. Nesse cenário, os BE's representam as abstrações de dados que obtemos a partir da camada de dados, via Entity Framework.

Na sequência, um bom exemplo de implementação é dado no artigo do John Papa, que segue abaixo:

Entity Framework em arquiteturas de camadas
John Papa
Ref.: http://msdn.microsoft.com/pt-br/magazine/cc700340.aspx

O artigo apresenta uma solução que oferece um bom começo para quem está pensando em projetos com o Entity Framework. A figura a seguir apresenta a organização básica da solução, onde vemos as interfaces em WCF para comunicação entre a camada de apresentação e a camada de negócio.

Finalmente, vale lembrar que o Otávio fez uma apresentação sobre o assunto durante o último Tech-Ed Brasil 2008, usando o mesmo artigo do John Papa para falar sobre múltiplos contextos e boas práticas. Veja alguns comentários dele aqui:

Semana de acontecimentos
Ref.: http://blogs.msdn.com/otavio/archive/2008/10/19/semana-de-acontecimentos.aspx

Por enquanto é só! Até o próximo post :)

Waldemir.

ADO.NET Entity Framework : novos providers estão chegando.

wcamb — Sat, 14 Jun 2008 21:34:00 GMT

Olá pessoal, tudo certo?

O último TechEd 2008 trouxe algumas novidades sobre o mundo ADO.NET Entity Framework e LINQ, vale conferir.

Para quem está começando agora, Entity Framework oferece uma camada de mapeamento ORM - Object Relational Mapping, resolvendo a impedância entre o mundo relacional (de dados e coleções) e o mundo orientado a objetos (de tipos e classes). Enquanto isso, o LINQ - Language Integrated Query - oferece uma síntaxe de manipulação e acesso a coleções, permitindo uma navegação por dados de uma forma mais legível e aderente ao modelo orientado a objeto.

Quando vemos um código acessando uma base de dados via LINQ to SQL, por exemplo, temos algo assim:

A partir de um contexto de conexão, instanciamos uma classe de mapeamento da tabela People (do banco de dados mapeado) e fazemos nossa consulta através de uma coleção, dada pelo objeto query. Veja que o tipo utilizado é "var", um tipo anônimo que permite esse tratamento de coleções no LINQ.

Assim também, o mesmo acesso utilizando LINQ to Entity sobre o ADO.NET Entity Framework ficaria assim:

No exemplo acima, a instância da tabela People é feita através do objeto ObjectQuery, que acessa a pilha de mapeamento do Entity Framework. Só para lembrar, quando falamos em LINQ to SQL, estamos somente sobre SQL Server da Microsoft. Quando falamos em LINQ to Entity, estamos sobre qualquer banco mapeado pelo Entity Framework.

A boa notícia, anunciada no último TechEd em Orlando, é que novos providers para múltiplos bancos estão saindo do forno, uma demanda que muitas empresas têm feito para o uso do Entity Framework. Vejamos:

a Core Lab foi a primeira empresa a oferecer um ADO.NET provider com suporte para o Entity Framework Beta 3, ainda com conectividade para o SQLite, Oracle, MySQL e PostgreSQL. Veja mais aqui:
Ref.: http://crlab.com/news/2007/directs430.html
a IBM anunciou recentemente seus providers para Entity Framework, permitindo a conectividade com DB2, IDS e U2, trabalhando também com o DB2 Express-C 9.5. Veja mais aqui:
Ref.: http://www-128.ibm.com/developerworks/forums/thread.jspa?threadID=203893
a Npgsql já oferece o beta 4 de seu provider .NET Data Provider para bancos de dados Postgresql, confira:
Ref.: http://pgfoundry.org/forum/forum.php?forum_id=1307
Reggie Burnett, o lead developer do provider para MySQL, o MySQL ADO.NET provider, anunciou que em breve, a versão 5.3 do produto irá suportar a tecnologia Entity Framework.
Finalmente, a DataDirect anunciou que irá disponibilizar já em Q3 de 2008, um novo release de seu Oracle ADO.NET provider, suportando o Entity Framework para acesso aos bancos de dados Oracle.
Ainda para o mundo Oracle vale um destaque: diversas empresas estão atualizando seus providers para o suporte ao Entity Framework e acesso aos bancos de dados Oracle. É o caso da Core Lab, da OpenLink Software e agora a DataDirect Technologies.

Com o lançamento desses providers, será possível implementar estruturas de navegação LINQ com qualquer tipo de banco de dados, ampliando a flexibilidade de acesso de nossas soluções. Um sonho se tornando realidade!

Por enquanto é só! Até o próximo post :)

Waldemir.

Entity Framework FAQ : atualizado e com novas questões.

wcamb — Sat, 17 May 2008 01:05:00 GMT

Olá pessoal, tudo certo?

Para quem anda acompanhando a evolução do Entity Framework, componente importante da próxima versão do ADO.NET, o FAQ de Danny Simmons foi atualizado esta semana e está mais rico do que nunca... :)

Entity Framework FAQ
Version 0.4 – 5/13/2008
Ref.: http://blogs.msdn.com/dsimmons/pages/entity-framework-faq.aspx

Aqui no blog, já tivemos alguns posts falando sobre camadas de persistência, LINQ e EF. Veja:

Revisitando a Persistência - LINQ, Entity Framework, Object-relational mapping, entre outros.
Ref.: http://blogs.msdn.com/wcamb/archive/2008/03/20/revisitando-a-persist-ncia-linq-entity-framework-ado-entity-framework-entre-outros.aspx

Revisitando a Persistência - ORM, ADO.NET Entity Framework, Data Services, Sync, LINQ e ainda outros comentários.
Ref.: http://blogs.msdn.com/wcamb/archive/2008/03/26/revisitando-a-persist-ncia-orm-ado-net-entity-framework-data-services-sync-linq-e-ainda-outros-coment-rios.aspx

Estou preparando um novo material para avançar no assunto e em breve compartilho com vocês algumas soluções. Aguardem...

E não deixem de visitar também a página do projeto EF no CodePlex, veja:

Entity Framework Contrib project
Ref.: http://www.codeplex.com/efcontrib

Por enquanto é só! Até o próximo post :)

Waldemir.

Do Windows DNA para o mundo orientado a serviços : uma proposta para estudo.

wcamb — Fri, 18 Apr 2008 14:17:00 GMT

Olá pessoal, tudo certo?

No último post, começamos nosso papo sobre evolução de uma arquitetura WinDNA para uma plataforma mais atual. Vimos que antes de tudo, precisamos ter uma visão clara sobre os cenários envolvidos, assim como conhecer as novas tecnologias oferecidas pelo mercado. Nesse aspecto, novos frameworks estão disponíveis na plataforma Microsoft e cabe a nós, arquitetos, conhecê-los e exercitá-los, afim de melhor decidir sobre cada alternativa de evolução para nossas aplicações.

Considerando a disposição de componentes na plataforma WinDNA, podemos estudar uma alternativa de solução, conforme a figura a seguir:

Camada de apresentação : ASP.NET com Microsoft AJAX versão 1.0 e Silverlight 2.0.

Para uma aplicação tipicamente Web, a construção de uma interface rica (RIA - Rich Internet Application), que traga as funcionalidades e recursos da Web 2.0 é recomendável. E sobre recursos pensamos não somente em wikis, fóruns, webparts, controles gráficos, streaming, etc, mas também em novas abordagens de apresentação e UX - User Experience. Pensando ainda na composição de serviços e workflows, conceitos de aplicações compostas ou mashups também é uma capacidade que deve ser avaliada para nossa arquitetura.

Nesse ponto, a infra-estrutura ASP.NET com AJAX e Silverlight 2.0 oferece essa gama de recursos para a construção de interfaces poderosas em .NET. Claro, devemos avaliar qual a aderência de nossa aplicação para todas essas inovações. Mas os novos recursos de administração do IIS 7.0 devem ser avaliados, independente do grau de ousadia de nossa nova interface. O IIS 7.0 seria nossa infra-estrutura de suporte às páginas e requisições HTTP/HTTPS, etc. sobre o Windows Server 2008.

Para saber mais sobre o IIS 7.0 e esses recursos, não deixe de ver a série especial sobre o produto no blog do Danilo Bordini, onde temos:

IIS 7.0 (Internet Information Services): Parte 7: Delegação
IIS 7.0 (Internet Information Services): Parte 6: Configuração
IIS 7.0 (Internet Information Services): Parte 5: Extensibilidade
IIS 7.0 (Internet Information Services): Parte 4: Segurança
IIS 7.0 (Internet Information Services): Parte 3: Pilares
IIS 7.0 (Internet Information Services): Parte 2: Evolução da Plataforma
Série Especial - IIS 7.0 (Internet Information Services)

Ref.: http://blogs.technet.com/dbordini/archive/tags/Internet+Information+Services+_2800_IIS_2900_/default.aspx

e para saber mais sobre o Silverlight 2.0 e o AJAX 1.0, veja os links:

Ref.: http://silverlight.net/

Ref.: http://www.asp.net/ajax/

E sempre é bom acompanhar como está a evolução do modelo ASP.NET MVC Framework, ainda em Preview 2 (Model-View-Controller). Veja aqui:

Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyID=38CC4CF1-773A-47E1-8125-BA3369BF54A3&displaylang=en

Camada de colaboração de processos : Windows Workflow Foundation (.NET 3.5)

Em alguns cenários, podemos pensar na implementação de processos de negócio através de fluxos de controle ou mesmo máquinas de estado. Quando falamos em fluxos de controle (ou workflows), pensamos num cenário onde a execução de atividades é sequencial, a partir de eventos que são tratados numa ordem esperada. Temos uma atividade inicial e uma atividade final bem definida. Quando falamos em máquinas de estado, a execução das atividades é orientada por eventos, que podem ocorrer numa ordem aleatória. Assim, nosso desenvolvimento é baseado no estado corrente, com transições por eventos, sendo mais flexível para mudanças externas.

A implementação de um processo de negócio através de um workflow ou máquina de estados pode ser feita através do WF - Windows Workflow Foundation. Como vimos em posts anteriores, podemos ainda integrar esses processos com serviços do WCF - Windows Communication Foundation, ou ainda outros processos de negócio.

Finalmente, lembre-se que um processo pode ter interação humana para aprovações ou submissões, o que pode caracterizar execuções de longa duração. A interação de serviços ou outras camadas com esse tipo de processo precisa ser bem pensada e sinalizada para toda a arquitetura.

Algumas perguntas: Quais são os processo de longa duração e de curta duração presentes em nossa arquitetura? Podemos implementar parte da lógica e regras de negócio em processos com WF?

Para saber mais sobre WF e processos, veja:

Ref.: http://msdn2.microsoft.com/en-us/netframework/aa663322.aspx

Camada de serviços e negócicos : Windows Communication Foundation e serviços hosteados no WAS - Windows Process Activation Service

Surge então a discussão sobre a camada de serviços. O que é mesmo um serviço? :)

Podemos pensar na implementação de classes de negócio, com suas business entities e business process, utilizando a infra-estrutura do WCF para sua exportação e publicação de interfaces. Quando surge o WCF em nossa arquitetura, precisamos discutir alguns pontos importantes:

Qual será o template de serviço que usaremos? Nesse template, precisamos considerar o tratamento de exceção, a propagação de mensagens de erro, exportação de contadores de performance, e também aspectos de comportamento do serviço, contrato de dados, suporte transacional, mensagens tratadas, etc.

Qual será o transporte tratado pelo serviço? A definição do binding (para nosso endpoint) é tão importante quanto a definição do próprio serviço. Através do binding correto, garantimos a melhor performance para a interação entre camadas, processos e serviços.

Qual será o host para execução de serviços? Aqui, surge o WAS, já comentado em posts anteriores. Veja:

Windows Process Activation Service (WAS) - Um mecanismo de ativação de processos e serviços.
Ref.: http://blogs.msdn.com/wcamb/archive/2008/04/10/windows-process-activation-service-was-um-mecanismo-de-ativa-o-de-processos-e-servi-os.aspx

A importância da definição do host está associada ao processo de execução, mas também de administração, governança, distribuição e monitoração dos serviços em nossa arquitetura. Sem dúvida, cuidado muito especial é exigido.

Camada de negócio e aplicações LOB : COM+ 1.5 e MSDTC

Um ponto importante nessa arquitetura para estudo é que ainda podemos conviver com componente publicados no COM+, isto é, componentes COM que estão hosteados no Component Services (veja comexp.msc) e ainda aproveitam o MSDTC - Distributed Transaction Coordinator para o suporte transacional. Esses componente podem e devem permanecer em nossa arquitetura. Isso significa que é possível conviver com esse legado, seja através de camadas de interoperabilidade (interop .NET) ou simplemente consumindo esses componentes através de Web Services. Para alguns casos, teremos traduções entre ambiente gerenciado .NET e não-gerenciado, o que deve causar um certo delay, que deve ser avaliado.

A questão sempre será sobre a viabilidade (de custo, recursos e tempo) para a migração desses componentes (COM+ WinDNA) para .NET.

Camada de acesso a dados e LOB : bancos de dados legado e aplicações LOB

E para o acesso aos dados temos algumas alternativas, como:

ADO.NET 2.0, quando usamos o .NET 2.0 e seus recursos como Dataset, DataReader, Datatable, DataAdapter, DbConnection, DbCommand, etc.;
LINQ TO SQL, quando usamos .NET 3.5 e estamos falando com servidores da família SQL Server;
LINQ TO ENTITY, quando usamos ADO.NET Entity Framework (ainda em Beta 3), para falar com outros servidores de bancos de dados, através do providers oferecidos no mercado.

Já falamos sobre LINQ e Entity Framework em alguns posts anteriores, veja aqui:

Ref.: http://blogs.msdn.com/wcamb/archive/tags/LINQ/default.aspx

A decisão entre as tecnologias de acesso a dados e camadas de persistência acima vai depender da orientação do projeto, entre a especialização para um middleware de alto desempenho, focado num único banco, ou um middleware de abstração e mapeamento, que permitirá trocas futuras de bancos de dados sem impacto na aplicação, porém, com um custo de mapeamento de traduções que deve ser avaliado quanto a performance.

Mais uma vez, é importante lembrar que cada caso é um caso, sempre!

A estrutura em camadas acima foi colocada apenas como pretexto para a discussão dos frameworks e tecnologias disponíveis. Caberá a cada equipe de arquitetura avaliar internamente a aderência às suas próprias aplicações.

Porém, tenha em mente que sua nova plataforma precisa estar antenada com as tendências de colaboração e integração de Software + Serviços que temos observado.

Construir preparado para a mudança, já que tudo se move, tudo flui, é uma prática cada vez mais desejada, já dizia Heráclito de Éfeso, uns 500 a.C. :) Panta hrei!

Por enquanto é só! Até o próximo post :)

Waldemir.

Revisitando a Persistência - ORM, ADO.NET Entity Framework, Data Services, Sync, LINQ e ainda outros comentários.

wcamb — Thu, 27 Mar 2008 02:25:00 GMT

Olá pessoal, tudo certo?

No último post, começamos uma discussão interessante sobre persistência. Vamos rever alguns pontos e avançar mais um pouquinho. A motivação do estudo é uma só: como e por que integrar a modelagem e programação Orientada a Objetos com Bancos de Dados Relacional?

De fato, a maior parte de nossas aplicações usam um banco relacional para armazenamento de dados. Como vimos, essa tecnologia é vigente no mercado, por sua maturidade, fundamentação em uma teoria matemática forte (baseada em conjuntos) e padronização. Veja que, quando usamos o modelo relacional, o objetivo é a normalização e a otimização de recursos no armazenamento de nossos dados ou coleções;

Da mesma forma, a maior parte de nossas aplicações usam linguagens de programação orientada a objetos em seu desenvolvimento. Com isso, nosso objetivo é a modelagem de processos, como a definição de comportamentos e tipos de entidades na forma de classes;

Surge assim um problema chamado "Impedance Mismatch", que é a dificuldade em realizar o mapeamento entre os dois mundos, o mundo relacional e o mundo OO.

Para esse problema, uma solução é o uso de uma camada de tradução ou ORM - Object Relational Mapping, que é responsável por esse mapeamento entre o mundo OO e o mundo relacional. Pense que o grande desejo é que essa camada de mapeamento ORM seja transparente para nossas aplicações.

Existe uma série de ferramentas no mercado que oferecem soluções implementando camadas ORM e seus recursos. Veja que a técnica de mapeamento objeto-relacional ainda precisa resolver alguns problemas de mapeamento e representação de dados entre ambos os mundos, problemas como:

Mapeamento entre Entidade e Classe (queries X tipos)
Herança
Tratamento de Chaves (primárias, extrangeiras)
Representação de Relacionamentos
Campos Calculados
Diferenças entre tipos SQL e linguagens de programação
Locking e Isolation Level
Tunning
Caching, entre outros.

De fato, existe um impacto em banco de dados durante a implementação desses modelos ORM. Para a implementação de herança, por exemplo, temos técnicas de mapeamento horizontal, mapeamento vertical, mapeamento filtrado, que implementam abordagens diferentes para a representação da herança entre classes, através de 1 ou mais tabelas em banco.

No final, a própria decisão pelo uso de uma camada de mapeamento objeto-relacional deve ser ponderada em função de um conjunto de critérios (pessoais), como:

Desempenho final exigido (SLA envolvido na solução);
Frequência de Leitura x Escrita x Atualização;
Flexibilidade e Custo de Manutenção;
Desempenho e Redundância x Custo de Manutenção e Formas Normais;
Consumo de Espaço x Desempenho;
Tempo de Processamento de Consultas;
Estilo da Aplicação;
Integração com sistemas legados, etc.

Atualmente, temos uma série de novos frameworks disponíveis para o tratamento de acesso a dados, assim como para a construção de consultas integradas ao modelo orientado a objetos. É o caso do próprio ADO.NET Entity Framework e do LINQ, como citamos anteriormente. Porém, já existem muito outros componentes disponíveis, que você precisa conhecer. Para ajudar um pouco nesse roadmap, segue um conjunto de links interessante:

ADO.NET 2.0
Nosso ADO.NET clássico, onde encontramos as estruturas Dataset, DataReader, Datatable, DataAdapter, DbConnection, DbCommand, etc.
Ref.: http://msdn2.microsoft.com/en-us/data/aa937722.aspx

ADO.NET 3.5
Disponível com o .NET Framework 3.5, onde encontramos as versões de LINQ to Objects, LINQ to DataSets, LINQ to SQL, LINQ to XML, enfim, as implementações de LINQ - Language Integrated Quey, que permite a construção de consultas integradas ao modelo OO, para o acesso aos dados no mundo relacional ou ainda qualquer outra fonte de dados, como arquivos XML, estruturas customizadas, etc. Em linhas gerais, LINQ implementa um conjunto de mecanismos e bibliotecas para consultas de dados em memória, através de coleções.
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyID=333325fd-ae52-4e35-b531-508d977d32a6&DisplayLang=en

ADO.NET vNext
A próxima versão do ADO.NET deve encapsular um conjunto de novas ferramentas, que já estão sendo disponibilizadas em CTP e Previews para nossa discussão e alegria. Os principais componentes que já temos são:

ADO.NET Entity Framework Beta 3
Responsável pelo mapeamento objeto-relacional, através do chamado EDM - Entity Data Model. Esse modelo permite o mapeamento de classe objeto em qualquer tipo de fonte de dados (não só o modelo relacional) através de um processo de tradução implementado em 3 camadas: camada conceitual, camada lógica e camada de mapeamento. A documentação que acompanha o pacote está muito boa, vale conferir.
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=15DB9989-1621-444D-9B18-D1A04A21B519&displaylang=en

ADO.NET Data Services (codenome “Astoria”) => download do ASP.NET 3.5 Extensions Preview, onde temos o ASP.NET 3.5 + ADO.NET Data Services.
Permiti a publicação e navegação das informações de um banco de dados de forma online.
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=A9C6BC06-B894-4B11-8300-35BD2F8FC908&displaylang=en

Um exemplo muito interessante de navegação via Data Services você encontra aqui.Veja que nosso velho Northwind agora pode ser navegado diretamente através de querystrings, praticamente. As aplicações são inúmeras, como integrações para aplicações AJAX, consumo via WCF, aplicações Web convencionais, etc.
Northwind - Navegando dados online via ADO.NET Data Services
Ref.: http://astoria.mslivelabs.com/OnlineServiceNorthwind.aspx

ADO.NET Sync Services v1.0
Sync Services é uma primeira parte de um framework ainda em desenvolvimento, que deve atender as aplicações que ficam parcialmente conectadas, ou seja, que demandam o uso de um cache local em tempos de desconexão, com a necessidade de uma sincronização de dados posterior com o servidor. Esses mecanismos e estruturas de persistências temporárias são o objetivo do Sync Services.

Recomendo assistir um vídeo do channel9, nesse link:
Ref.: http://channel9.msdn.com/Showpost.aspx?postid=384948

Para saber ainda mais, acompanhe as discussões aqui:
Ref.: http://www.danielmoth.com/Blog/2008/02/adonet-sync-services.html

Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=75FEF59F-1B5E-49BC-A21A-9EF4F34DE6FC&displaylang=en (sync for devices)
Ref.: http://www.microsoft.com/downloads/details.aspx?&FamilyID=7849b34f-67ab-481f-a5a5-4990597b0297&DisplayLang=en (sync for desktop)

Finalmente, outros projetos que estão também no forno são o Microsoft ASP.NET MVC Framework e o SubSonic.

O Microsoft ASP.NET MVC Framework habilita o desenvolvimento de aplicações Web no modelo MVC - Model View Controller. Nesse modelo, a lógica da página fica na porção CONTROLLER, os objetos de HTML ficam no módulo VIEW e a lógica da aplicação fica na porção MODEL. Não está muito relacionado com o acesso a dados, mas colabora! :)

ASP.NET MVC Preview 2
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyID=38CC4CF1-773A-47E1-8125-BA3369BF54A3&displaylang=en

O SubSonic Project, conduzido por Rob Conery, é um conjunto de ferramentas que deve gerar de forma completa a camada de acesso a dados. Ao contrário do modelo ORM, onde temos o mapeamento do mundo OO no mundo relacional, SubSonic será um gerador de código ou do modelo de classes OO, a partir do schema do banco relacional. Bonito! :)

Para saber mais, acompanhe as discussões no Codeplex, aqui:

SubSonic Codeplex
Ref.: http://www.codeplex.com/subsonic

SubSonic: 2.1 Beta 2 Available Now
Ref.: http://www.codeplex.com/subsonic/Release/ProjectReleases.aspx?ReleaseId=5636

Enfim, Vida Longa ao Blog!!!
Acho que não vai faltar assunto para os próximos meses, não acham?

Por enquanto é só! Até o próximo post e boa leitura a todos... :)

Waldemir.

Revisitando a Persistência - LINQ, Entity Framework, Object-relational mapping, entre outros.

wcamb — Thu, 20 Mar 2008 22:40:00 GMT

Olá pessoal, tudo certo?

Falar de LINQ e persistência de dados é mesmo desafiador? Estive navegando pela Web e existem diversos blogs, artigos, whitepapers, pdf's, ppt's, wikis e exemplos que realmente deixam o leitor confuso. E algumas perguntas ainda aparecem no meio da discussão, como: "usando LINQ, onde é melhor colocar minha lógica de negócio, em banco de dados ou em componentes extra banco?" ou ainda "para toda arquitetura devo utilizar um modelo de persistência e mapeamento relacional?" e outras como "Qual a diferença entre LINQ, XPO, SubSonic, Ibatis, Nhibernate ou algo doméstico?".

Bom, este post não pretende esgotar o assunto, mas colocar uma rápida visão sobre o tema, com um foco sobre o ADO.NET Entity Framework e seus componentes. Para começar, vamos rever algumas definições.

Revisitando a persistência

Quando falamos em persistência de dados pensamos no armazenamento "eterno" dos dados, ou seja, enquanto o dispositivo físico de armazenamento dure. Quando se grava um arquivo no disco, por exemplo, o dado está sendo "eternizado" ou "persistido", deixando de ser volátil na memória RAM e passando a ser escrito num dispositivo que armazena a informação de modo que ela não desapareça facilmente.

Assim, podemos dizer que a persistência de dados envolve um meio físico que permita recuperação de dados, como um banco de dados, um arquivo em disco, etc, o que garante a persistência das informações e sua posterior recuperação. Ao longo da execução de um sistema, a persistência de dados é fator crítico, pois determina o modelo de acesso aos dados persistidos, assim como o desempenho, a facilidade de acesso, a dificuldade de manutenção, a capacidade de rastreabilidade dos dados, o modelo de programação, etc.

De modo geral, o modelo de persistência mais comum no mercado é o baseado em banco de dados relacional, onde através de SQL (Structured Query Language), fazemos a navegação pelos dados persistidos. Nossas consultas são escritas em SQL e executadas sobre o banco, para a recuperação de informações específicas. Essa tecnologia é muito madura, difundida e padroniza, porém, apresenta muitos problema de acoplamento com a orientação a objetos. Vamos considerar que a orientação a objetos hoje é o modelo de programação de sistemas dominante. Assim, quando falamos sobre persistir nossos objetos de um modelo OO, falamos da persistência de objetos, o que exige um mapeamento. De fato, a persistência de objetos utilizando um modelo relacional envolve a discussão sobre o chamado Object-Relational Mappings, ou mapeamento Objeto-Relacional.

Revisitando o mapeamento objeto-relacional (ORM - Object-relational mapping)

Como vimos, o mapeamento objeto-relacional é uma técnica que visa diminuir a chamada impedância entre o modelo de objetos e o modelo relacional em banco de dados. Existe muita discussão em torno do assunto, já que alguns aspectos de ambos os modelos são conflitantes. Algumas vezes, você vai desejar um modelo de persistência que simplesmente faça a serialização de seus objetos para armazenamento. Em cenários de longo prazo, onde versionamento dos objetos persistidos é importante, você vai precisar ainda de algum mecanismo mais sofisticado, que faça um mapeamento objeto relacional considerando a versão dos objetos envolvidos.

Mas a necessidade de se tornar transparente a persistência de dados, instâncias de objetos e informações de sistemas OO é uma constante. Frequentemente somos confrotados com a decisão sobre utilizar uma camada de persistência de nossos dados ou simplesmente manter o acoplamento de classes com estruturas relacionais de forma explícita.

Por exemplo, quando pensamos num modelo objeto-relacional, pensamos numa tabela por classe, com artibutos primitivos representados por colunas. Da mesma forma, atributos complexos são representados por múltiplas colunas ou tabelas adicionais. E todo esse mapeamento é feito de forma transparente para o sistema, isolando o desenvolvedor desses detalhes durante a codificação da lógica de negócio. Agora, algumas otimizações ainda podem ser necessárias no modelo objeto-relacional, como reduções e transformações de schemas, para eliminação de colunas redundantes, validações, verbalizações para eliminação de ambiguidades, entre outras.

Visitando o ADO.NET Entity Framework

Depois dessa introdução, vamos falar um pouco sobre o ADO.NET Entity Framework. Ele está disponível através do link abaixo:

ADO.NET Entity Framework Beta 3
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=15DB9989-1621-444D-9B18-D1A04A21B519&displaylang=en

Você ainda vai precisar de um pacote de ferramentas para trabalhar com ele, obtido aqui:

ADO.Net Entity Framework Tools Dec 07 Community Technology Preview
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=D8AE4404-8E05-41FC-94C8-C73D9E238F82&displaylang=en

De fato, o ADO.NET Entity Framework é um pacote que integra as funcionalidades do ADO.NET 2.0 (com seus mecanismos de DataSet, DataAdapter, DbConnection, DbCommand , etc), adicionando 2 novos componentes: o Entity Data Model e o LINQ - Language Integrated Query.

Veja a figura a seguir que representa bem o pacote:

De forma resumida, o Entity Framework permite o mapeamento do modelo relacional para o modelo de negócio orientado a objetos na aplicação. Assim, parte importante da arquitetura do Entity Framework são suas camadas internas: camada conceitual, camada de mapeamento e camada lógica. Essas 3 camada garantem o mapeamento ORM (Object-relational mapping) conforme discutido anteriormente:

No ambiente do Visual Studio, esse mapeamento é disponibilizado através da ferramenta Entity Model Code Generator Tool, instalada com o pacote ADO.Net Entity Framework Tools, citado acima. Veja uma figura da ferramenta em ação:

Observamos a parte inferior com o mapeamento entre colunas e propriedades das classes envolvidas no mapeamento objeto-relacional. Esse mapa é mantido pelo EDM - Entity Data Model presente na aquitetura.

Nesse contexto surge o LINQ. LINQ é um conjunto de recursos introduzidos no .NET Framework 3.5 que permite a realização de consultas diretamente em base de dados, documentos XML, estrutura de dados, coleção de objetos, etc. usando uma sintaxe parecida com a linguagem SQL. Como resultado, o desenvolvedor obtêm maior legibilidade no código final, assim como maior transparência sobre os detalhes de implementação de cada fonte de dados.

Assim, sobre o Entity Framework é possível aplicar consultas LINQ em uma de suas variações. Veja:

Alguns exemplos de variações LINQ são:

LINQ to Objects
LINQ to DataSets
LINQ to SQL
LINQ to Entities
LINQ to XML

Cada variação ainda contempla as características da fonte de dados alvo.

Um exemplo de consulta LINQ to Entities segue abaixo:

string city = “London”;
var query = from c in northwindContext.Customers
where c.City == city
select c;
foreach (Customers c in query) Console.WriteLine(c.CompanyName);

Algumas considerações

Quando devemos utilizar um modelo objeto relacional para a persistência de dados? De fato, alguns desenvolvedores e arquitetos têm iniciado o uso de camadas de persistência ORM em todas as suas soluções. Isso é um erro. Um dos grandes problemas no uso dessa camada é o desempenho final obtido. Muitas vezes, devido a presença de mecanismos de cache durante a execução das consultas e retorno de objetos, uma camada ORM pode significar um desempenho deteriorado para a aplicação. Concordamos que muitos cenários não são aderentes ao modelo ORM por serem críticos quanto ao SLA definido. Nesses casos, o mais indicado é um middleware de banco de dados de alto desempenho. Precisamos entender que existem cenários onde a fronteira entre a lógica de programação e a camada de persistência de dados simplesmente não precisa ser escondida, ao contrário, é importante estar bem definida para os componentes da arquitetura. Um exemplo semelhante ocorreu na discussão do CORBA sobre os objetos distribuídos. As estruturas internas para tornar transparente a localização de um objeto ou esconder o fato de que tínhamos uma rede entre os componentes envolvidos trouxe grande complexidade para algumas soluções, assim como um desempenho ruim em muitos cenários.

Assim, devemos avaliar bem os benefícios de uma camada de persistência objeto relacional em nossa arquitetura, de acordo com as demandas reais de negócio que a solução irá atender. Entre os aspectos que podemos utilizar nessa decisão temos:

Desempenho
Manutenabilidade
Legibilidade
Rastreabilidade de dados
Facilidade de Depuração
Escalabilidade
Presença de múltiplos bancos de dados na solução
etc.

Em posts futuros vamos conversar mais sobre o assunto. Fique ligado!

Como referências adicionais, veja os links:

Object-relational mapping
Ref.: http://www.orm.net/
ADO.NET Entity Framework & LINQ to Relational Data
Ref.: http://code.msdn.microsoft.com/adonetefx/
ADO.NET Team blog
Ref.: http://blogs.msdn.com/adonet/
Data Team blog
Ref.: http://blogs.msdn.com/data/

Por enquanto é só! Até o próximo post :)

Waldemir