LUTI @ Microsoft : Entity Framework

EFUtil, IRegraNegocio e serviços para o Entity Framework

Luciano Caixeta Moreira — Wed, 03 Dec 2008 00:18:00 GMT

Muito se têm falado do Entity Framework e aqui em Brasília não é diferente, onde eu tenho trabalhado com alguns clientes, discutindo sobre a melhor forma se utilizar o EF nos projetos. Dentro das restrições de tempo (algo que está mais do que apertado ultimamente) eu juntei algumas idéias que tive e gostaria de compartilhar com vocês, um pouquinho de cada vez.

Definição do problema: a empresa R2D2 vai utilizar o Entity Framework em um novo projeto (ponto para ela!) e está montando uma arquitetura de referência. Dentre os requisitos, eles querem tentar garantir ao máximo que os desenvolvedores programem de acordo com os padrões definidos e utilizem métodos de uma interface específica (para validação de negócio) junto com o Entity Framework.

Pensando nisso, podemos criar diversas maneiras para tentar garantir ao máximo que essas regras serão seguidas, como utilização de templates, geradores de código, modificação do gerador do Entity Framework, etc. Eu resolvi usar uma abordagem mais direta, com o uso de interfaces e, alguns subterfúgios, para que sejam feitas algumas validações das entidades.

Quer ver no que deu? Continue lendo o artigo e baixe o projeto de referência, anexado a esta postagem.

Solução 01 do brainstorm
(feedbacks são mais do que bem vindos!!)

Devemos criar uma biblioteca de classes “EFUtil” com classes utilitárias que ofereçam serviços interessantes para o desenvolvedor. Dessa forma ele ficará compelido a usar os recursos disponibilizados e nós poderemos fazer alguns controles através desses métodos.

Detalhamento do projeto EFUtil

Classe PoliticasEF - Oferece métodos responsáveis pela verificação das políticas de desenvolvimento definidas pelo time de arquitetos, como por exemplo: toda entidade deve implementar a interface IRegraNegocio.

Interface IRegraNegocio - Interface que faz parte do EFUtil e define o método ValidaRegraNegocio, que deve ser implementado por toda entidade definida no modelo conceitual. Na versão 1.0 do EF precisamos usar uma interface, pois por padrão toda entidade já deriva de EntityObject. Quem sabe no futuro vamos usar uma classe abstrata e fazer com que as entidade derivem desta…

Classe ServicoContexto – Responsável por manter os métodos relacionados com os contextos do EF, como por exemplo, o método SalvarAlteracoes. Este seria responsável por chamar o método SaveChanges, fazer a validação das políticas, logging e, em caso de problemas de concorrência, aplicar a política definida para o projeto.

Partindo do que foi dito acima, para essa proposta todo desenvolvedor seria orientado para fazer o seguinte:

- Implementar a interface IRegraNegocio em uma classe parcial para todas as entidades definidas no seu modelo conceitual.
- Criar uma classe parcial para o contexto e implementar o método parcial OnContextCreated().

No exemplo que tenho, no projeto de acesso a dados “EFDataAccess”, criei um modelo edmx baseado no banco de dados SimpleDB (que somente possui a tabela funcionário) e implementei as regras definidas acima…

public partial class SimpleDBEntities
{
    partial void OnContextCreated()
    {
        EFUtil.PoliticasEF.VerificaEntidades(this);
    }
}

public partial class Funcionario: EFUtil.IRegraNegocio
{
#region IRegraNegocio Members

    public void ValidaRegraNegocio()
    {
        throw new Exception("Um erro qualquer de validação de negócio...");
    }

#endregion
}

Vamos ver agora como implementei as verificações e validações para tentar evitar que o desenvolvedor fugisse à regra…

O método VerificaEntidades analisa o espaço conceitual do modelo informado pesquisando todos os tipos “entidade” e, como estamos falando da entidade conceitual, não temos informação das interfaces que as classes parciais implementam, então precisamos usar reflexão. Dessa forma, para cada entidade recuperada, verificamos se o tipo recuperado pelo método GetType implementa a interface EFUtil.IRegraNegocio. Utilizo uma coleção de dicionário para verificar quais contextos já foram verificados, fazendo este controle através do hashcode do objeto.

public static void VerificaEntidades(ObjectContext contexto)
        {
            string nomeAssembly, nomeEntidade;
            Type tipoEntidade;
            Assembly AssemblyDA = Assembly.GetCallingAssembly();

            // Mostra o nome do Assembly - EFDataAccess neste caso
            nomeAssembly = AssemblyDA.GetName().Name;

            var entidades = from e in contexto.MetadataWorkspace.GetItems(System.Data.Metadata.Edm.DataSpace.CSpace)
                            where e.BuiltInTypeKind == System.Data.Metadata.Edm.BuiltInTypeKind.EntityType
                            select e;

            foreach (var e in entidades)
            {
                // Recupera o nome da entidade listada, ignorando o namespace do modelo conceitual, que normalmente é
                // diferente do namespace definido no assembly
                nomeEntidade = e.ToString().Split('.')[1];

                tipoEntidade = AssemblyDA.GetType(nomeAssembly + "." + nomeEntidade, true);
                if (tipoEntidade.GetInterface("EFUtil.IRegraNegocio") == null)
                    throw new Exception("Entidade '" + nomeEntidade + "' não está implementando a interface EFUtil.IRegraNegocio");
            }

objetosVerificados.Add(contexto.GetHashCode(), DateTime.Now);
}

Obs 1: É necessário compormos o nome do tipo conforme exibido, porque o namespace do modelo conceitual é diferente do namespace primitivo do assembly, que por padrão é o nome do projeto. Por simplicidade eu estou considerando namespaces no formato namespace.entidade, mas é claro que isso pode ser diferente e deverá ser tratado de forma genérica, recuperando o último nome após o “.”.

Obs 2: Como estamos chamando o método VerificaEntidades através de uma classe parcial, é obrigatório que essa classe esteja na mesma DLL que o modelo, então eu posso assumir que o GetCallingAssembly está sempre se referindo ao módulo correto.

Para tentar aumentar a segurança e evitar que um desenvolvedor tente usufruir dos serviços disponibilizados pela classe ServicoContexto sem chamar o VerificaEntidades, no início do método SalvarAlteracoes() é feito uma validação, que pesquisa no dicionário se o objeto deste contexto já foi verificado.

internal static void JaFoiVerificado(ObjectContext contexto)
        {
            if (!objetosVerificados.ContainsKey(contexto.GetHashCode()))
                throw new Exception("A validação do contexto não foi feita, verifique se existe uma classe parcial " +
                "do contexto implementando o seguinte trecho de código: \n" +
                "partial void OnContextCreated() { \n" +
                "EFUtil.PoliticasEF.VerificaEntidades(this); \n" +
                "}");
        }

É também no SalvarAlteracoes que as regras de negócio de cada entidade são invocadas, de acordo com o código abaixo (note que por simplicidade eu somente estou verificando os itens que foram adicionados):

private static void ValidaRegras(ObjectContext contexto)
{
    foreach (ObjectStateEntry item in contexto.ObjectStateManager.GetObjectStateEntries(EntityState.Added))
    {
        IRegraNegocio entidade = (IRegraNegocio)item.Entity;
        entidade.ValidaRegraNegocio();
    }
}

Conclusão e considerações

Com o exemplo acima eu não espero ter resolvido essa questão, muito pelo contrário, espero que essa postagem seja o início de uma discussão produtiva. Gostaria de fazer algumas considerações sobre o que foi codificado:

Se o desenvolvedor utilizar o método SalvarAlteracoes sem ter implementado corretamente o método parcial OnContextCreated, o JaFoiVerificado pega o problema.
Se o desenvolvedor implementar corretamente a classe parcial do contexto, mas esquecer de implementar em alguma entidade a interface IRegraNegocio, o problema será detectado pelo VerificaEntidades.
Se o desenvolvedor não implementar a interface e chamar o SaveChanges do contexto diretamente, não podemos fazer nada (com essa abordagem).
- Comentando a interface e o método que chama o VerificaEntidades, vocês podem simular os cenário acima.
Fazer a validação da regras auxiliares (e até poder chamar outros métodos) em toda instância pode parecer um desperdício, mas talvez seja possível parametrizar algumas coisas e até criar novas sobrecargas para os construtores do contexto, que pode trazer uma flexibilidade interessante se pensarmos na configuração do contexto em subsistemas específicos.

Pessoal, notem que eu não quero com esse post entrar em detalhes qual a melhor arquitetura para sua aplicação, aonde é melhor colocar sua regra de negócio ou outra afirmação do tipo. Estou apenas mostrando algumas maneiras de como podemos utilizar o Entity Framework, que espero eu, possa ajudá-los no dia-a-dia.

Em anexo está tudo o que foi codificado, além de um outro modelo do northwind com mais entidades. Espero que vocês testem o projeto e tudo funcione corretamente, pois estou esperando o feedback de vocês. :-)
Em breve voltarei com adendos e este projeto, como controle de concorrência e logging…

[]s
Luciano Caixeta Moreira
luciano.moreira@microsoft.com
===============================================
This post is provided "AS IS" and confers no right
===============================================

Roadmap para o Linq to SQL e Linq to Entities

Luciano Caixeta Moreira — Fri, 31 Oct 2008 02:59:40 GMT

Bom, já têm um tempinho que nós vemos um enfoque maior no Entity Framework que no Linq to SQL, mas o que será que os times de produto estavam pensando? Ontem tivemos um anúncio importante feito pelo Tim Mallalieu (http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx). O trecho mais importante é:

"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. 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."

Got it? :-)

Webcast da semana: Entity Framework

Luciano Caixeta Moreira — Mon, 27 Oct 2008 20:51:00 GMT

Nessa semana temos mais um encontro nos webcast do MSDN, onde eu volto a falar sobre o Entity Framework.

Sessão: Utilizando na prática recursos do Entity Framework v1
Descrição: O Entity Framework é parte fundamental da estratégia de acesso a dados e um dos frameworks da Microsoft que mais recebe atenção, sendo necessário entendermos como é possível utilizar da melhor forma o EF v1. Nessa sessão iremos ver como utilizar na prática diversos recursos do Entity Framework, como: serialização de entidades utilizando o WCF, controle de concorrência, como adicionar lógica de negócio (na entidade ou na camada de negócio), como manipular o gerenciador de estados, auto-relacionamento e chaves compostas, além de abstrair a utilização de diferentes bancos de dados.
Data/hora: quarta-feira, 29 de outubro de 2008 12:00 Brasília
URL: https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032394175&EventCategory=4&culture=pt-BR&CountryCode=BR

Nos vemos na quarta-feira!

Entity Framework + SQL Server 2008 + MySQL 5.0

Luciano Caixeta Moreira — Fri, 05 Sep 2008 16:34:00 GMT

function showDiv(post, lingua) { if (document.getElementById) { // DOM3 = IE5, NS6 document.getElementById(post + lingua).style.display = 'block'; document.getElementById(post + ((lingua == 'P')? 'E' : 'P')).style.display = 'none'; //alert(post + ((lingua...(read more)

Propriedades Read-Only no Entity Framework

Luciano Caixeta Moreira — Fri, 04 Apr 2008 13:46:00 GMT

Recentemente tenho recebido vários e-mails sobre o entity framework, o que é ótimo, pois me força a estudar ainda mais a tecnologia e passo a conhecer problemas reais que os profissionais espalhados pelo Brasil estão passando. Então vamos a um post rápido...

Como eu crio propriedades somente para leitura no EF?

Se notarmos no designer do seu modelo EDM, quando você clica sobre uma propriedade da entidade, você pode ver que existem duas configurações de code generation (setter e getter), mas essas não estão habilitadas para edição (provavelmente isso será efetivo no próximo beta, sei lá). Então temos que recorrer ao velho e bom XML para nos ajudar.

Abra o seu arquivo edmx com o editor XML, encontre a propriedade que quer alterar e quando digitar “a:”, conte com a ajuda do intellisense para definir a visibilidade dos métodos de acesso (propriedades no .NET), onde poderá escolher entre public, internal e private. Exemplo:

Nesse caso, como a visibilidade está como private, somente outros métodos da própria classe podem acessar a propriedade. Você também pode definir o acesso como internal, para possibilitar o acesso de outras classes dentro do mesmo assembly. O importante aqui é notar que não tendo acesso ao método Set, a propriedade da entidade passa a ser somente leitura para quem está manipulando o objeto.

[]s

Luciano Caixeta Moreira

luciano.moreira@microsoft.com

=============================================================

This posting is provided "AS IS" with no warranties, and confers no rights

=============================================================

Webcast quarta-feira - ADO.NET Entity Framework (Recursos Avançados)

Luciano Caixeta Moreira — Mon, 03 Mar 2008 23:10:00 GMT

Nesta quarta-feira (05/03/2008), dia de webcasts sobre banco de dados e tecnologias de acesso a dados no MSDN Brasil, eu estou novamente escalado para falar com vocês novamente sobre o Entity Framework. Para quem ainda não conhece o distinto, recomendo assistir a gravação do webcast de introdução do assunto (http://blogs.msdn.com/luti/archive/2007/12/17/webcast-do-m-s-ado-net-entity-framework.aspx).

Entendam por recursos avançados outras capacidades que o EF oferece e não foram abordadas no nosso primeiro encontro, nada de debugging nível 400, então não precisam pirar. Para mais informações sobre o evento, acessem o link abaixo:

https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032370683&EventCategory=4&culture=pt-BR&CountryCode=BR

Fiquem ligados no Entity Framework, pois ele ainda vai dar o que falar! Espero vocês na quarta-feira.

[]s

Luciano Caixeta Moreira

luciano.moreira@microsoft.com

=============================================================

This posting is provided "AS IS" with no warranties, and confers no rights

=============================================================

[PostMortem] Entity Framework – Errata e dúvidas

Luciano Caixeta Moreira — Thu, 27 Dec 2007 21:50:00 GMT

Bom dia! Recentemente eu gravei um webcast sobre o Entity Framework e no final da sessão houve um painel de perguntas e respostas, então vou aproveitar outras perguntas que eu recebi e escrever um rápido Q&A.

P: Se a estrutura do banco mudar, existe uma forma de atualizar automaticamente o modelo?

R: A partir do CTP2 do Entity Designer (que acompanha o Beta 3 do EF) é possível atualizar tanto o modelo conceitual (atualizando também o modelo físico), como é possível atualizar somente o modelo físico e depois criar manualmente as novas entidades e os mapeamentos.

Errata: no webcast eu não respondi corretamente essa pergunta! Eu ainda não havia utilizado essa funcionalidade e a novidade me escapou, pois me lembrei das funcionalidades do EF Beta 3 e não do ED CTP2. Vide os anúncios no fim deste post.

Para compensar essa pequena falha, no próximo ano eu vou escrever um post detalhando essa funcionalidade. J

P: Existe suporte a transações no ADO Entity? Isso é feito implicitamente, por exemplo, quando usamos a função para salvar as alterações (é feito atomicamente?), ou devemos explicitamente informar isso ao Framework?

R: Quando você chama o método SaveChanges(), o Entity Framework automaticamente inicia uma transação e faz o commit depois que as alterações foram executadas. Você pode analisar esse comportamento utilizando o Profiler e capturando alguns eventos relacionados às transações. Se desejar, também pode controlar a transação da maneira que quiser, pois através da classe de entidades (gerada pelo EDM) você tem acesso a um objeto do tipo DbConnection. Exemplo:

AWorksModel.AWorksEntities entidades = new AWorksModel.AWorksEntities();

entidades.Connection.BeginTransaction(IsolationLevel.Serializable);

P: Hoje o ADO.NET Entity Framework Beta 3 dá suporte p/ Oracle? Caso isto seja possível, ele gera o modelo baseado no banco de dados, assim como é feito no SQL Server?

R: Se você quiser brincar hoje com o EF junto ao Oracle, infelizmente não é possível. Mas já foi anunciado uma série de providers que estarão disponíveis em breve. Para mais informações, veja esse artigo: http://blogs.msdn.com/adonet/archive/2007/12/17/the-ado-net-entity-framework-not-just-for-sql-server.aspx

Não existe um exato detalhamento do que o provider vai suportar ou não, mas provavelmente a funcionalidade básica de gerar o modelo (como é feito com o SQL Server) estará disponível. Fica aqui uma dúvida, não sei se existe uma quantidade mínima de requisitos que um provider deve atender para funcionar com o EF (ou deve implementar tudo?), vou descobrir e depois coloco isso aqui.

Para informações do lançamento do EF Beta 3 e ED CTP 2, acesse:

http://blogs.msdn.com/adonet/archive/2007/12/05/ado-net-entity-framework-beta-3-rleased.aspx

http://blogs.msdn.com/adonet/archive/2007/12/06/entity-designer-ctp2.aspx

[]s

Luciano Caixeta Moreira

luciano.moreira@microsoft.com

=============================================================

This posting is provided "AS IS" with no warranties, and confers no rights

=============================================================