O objetivo 1.2 do exame 70-487: Developing Microsoft Azure and Web Services, Implement caching, trata-se de implementações de cache. Nesse objetivo, é necessário que você se familiarize com dois objetos de cache: ObjectCache e o HttpContext.Cache.

ObjectCache

O ObjectCache provê a funcionalidade de cache com extrema facilidade. Basta obter a instância dele usando MemoryCache.Default e usar os métodos que têm nomes amigáveis como Add, AddOrGetExisting, Get e Set. Pode não ser fácil memorizar todos os overloads, mas já chegamos lá. Primeiro dê uma olhada num uso simples do ObjectCache:

Note que é necessário primeiro remover o item do cache antes de chamar o método Add. Isso ocorre porque internamente o método Add usa o método AddOrGetExisting, então ele não substitui o valor anterior. Para obter um valor, você pode usar o método Get ou chamar diretamente o indexador (cache[key]).

Vamos às diferentes formas de adicionar um item no cache:

• Add(CacheItem, CacheItemPolicy)
• Add(String key, Object value, DateTimeOffset absoluteExpiration)
• Add(String key, Object value, CacheItemPolicy policy, String regionName)
• AddOrGetExisting(CacheItem, CacheItemPolicy)
• AddOrGetExisting(String key, Object value, DateTimeOffset absoluteExpiration)
• AddOrGetExisting(String key, Object value, CacheItemPolicy policy, String regionName)
• Set(CacheItem, CacheItemPolicy)
• Set(String key, Object value, CacheItemPolicy policy, String regionName)

Embora numerosos, esses overloads são bem parecidos. Certifique-se de memorizá-los.

O efeito de todos eles é bem parecido. A principal diferença é que o método Add, por internamente usar o método AddOrGetExisting, retorna um bool indicando se o item foi inserido no cache ou se ele já existia. Já o método Set não tem retorno e atualiza o valor se o item já estiver no cache.

O objeto CacheItem tem três propriedades: Key, Value e RegionName.

No objeto CacheItemPolicy, você pode setar a política de expiração usando a propriedade AbsoluteExpiration ou a SlidingExpiration. A diferença entre as duas é que, com AbsoluteExpiration, você determina exatamente a data em que o item vai ser removido do cache. Já com SlidingExpiration, o item é removido do cache se não for utilizado após o tempo (TimeSpan) determinado.

Ainda no CacheItemPolicy, você pode configurar também a propriedade Priority com o enum CacheItemPriority. No System.Runtime.Caching (ObjectCache), ele tem dois possíveis valores: Default (que é o marcado por padrão) e NotRemovable. A propriedade Priority funciona assim: quando os recursos de processamento estão baixos, o runtime pode limpar algumas coisas da memória para melhorar o processamento. Os itens do cache estão incluídos nessa limpeza. Esse é o comportamento padrão, adotado quando a Priority está com o valor Default. Os itens do cache adicionados com o valor NotRemovable na propriedade Prority nunca são removidos do cache pelo runtime. Isso é perigoso pois a aplicação pode crashar devido à falta de memória.

O objeto CacheItemPolicy conta ainda com uma lista de ChangeMonitor. Esse objeto, como o nome sugere, lida com mudanças (eventos) que causam atualização do cache. ChangeMonitor é uma classe base que tem várias implementações:

• CacheEntryChangeMonitor: serve como base para a construção de classes derivadas que monitoram os CacheItems
• FileChangeMonitor: monitora um arquivo checando se há mudanças para atualizar o cache
• HostFileChangeMonitor: monitora mudanças em diretórios e caminhos de arquivos, como o nome ou tamanho de um arquivo.

HttpContext.Cache

O HttpContext.Cache foi criado para ser usado especificamente numa aplicação web ASP.NET (fica em System.Web.Caching). Tome cuidado para não confundir os dois no exame. Se alguma questão mencionar o objeto HttpContext.Cache, Page.Cache ou somente Cache, você deve assumir que se trata de uma aplicação ASP.NET. Quaisquer outras menções à cache, pode se assumir que se trata do ObjectCache.

O jeito mais simples de adicionar ou atualizar um item no HttpContext.Cache é assim: Cache["FullNameKey"] = "John Q. Public";. Há também os métodos Add e Insert, que contêm várias sobrecargas (e infelizmente você também deve memorizar todas elas):

• Insert(String Key, Object Value)
• Insert(String Key, Object Value, CacheDependency dependencyItem)
• Insert(String Key, Object Value, CacheDependency dependencyItem, DateTime absoluteExpiration, TimeSpan slidingExpiration)
• Insert(String Key, Object Value, CacheDependency dependencyItem, DateTime absoluteExpiration, TimeSpan slidingExpiration, CacheItemUpdateCallback updateCallback)
• Insert(String Key, Object Value, CacheDependency dependencyItem, DateTime absoluteExpiration, TimeSpan slidingExpiration, CacheItemPriority priority, CacheItemRemovedCallback removeCallback)
• Add(string key, object value, CacheDependency dependencies, DateTime absoluteExpiration, TimeSpan slidingExpiration, CacheItemPriority priority, CacheItemRemovedCallback onRemoveCallback)

O método Add e a última forma do método Insert são virtualmente idênticos. A principal diferença está no método Insert que usa um CacheItemUpdateCallback, ao contrário do método Add que usa um CacheItemRemovedCallback. Em RemoveCallback é chamado quando o item é removido do cache, enquanto UpdateCallback é invocado um pouco antes do item ser removido do cache. Para a maioria das aplicações isso não faz muita diferença, mas a ideia é que se você precisa se certificar que um item nunca seja removido do cache, por exemplo, use UpdateCallback.

Assim como no ObjectCache, temos aqui também o enum CacheItemPriority, que funciona da mesma forma. A diferença é que aqui há mais opções de valores, com nomes bem sugestivos: Low, BelowNormal, Normal, AboveNormal, High, NotRemovable e Default. O valor padrão é Normal, que funciona da mesma forma que Default.

Para finalizar, há o parâmetro CacheDependency, que lida com cache de arquivos (como o HostFileChangeMonitor). Você pode passar também um objeto bem importante, o SqlCacheDependency. Ele tem dois construtores: um que aceita um SqlCommand e outro que aceita duas strings, a primeira sendo o nome do banco definido no web.config e a segunda é o nome da tabela que o cache será associado. Há muitos requisitos para se usar SqlCacheDependency, e alguns cuidados devem ser tomados.
Para o primeiro construtor, o banco de dados deve ser SQL Server 2005 ou superior. Dentro do SqlCommand, as tabelas devem ser referenciadas com o owner (dbo.Customer, por exemplo). SELECT * é proibido e a página não pode ter output caching.
O segundo é ainda mais complicado. Deve haver uma connection string no web.config da aplicação (obviamente). O banco de dados e a tabela devem ter notificações habilitadas no SQL Server e não é possível associar o cache com mais de uma tabela.

E é isso. O conteúdo desse objetivo foi bem simples, apesar de ser difícil decorar todos os overloads dos métodos de inserção.

Nos vemos no post do próximo objetivo, Implement transactions.
Até mais!

Leia Mais

EDIT: Essa é a parte 3 de três posts sobre o objetivo 1.1. Você pode conferir a parte 1 aqui (ADO.NET) e a parte 2 aqui (Entity Framework).

Esse é o último post sobre o objetivo 1.1 da certificação Microsoft 70-487. Vou falar sobre a terceira opção de acesso à dados que contempla o primeiro objetivo, o WCF Data Services. As outras duas opções, ADO.NET e Entity Framework, você pode ver aqui e aqui.

WCF Data Services

WCF Data Services, antes chamado ADO.NET Data Services, é um serviço da Microsoft acoplado ao Entity Framework que permite expor seus dados na web via HTTP utilizando tecnologias como OData, REST e JSON.

Para criar um WCF Data Services, os seguintes passos são necessários:

• Criar uma aplicação web ASP.NET;
• Usar o Entity Framework para criar um EDM;
• Adicionar um Data Service na aplicação;
• Habilitar acesso ao serviço.

Com o WCF Data Services criado, o consumo desses dados pode ser feito simplesmente chamando URLs num browser. Por exemplo, para obter todos os Customers do seu banco de dados, basta acessar a URL http://my company uri/MyApplication/MyService.svc/Customers. Para retornar todos os Customers com o LastName ‘Doe’, a URL fica http://my company uri/MyApplication/ MyService.svc/Customers(‘Doe’).

Mais detalhes desses filtros na URL serão cobertos em outros objetivos.

Resumo Do Objetivo 1.1

Como o conteúdo sobre WCF Data Services é pequeno, vou aproveitar para colocar aqui o resumo do objetivo 1.1 do exame, Choose data access technologies. Lembrando que o resumo contempla as três opções de acesso à dados: ADO.NET, Entity Framework e WCF Data Services.

• ADO.NET é a mais antiga das três opções e tem várias vantagens. Não requer conexão contínua com o banco de dados, é possível fazer conexão com qualquer banco de dados e possui objetos específicos para consumir os dados (DataSet e DataTable);
• Com Entity Framework, é possível que os desenvolvedores foquem no código da aplicação, e não no banco de dados utilizado. Você pode criar seu modelo baseado num banco de dados existente ou contruir o banco de dados a partir de um modelo conceitual;
• WCF Data Services permite que você exponha seus dados na web. O consumo dos dados, por ser via HTTP, não é atrelhado a nenhuma tecnologia. WCF Data Services é usado com Entity Framework no back end e provê um jeito fácil de construir e consumir um serviço na web.

E chegamos ao fim do objetivo 1.1 Por ser mais longo, tive que dividir o tema em três partes, mas a ideia é que os próximos objetivos sejam cobertos em um só post.

Fique ligado no próximo objetivo, que será Implement caching. Até mais!

Leia Mais

EDIT: Essa é a parte 2 de três posts sobre o objetivo 1.1. Você pode conferir a parte 1 aqui (ADO.NET) e a parte 3 aqui (WCF Data Services).

Nesse post vou falar do Entity Framework, a segunda opção de acesso à dados que estará no exame da certificação Microsoft 70-487 dentro do objetivo 1.1, Choose data access technologies. A primeira parte, sobre ADO.NET, está nesse post.

Entity Framework

O EF foi criado para permitir que os desenvolvedores focassem no código da aplicação, não no código necessário para se comunicar com o banco de dados. Essa necessidade surgiu devido às diferenças estruturais entre a programação orientada a objeto e o modelo relacional dos bancos de dados.

Para o exame, é necessário conhecer a estrutura do EF. O model do Entity Framework é dividido em três partes: o CSDL (conceptual schema definition language), que contempla o modelo conceitual, o SSDL (store schema definition language), que trata dos aspectos da estrutura do banco de dados, e o que mapeia as duas partes é chamado de MSL (mapping specification language). As três partes ficam em um único arquivo com a extensão .edmx.

Há dois modos de criar seu modelo conceitual no EF, chamado de Entity Data Model (EDM): Database First, onde você cria seu banco de dados e depois cria seu modelo conceitual, e Model First, onde você primeiro constrói o modelo conceitual e permite que as ferramentas do EF criem a estrutura do banco de dados para você.

Quatro ferramentas estão disponíveis para você criar e modificar seu EDM. São elas:

• Entity Model Designer, item que cria o arquivo .edmx e permite que você manipule quase todos os aspectos do model (criar, atualizar e deletar entidades, criar associações, etc.);
• Entity Data Model Wizard, que é o ponto de partida para a criação do seu EDM no modelo Database First;
• Create Database Wizard é o contrário do item anterior; essa ferramenta permite que você crie primeiro todo o seu modelo conceitual e depois gera o banco de dados necessário (Model First);
• E Update Model Wizard, que permite modificações no EDM após o modelo estar criado.

Nota importantíssima: no exame (e no Visual Studio), o Entity Framework pode ser chamado de ADO.NET Entity Data Model, ou ADO.NET EF. Não se confunda com essa nomeclatura! Ambos estão citando apenas o Entity Framework.

Veja o código para acessar o banco de dados com o EF. Mais detalhes sobre a API do EF serão cobertos no capítulo 2, que é todo dedicado ao Entity Framework.

O EF consegue mapear heranças de duas principais formas: Table per Hierarchy (TPH) e Table per Type (TPT). No TPH, ele cria somente uma tabela que contém todos os derivados de uma herança (criando colunas nullable e uma coluna para indicar o tipo). Já no TPT, para cada filho, uma tabela é criada referenciando o pai com um ID. No EF é possível também criar Tipos Complexos (Complex Types). Numa tabela que tem as colunas DataInicio e DataFim, por exemplo, você pode identificar essas colunas como um tipo complexo e elas se tornarão uma entidade DataRange no seu modelo conceitual.

ObjectContext

No código acima, e nas versões novas do Entity Framework, você geralmente trabalhará com o DbContext (a classe TestEntities). Mas no exame outro (antigo, velho e sujo) modo de usar o EF será cobrado: o ObjectContext. Veja como ele pode ser utilizado abaixo:

O contexto da classe ObjectContext tem uma propriedade chamada ContextOptions que contém 5 propriedades que você pode manipular. São elas:

• LazyLoadingEnabled. Marcada por padrão, essa propriedade controla se as entidades serão carregadas por demanda ou não. O EF faz o Lazy Loading pelas Navigation Properties. Por exemplo, ao carregar um Customer, suas Transactions não são carregadas. Ao iterar pela propriedade Transactions (uma Navigation Property), para cada Transaction na lista, um hit no banco é feito para obter os dados com o LazyLoadingEnabled setado true. Caso seja false, você precisa explicitamente carregar esses dados com o método LoadProperty() ou Include();
• ProxyCreationEnabled determina se classes POCO (plain on commom object) devem ser criadas para dados customizados. Detalhes serão cobertos no capítulo 2 do livro;
• UseConsistentNullReferenceBehavior funciona da seguinte forma: caso seja true e você sete uma Navigation Property que não esteja carregada como null, ao salvar, o EF tentará persistir isso no banco de dados (o que gerará um erro se a coluna não for nullable);
• UseCSharpNullComparisonBehavior muda o jeito que as comparações com null são feitas no banco de dados. Veja a diferença:
  
  Nesse caso, as seguintes queries serão feitas no banco de dados:
  SELECT COUNT(*) FROM Account WHERE AccountAlias <> ‘Home’ — Disabled
  SELECT COUNT(*) FROM Account WHERE AccountAlias <> ‘Home’ OR AccountAlias IS NULL — Enabled
• Por último, UseLegacyPreserveChangesBehavior controle o que acontece quando uma entidade já existe no contexto e é attachada novamente. Por padrão, o EF compara as duas entidades e, se alguma propriedade tiver valor diferente, o estado dessa propriedade vira Modified. Com o UseLegacyPreserveChangesBehavior, o valores diferentes não são copiados.

Você precisa se familiarizar também com as classes geradas pelo ObjectContext, assim como as geradas pelo DbContext (já mostradas acima). Cada entidade do modelo conceitual tem uma classe que herda de EntityObject. Essas classes são decoradas com três atributos:

• EdmEntityTypeAttribute indica que a classe faz parte de um EDM. Contém o namespace e o name da entidade;
• SerializableAttribute. As classes geradas pelo EF precisam ser serializáveis;
• DataContractAttribute é necessário para se trabalhar com WCF (mais detalhes no objetivo 1.5).

As propriedades são decoradas com dois atributos: DataMemberAttribute, para fins de WCF, e EdmScalarPropertyAttribute, que seta duas propriedades (EntityKeyProperty e IsNullable). O código da classe fica assim:

Por Que Entity Framework?

• Com as ferramentas se desenvolvendo cada vez mais, atualizar o modelo é muito menos trabalhoso do que com ADO.NET;
•  Você pode focar na lógica do negócio da aplicação, e não com o armazenamento dos dados;
• Atualmente, o EF permite a desacoplação entre o modelo conceitual e o armazenamento dos dados;
• O banco de dados pode ser mudado sem ter a necessidade de reescrever todo o código da aplicação;
• O EF foi pensado para trabalhar em conjunto com WCF.

O próximo post será sobre o último ponto do objetivo 1.1 da certificação, que é sobre o WCF Data Services.

Até mais!

Leia Mais

EDIT: Essa é a parte 1 de três posts sobre o objetivo 1.1. Você pode conferir a parte 2 aqui (Entity Framework) e a parte 3 aqui (WCF Data Services).

O primeiro tópico da certificação Microsoft 70-487 é Accessing data. Você pode conferir todos os tópicos e seus objetivos aqui.

Vamos falar do primeiro objetivo, Choose data access technologies, que se trata de como escolher uma tecnologia de acesso a banco de dados baseado nos requisitos da aplicação.

As três opções que serão cobradas no exame são:

• ADO.NET
• Entity Framework
• WCF Data Services

Farei um post para cada uma das opções, pois esse primeiro objetivo é bem extenso.

ADO.NET

ADO.NET é a tecnologia mais antiga das três e, portanto, considerada a mais madura e performática.

A primeira característica abordada no livro é a de que ADO.NET usa um modelo desconectado quanto a conexões no banco de dados. Ou seja, a cada comando (INSERT, UPDATE ou DELETE) ou query (SELECT), uma conexão é aberta e imediatamente fechada após o uso. Isso é uma vantagem pois evita todos os erros provenientes de se manter longas conexões abertas com o banco de dados, como processamento, rede e limite de conexões abertas ao mesmo tempo.

Outro ponto positivo é que ADO.NET é compatível com vários sistemas de banco de dados. No pacote System.Data, há classes específicas para alguns deles, como System.Data.SqlClient e System.Data.OracleClient, e também genéricas como System.Data.OleDb ou System.Data.Odbc.

Arquitetura

O .NET framework, no pacote System.Data, oferece várias classes apelidadas “data providers” que são designadas para lidar com as questões básicas de banco de dados, como fazer uma conexão, executar um comando e trabalhar com os dados que vieram do banco.

Nesse momento, o livro foca na diferença entre duas classes para obter dados: DataSet (ou DataAdapter) e DataReader. Note a diferença entre como as duas funcionam:

As principais vantagens do DataReader são:

• Como internamente um DataAdapter usa um DataReader, o último tem melhor performance;
• DataReader possui métodos assíncronos (BeginExecuteNonQuery, BeginExecuteReader, BeginExecuteXmlReader), enquanto DataAdapter não;
• O método Fill de um DataAdapter, conforme mostrado acima, só popula DataSets e DataTables. Com DataReaders, trabalhar com objetos de negócio é mais fácil.

Já as vantagens do DataAdapter são:

• É possível mapear os relacionamentos do banco de dados usando a propriedade Relations;
• O método Fill lê todos os registros do comando de uma vez, quando no DataReader você deve iterar por todos os registros manualmente (while (reader.Read()) …);
• DataSets são serializáveis. Eles podem ser carregados ou persistidos de um XML, por exemplo. Podem também ser salvos na Session ou em um ViewState (você não vai querer fazer isso).

Por Que ADO.NET?

No exame, muitas perguntas são do tipo “dada uma situação, escolha as tecnologias que seriam as mais apropriadas”. Às vezes é difícil identificar, mas o livro é bem focado e já apresenta as informações dessa forma. Vamos às vantagens de se utilizar ADO.NET:

• Consistência: ADO.NET é a mais antiga e estável das opções disponíveis. Foi muito utilizada e testada.
• Estabilidade em termos de evolução e qualidade. ADO.NET está bem estabelecida e é pouco provável que mude ou tenha novas features.
• ADO.NET é fácil de entender. Sabendo o conceito de como funciona, não há muitos segredos. Por existir há muito tempo, há providers para quase todos os tipos de bancos de dados e uma documentação bem abrangente.
• É possível utilizar ADO.NET com Azure SQL sem problema algum.

Fique ligado no próximo post, que será sobre a segunda opção de tecnologia para acesso à banco de dados: o Entity Framework.

Até mais!

Leia Mais