Construindo camadas de acesso a dados – Parte V – Unity of Work

O padrão Unit of Work mantém um rastreamento sobre todas as alterações que possam alterar sua fonte de dados durante uma transação. Assim, quando todas as alterações já tiverem sido executadas o padrão fica responsável por persistir todas na fonte de dados.

Geralmente, não somos responsáveis por implementar este padrão, acabamos por consumi-lo em ferramentas de persistência, como: Entity Framework, NHibernate e LINQ to SQL.

Saiba mais

About these ads

Vídeo/Palestra – Patterns para criação de camadas de acesso a dados

Olá,

Foi publicado o vídeo da minha palestra no Visual Studio Summit 2013. O tema da palestra foi: “Patterns para criação de camadas de acesso a dados”.

Saiba mais

Visual Studio Summit 2013: Patterns para criação de camadas de acesso a dados

Olá!

No último sábado (25/05/2013) tive a honra de participar do Visual Studio Summit 2013.

Participei da edição de 2012 com o tema “Principais novidades do Entity Framework 5″ (http://ferhenriquef.com/2012/09/24/visual-studio-summit-2012-principais-novidades-do-entity-framework-5-0/).

Este ano apresentei um conteúdo mais próximo aos tópicos de arquitetura e modelagem de software, falei sobre o tema “Patterns para criação de camadas de acesso a dados”.

Saiba mais

Construindo camadas de acesso a dados – Parte IV – Padrão “Find or Create”

Continuando a série de posts sobre camadas de acesso a dados (se vc não sabe do que estou falando clique aqui: Camadas de Acesso a Dados). Existe um padrão que comumente utilizamos e que não fazemos ideia de que este realmente é um padrão documentado e utilizado por muitos, este é o padrão “Find or Create”.

Este padrão consiste da característica de: buscar um determinado dado na fonte de dados e, se o mesmo não for encontrado, então fazer a sua inclusão. Pode parecer simples, mas é um recurso bastante comum que utilizamos no nosso dia.

Saiba mais

Construindo camadas de acesso a dados – Parte II – Identity Field

Dentro dos diferentes patterns de criação de camadas de acesso dados alguns deles não estão diretamente associados à construção de nossos repositórios, mas estão associados com a adequação da estrutura de nossas entidades a um determinado objetivo.

Este post é sobre um pattern chamado Identity Field.

O padrão Identity Field instrui a utilização de uma propriedade que funcione como chave de identificação de cada entidade das demais, independente do seu tipo de dados, tabela na qual estão salvos ou estrutura.

O objetvo desta chave de identificação é basicamente funcionar como identificador global, que ao contrário dos valores de campos que são chaves primárias (que geralmente são baseados em tipos inteiros, auto-incrementais e que podem se repetir em outras tabelas), agregue uma identificação única daquela tupla no banco de dados e no sistema.

Saiba mais

Um modelo arquitetural…

Nos últimos tempos tenho recebido algumas perguntas de como modelo meus projetos, quais design patterns utilizo e como divido minha aplicação em camadas. Estas perguntas possuem apenas uma resposta: depende do caso.

Cada aplicação merece um modelo arquitetural diferente do outro. Cada aplicação exige diferentes design patterns. Cada aplicação funciona de um jeito. Nenhuma aplicação é igual a outra, assim como os dedos das mãos não são iguais.

Mas, como esta pergunta não possui uma resposta certa ou errada, gostaria de demonstrar um modelo arquitetural que me agrada bastante. Este modelo mescla alguns design patterns e alguns princípios de projetos orientados a objetos. A arquitetura da aplicação é a demonstrada abaixo.

architecture

Saiba mais

Padrão Bom Cidadão (Good Citizen Pattern)

Olá,

Faz algum tempo que não escrevo e o motivo disto é uma questão de tempo. Devo apresentar meu mestrado no próximo mês de Dezembro e a correria é grande para terminar tudo…

Hoje gostaria de escrever sobre um design pattern que sempre apliquei, mas que não sabia que era um design pattern. Esse tipo de situação é mais comum de acontecer do que parece… Geralmente os design patterns são soluções que as pessoas aplicam no seu dia-a-dia e que após serem consideradas viáveis e reutilizáveis são documentadas em algum catálogo de padrões.

51M-zRDNMJL._SL500_PIsitb-sticker-arrow-big,TopRight,35,-73_OU01_SS500_

Saiba mais

Design Pattern – Façade

O pattern Façade (fachada), pertencente ao catálogo GOF, possui a intenção de estruturar o sistema de forma que se crie uma barreira (fachada) entre um conjunto complexo de instruções (subsistema) e os desenvolvedores (usuários), de forma que o subsistema torne-se mais fácil de ser utilizado e entendido, além de tornar-se reutilizável e confiável por executar sempre a mesma seqüência de passos. (Bishop, 2007, p. 93) (GoF, 1995, p. 179)

“Fornece uma interface unificada para um conjunto de interfaces em um subsistema. O Façade define uma interface de nível mais alto que torna o subsistema mais fácil de usar.” (GoF, 1995, p. 179)

clip_image002

 

Saiba mais

Design Patterns

Olá,

Não sei se sabem, mas Design Patterns são realmente um tema do qual eu gosto muito de falar e do qual sou extremamente fascinado. Por isso gostaria de começar uma série de artigos abordando o tema. Espero que aproveitem!

Design Patterns…

“Os Design Patterns não exigem nenhum recurso incomum da linguagem, nem truques de programação surpreendentes para impressionar seus amigos e gerentes.” (GoF, 1995, prefácio vii)

Um Design Pattern (Padrão de Projeto) é uma solução para um problema recorrente de modelagem de um software orientado a objetos. É composto por descrições de objetos e classes comunicantes que precisam ser personalizadas para resolução de um problema geral de projeto dentro de um contexto particular. (GoF, 1995, p. 20) (Freeman, 2005, p. 47/460)clip_image002

Saiba mais

Construindo sua camada de acesso a dados com o Entity Framework 4.1

O Entity Framework 4.1(EF41) Code First veio para ajudar os desenvolvedores no processo de construção da camada de acesso a dados de suas aplicações. Ao contrário dos demais modelos do Entity Framework, o modelo Code First tem por objetivo criar o banco de dados seguindo como base a estrutura de nossas classes – os demais modelos, conhecidos como Table First, baseavam a criação das classes no modelo existente em nosso banco de dados. A vantagem da utilização do Code First é a possibilidade de criar um modelo de classes muito mais próximo a nossa necessidade, ao contrário das abordagens anteriores que produziam um modelo de classe “adaptado” de nossa estrutura de banco de dados.

Neste exemplo vamos discutir os modos de implementação de diferentes modelos de relacionamentos (e.g. um-para-muito, muitos-para-muitos, um-para-um) utilizando o ADO.Net Entity Framework 4.1. Além disso, quero mostrar algumas novas features e dar algumas dicas de como nos adequar ao Entity Framework 4.1.

Vamos começar! Alegre

Obs.: Para fazer download do código-fonte acesse este link: http://code.msdn.microsoft.com/Construindo-sua-camada-de-de659425.

1 – Nosso projeto de teste

Para este teste criaremos um cadastro de Clientes, Fabricantes, Produtos e Ordens de Compra. Neste modelo um cliente pode efetuar diversas ordens de compras, sendo que cada comprar pode conter um ou mais produtos, onde cada produto pode estar atrelado a uma ou mais ordens de compra. Além disso, um produto obrigatoriamente contém um fabricante. Nosso diagrama de classes será o seguinte:

diagrama

2 – Camadas da aplicação

Para este exemplo adotei os design patterns MVC e DAO. Os projetos estão dispostos como a imagem a seguir:

Projects

Commerce.Controler: corresponde a camada de controle de nossa aplicação.

Commerce.Entity: possui todas as entidades lógicas de nossa aplicação, além das interfaces que devem ser implementadas pelas demais camadas.

Commerce.Data: responsável pela funcionalidade de armazenamento das informações, esta camada engloba todo o uso do Entity Framework 4.1, diminuindo a dependência do projeto a um tecnologia. Isso permite a fácil manutenção e alteração da tecnologia, sem gerar impactos globais por toda a aplicação.

Commerce.Console: camada de apresentação e consumo dos recursos.

3 – Estratégia de criação da base de dados

Para definir a estratégia de criação do banco de dados fazemos uso de inicializadores.A estratégia default é a DropCreateDatabaseIfModelChanges, que apaga o banco de dados e o recria, além dessa estratégia ainda existem outras duas, sendo elas: DropCreateDatabaseAlways e CreateDatabaseIfNotExists. O time de produto do ADO.Net trabalha hoje em um projeto chamado Code First Migration, que trata do processo de adequação do modelo do banco de dados com as atualizações de suas entidades, sem que seja necessário apagar e recriar o banco de dados. Para fazer uso dos inicializadores de bancos de dados crie em seu DataContext um construtor que defina a estratégia de criação da base de dados como a seguir:

SetInitializer

4 – Remoção de convenções do Entity Framework 4.1

Para efetuar o mapeamento automático de nossas tabelas, o EF41 adota algumas convenções de nomenclatura, tipos de dados, e outros recursos. Para adicionar ou remover convenções devemos sobrescrever o método OnModelCreating de nosso DataContext. Em nosso exemplo removerei duas convenções: IncludeMetadataConvention, que evita a criação da tabela EdmMetada, que é uma tabela que contém um código uma única linha com um código hash utiliza para verificar se o modelo de nosso código é o mesmo do modelo de nosso banco de dados (mais informações aqui: http://blog.oneunicorn.com/2011/04/08/code-first-what-is-that-edmmetadata-table/); e PluralizingTableNameConvention, que é um atributo que evita que a nome das tabelas seja pluralizado, isto é, se você possui uma entidade chamada Carro, a tabela criada automaticamente no banco de dados se chamará Carro, e não Carros como a convenção do EF41 faz.

Conventions

5 – Tipos complexos

É bastante comum em nossas aplicações a necessidade de utilizarmos atributos que apenas servem como “agrupadores” de dados, e que na verdade não deve ser mapeamos em uma única tabela dedicada a eles. Podemos adotar como exemplo um tipo de dados Endereço. Uma classe chamada Endereço é bastante importante para agrupar informações de localidade, mas não possui características que exijam mapeamento para uma tabela dedicada exclusivamente para isso. Diante deste cenário devemos fazer uso do atributo ComplexType. Este atributo quando utilizado indica que nossa classe é um tipo complexo, que não deverá ser persistido em uma tabela própria, e que estará vinculado a atributo de alguma classe. Podemos indicar que uma classe é um tipo complexo de duas maneiras, sendo elas:

2.1 – No corpo da classe, indicando através do atributo ComplexType:

ComplexType01

2.2 – Indicando o tipo complexo em nosso DataContext, dentro do método OnModelCreating:

ComplexType02

Ultimamente tenho pensado que é mais interessante configurar o mapeamento de nossas classes dentro do DataContext do que em nossas classes através da utilização de atributos. Acredito que essa é a melhor forma, pois nosso projeto de entidades ficará livre de mais dependências, necessitando apenas de recursos nativos do Framework .

6 – Entidade base para persistência de dados em fontes de dados

É interessante, ao implementarmos nossas entidades, a criação de uma entidade base que defina atributos obrigatórios para todas as entidades. Neste exemplo criei uma entidade chamada DataEntity que contém três atributos: Id, atributo do tipo inteiro que servirá como chave primária de nossas entidades na base de dados; GlobalId, atributo do tipo GUID que fornecerá um identificador global a nossos registros dentro da base de dados; e Created, atributo do tipo DateTime que informará a data de criação de nossas entidades.

dataEntity

A utilização dessa classe como entidade base exige duas implementações em nossas entidades:

1 – Herança

Herança

2 – Invoque ao construtor da classe base em nossas entidades

construtor

7 – Interface como contrato para os repositórios

Para implementação dos repositórios criei uma interface com um conjunto de métodos obrigatórios que se espera de um repositório.

IRepository

Nessa interface temos as assinaturas:

void Save(T target): este método deve ser responsável pela inclusão e atualização dos dados na base de dados. Uma vez executado deve garantir que os dados serão inclusos ou atualizados conforme a entidade passada por parâmetro.

void Delete(T target): método de exclusão de registros da base de dados. Quando invocado, deve apagar o registro passado por parâmetro da base de dados.

T GetById(int id): método que deve retornar o registro na base de dados que contiver em sua chave primária o valor passado por parâmetro.

T GetByGlobalId(Guid id): gosto bastante de utilizar um campo UNIQUEIDENTIFIER em meus registros, pois atribuímos ao registro uma chave de identificação única que o torna único em todo o banco de dados, independente de sua localização – assim como propostos em bases de dados orientadas a objetos.

IEnumerable<T> GetAll(): deve retornar todos os registros existentes na base de dados para a entidade consultada.

IEnumerable<T> ExecuteQuery(Func<T, bool> expression): este método faz consultas na base de dados utilizando como filtro a expressão passada por parâmetro.

Esta interface define o que é esperado por cada classe repositório, mas se notarmos ela utiliza um tipo genérico como parâmetro para sua implementação. Para refinarmos o seu uso e tornarmos nosso repositório reutilizável e expansível, acredito que devemos criar para cada classe repositório uma interface que implemente o contrato definido por IRepository<T>, mas que defina qual entidade será persistida ali. Tomemos como exemplo a interface do repositório de clientes, conforme código:

IClientRepository

Seu classe repositório deve implementar ICLientRepository e ser igual a seguinte implementação:

ClientRepository

Observem que nossa classe de repositório implementa a interface IClientRepository utilizando a entidade Client como alvo de nossas ações de persistência no banco de dados, e não um tipo de dados genérico, como utilizado na interface IRepository<T>.

Este uso é indicado ao construirmos nossos testes unitários, pois ao implementarmos nossos repositórios fakes já teremos nossos repositórios bem estruturados e prontos para extensão.

Outra dica para a construção de nossos testes unitários é tornar os repositórios parametrizáveis através de nossas classes controllers. Devemos criar uma assinatura de construtor que permita a parametrização do repositório que utilizaremos em nossa implementação, assim como é importante fornecer um construtor que defina um repositório padrão, caso não seja passado nenhum parâmetro para o repositório, podemos fazer isso desta forma:

clientController

Bom, espero que algumas dicas aqui descritas ajudem a implementação de suas aplicações com o Entity Framework 4.1. Bom estudo e continuem programando… Alegre

[]s!

Por
Fernando Henrique Inocêncio Borba Ferreira

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 63 outros seguidores