Freigeben über

Desenhando Edms e criando queries dinâmicas

  • Artikel

Visitamos outro dia os arquitetos de uma empresa de ERP que estão desenvolvendo com o Entity Framework e eles nos trouxeram duas questões interessantes: 1) Como dividir edms (entity data models) quando muitas tabelas? 2) Como fazer queries dinâmicas em link?

Nossas respostas:

1) Preferimos casar edms com domínios – pense em domain driven design. Crie e descreva os cenários de negócio e coloque no edm apenas as entidades e relacionamentos que são necessárias para este cenário. Feito isto, na certa você terá entidades redundantes entre edms. Por exemplo, produto aparece nos edms relacionado a pedidos e estoque. Como lidar com isto? Algumas soluções:

a. Use views;

b. Coloque produto em outro edm e, se precisar, faça uma querie em um edm (por ex.: produtos de certa categoria) e use seu resultado numa querie no outro (ex.: where itemPedido.produto in ...);

c. Verifique se estas entidades são usadas como read-only nas queries deste domínio – isto é, são entidades auxiliares?Se sim, e caso não haja impacto na regra de negócio se houver uma edição desta entidade por outro cliente/thread, aceite a redundância;

Você sabe/usa alguma outra opção?

2) Poucos sabem, mas queries dinâmicas podem ser escritas em Linq. Isto é: é possível criar uma query e a modificarmos de acordo com a necessidade, adicionando, por exemplo, restrições em cláusulas where, etc. A maneira de fazer isto é ainda um pouco dura, mas já existem textos e projetos que ajudam. Aqui vão algumas referências:

a. O livro Programming Microsoft® LINQ (PRO-Developer) tem um capítulo só sobre o tema;

b. Dê uma olhada neste exemplo no MSDN ou neste blog ou neste;

c. Se precisar, existe um código para visitar uma expressão em linq neste blog;

d. Vi também um projeto para modificar arvores de expressão no codeplex: https://www.codeplex.com/xte . Não testei, mas creio que talvez ajude;

Boa semana

Comments

  • Anonymous
    November 16, 2008
    PingBack from http://mstechnews.info/2008/11/desenhando-edms-e-criando-queries-dinamicas/

  • Anonymous
    November 17, 2008
    Fala Otávio, Concordo que devemos pensar em DDD quando falamos da divisão do EDM. Impossível abordar todas as tabelas de um sistema complexo em apenas um EDM sem criar uma complexidade exponencial. Há relações entre objetos que devem ser abstraídas e ocultas, dependendo do contexto em que ele é utilizado ou observado. Com relação ao problema do produto que você colocou, sigo a recomendação do DDD de buscar bounded contexts, de acordo com a melhor estratégia, focando sempre no problema em questão do ponto de vista do domain expert. Eu uso muito shared kernels e customer/supplier teams, e anticorruption layers em caso de sistemas legados. Com esse tipo de análise, a questão é levada para longe da modelagem dos dados, e aproxima-se da modelagem do domínio, que é o grande objetivo do DDD. Um abraço, Giovanni Bassi http://unplugged.giggio.net

  • Anonymous
    November 18, 2008
    Olá Otávio, obrigado por suas contribuições, realmente muito relevantes. Com relação ao post, ao meu ver isso só vem mais uma vez provar a alta complexidade na modelagem de sistemas orientados a objetos utilizando uma base de dados relacional. Com a afirmação acima vem a seguinte questão: Você acredita que um dia teremos um bom sistema gerenciador de banco de dados orientado a objetos? Em caso afirmativo, esta seria a solução definitiva para problemas como o mencionado pelo seu cliente? Forte Abraço Ricardo Cunha

  • Anonymous
    November 18, 2008
    Salve, Ricardo. Vou te dar minha opinião pessoal: os clientes querem os dados no RDBMS para poder visualizá-los de várias maneiras; os desenvolvedores querem em OO para aplicar patterns e outras melhores práticas. Os BD's orientado a objetos não cumprem esta dupla função, daí a aposta atual em ORM's. Um segundo ponto: não creio que isto seja um problema do uso de ORM's. A complexidade decorre do desejo de modularização, baixo acoplamento e alta coesão. Um ORM pode ter um único edm com todas as entidades, mas isto não vai de encontro com estes desejos. Eu tinha o mesmo problema usando apenas RDBMS mas tentando uma arquitetura modular (sem OO). O que você acha?

  • Anonymous
    November 19, 2008
    The comment has been removed

  • Anonymous
    November 19, 2008
    Ricardo, Posso estar sendo simplista, mas minha impressão é a seguinte: Se o problema é pouco complexo, um ORM simplifica muito a vida. É mais simples que um DAL e ele pode ter um único edm para toda aplicação. Se é complexo, é importante que use boas práticas, como o DDD. Se o arquiteto ainda escolher a OO, então um ORM será uma boa ajuda para maximizar o reuso, etc. Neste caso, lidar com edms distintos é uma necessidade. A dúvida é o projeto de médio porte. Neste caso pode ser interessante usar outras técnicas, caso não haja conhecimento para usar um DDD/OO. Quanto à geração automática, ela é sempre bem vinda. Ela só não vai conseguir dizer qual entidade deve ficar num edm e qual não. Ainda precisamos de humanos para fazer ou aprovar decisões deste tipos (mesmo que hajam sugestões de nossas ferramentas). Portanto, não creio que possamos parar de trabalhar na melhoria dos nossos profissionais. Por fim, quantos aos gestores, creio que eles não podem ser excluídos da culpa ou sucesso de um projeto. Afinal, cabe a eles garantirem as condições para que um projeto tenha pessoal, ferramental e processos adequados. Ou não? Abraços