Olá!

O objetivo 2.5 da certificação, Create an Entity Framework data model, é o último objetivo do segundo tópico da certificação, Querying and manipulating data by using the Entity Framework. Finalmente vamos ver como construir um Entity Model, além de recordar alguns conceitos e componentes do EF cobertos no objetivo 1.1.

Esse objetivo cobre como: 1) estruturar o model usando as heranças Table-per-Type e Table-per-Hierarchy, 2) escolher e implementar um método de data model (Model First ou Database First), 3) implementar objetos POCO e 4) descrever um data model usando Conceptual Schema Definitions, Storage Schema Definition, e Mapping Language (CSDL, SSDL, MSL). Vamos lá?

Estruturando o Data Model Usando as Heranças Table-per-Type e Table-per-Hierarchy

Você pode tratar os casos de herança de duas formas: Table-per-Type (tabela por tipo) e Table-per-Hierarchy (tabela por hierarquia).

Basicamente, a diferença entre as duas é que, em tabela por tipo, cada classe herdeira vira uma tabela no banco de dados. Em tabela por hierarquia, tanto a classe pai quanto as filhas ficarão guardadas na mesma tabela, geralmente com uma coluna indicando qual é o tipo.

Para o exame, você deve saber quais são as vantagens e desvantagens das duas formas:

Tabela Por Tipo

Vantagens:

• Os dados não são guardados redundantemente;
• Os dados são armazenados na terceira norma formal, aumentando a integridade;
• A implementação é mais simples. Para adicionar ou remover uma entidade herdeira, basta deletar a tabela no banco de dados e atualizar o Entity Model.

Desvantagens:

• A performance é afetada em operações básicas (CRUD);
• Complica a administração do banco de dados pelas tabelas adicionais.

Tabela Por Hierarquia

Vantagens:

• Deixa o schema do banco simplificado por conter menos tabelas;
• Operações de CRUD otimizadas por trabalhar em uma só tabela.

Desvantagens:

• Há redundância dos dados por não seguir a terceira normal formal;
• Pode haver problemas com a integridade dos dados devido a redundância;
• O Entity Model fica mais complexo pela tabela conter mais campos.

Escolher e Implementar um Método de Data Model (Model First ou Database First)

Escolher um modelo de EDM é um conceito importante, mas não há muito o que aprender aqui.

Model First acontece quando você cria um modelo vazio e vai criando os recursos necessários, como as entidades, os relacionamentos entre elas e o comportamento das propriedades. Depois disso tudo, você gera o schema do banco de dados do EDM; e o Entity Framework cuida da criação do banco de dados e o mapeamento entre o banco e o modelo.

Database First, como esperado, assume que você já tem o schema do banco de dados pronto e escolhe criar o EDM a partir dele. Nesse caso, o Entity Framework cuida da criação dos itens do EDM e o mapeamento entre eles.

Outro ponto importante nesse assunto são as propriedades que você pode setar diretamente no EDM, escolhendo qualquer um dos dois métodos. Clicando com o botão direito no designer e indo em Properties, você pode controlar algumas propriedades que têm o nome bem sugestivo, como se o Lazy Loading deve ser utilizado, o nome do namespace desejado, o nível de acesso dos containers, etc.

Indo nas propriedades de cada entidade ou em alguma propriedade, há alguns comportamentos e configurações que podem ser alterados:

• A classe base da entidade;
• Se a propriedade é Nullable;
• Visibilidade dos getters e setters;
• Um valor default para uma propriedade;
• Essa é bem interessante: a propriedade Concurrency Mode, quando setada para Fixed, assegura que o valor no banco de dados não foi alterado quando você vai atualizá-lo. Por exemplo, se você obteve uma entidade do banco com uma propriedade no valor “x” e vai alterá-la para “y”, o Entity Framework vai validar se o valor ainda é “x” antes de você atualizá-lo para “y”. Isso pode ser bem útil em alguns cenários, mas carrega uma piora na performance pela validação. Outro ponto é que, embora esse comportamento seja definido no nível de propriedade, se você tiver 50 campos setados para Fixed, apenas uma query será feita no banco para comparar os 50 valores.

Implementar Objetos POCO

Ao criar uma entidade no EDM, o Entity Framework vai gerar a classe .NET automaticamente. Caso desejado, você pode desabilitar esse comportamento nas Properties do designer e criar você mesmo um POCO (plain old common object), tendo mais controle sobre suas classes.

Para usar suas classes POCO no contexto do EF, alguns passos são necessários. A primeira coisa é que as classes devem ser decoradas com o atributo Table, especificando o nome da tabela no banco de dados:

[Table("Account")]
public class Account{}
[Table("Customers")]
public class Customers{}
[Table("TransactionDetails")]
public class TransactionDetail{}
Table("Transactions")]
public class Transaction{}

O modo de vincular as classes no contexto depende se você estiver utilizando DbContext ou ObjectContext.

Com DbContext, basta definir as classes usando a classe genérica DbSet e passando o tipo de cada POCO:

public partial class EntityFrameworkSamplesEntitiesDb : DbContext
{
public EntityFrameworkSamplesEntitiesDb(): base("name=EntityFrameworkSamplesEntities1")
{}
public DbSet Accounts { get; set; }
public DbSet Customers { get; set; }
public DbSet TransactionDetails { get; set; }
public DbSet Transactions { get; set; }
}

Com ObjectContext não é muito diferente. A classe genérica ObjectSet deve ser usada e as propriedades devem ser inicializadas no construtor:

public partial class EntityFrameworkSamplesEntitiesSample : ObjectContext
{
public EntityFrameworkSamplesEntitiesSample(): base("name=EntityFrameworkSamplesEntities1")
{
Accounts = new ObjectSet();
Customers = new ObjectSet();
TransactionDetails = new ObjectSet();
Transactions = new ObjectSet();
}
public ObjectSet Accounts { get; set; }
public ObjectSet Customers { get; set; }
public ObjectSet TransactionDetails { get; set; }
public ObjectSet Transactions { get; set; }
}

Descrever um Data Model Usando Conceptual Schema Definitions, Storage Schema Definition, e Mapping Language (CSDL, SSDL, MSL)

O Entity Framework junta cada um desses componentes no arquivo .edmx, mas para o exame é importante entender qual o papel de cada um. Basicamente, o CSDL é o conceito do schema do banco traduzido para objetos; o SSDL representa o próprio schema do banco de dados e o MSL é o responsável por juntar os dois e mapear o schema do banco com os objetos.

Não há muito o que ir mais fundo sobre o CSDL e o SSDL, a não ser que são XMLs representando informações – objetos e modelos relacionais de banco de dados. O MSL, que unifica os dois, é um pouco mais complexo e merece um entendimento maior.

O MSL, junto com o .edmx, contém vários outros arquivos gerados automaticamente. São eles:

• Um arquivo .edmx que serve como container para tudo;
• Um arquivo ModelName.Context.tt para geração de templates das classes .NET especificadas no model do respectivo contexto;
• O arquivo ModelName.Context.cs que contém as classes do contexto;
• O arquivo ModelName.Designer.cs que provê suporte para o designer do EDM;
• Um arquivo ModelName.edmx.Diagram que contém um XML parecido com o seguinte:
  <?xml version="1.0" encoding="utf-8"?>
<edmx:Edmx Version="2.0" xmlns:edmx="http://schemas.microsoft.com/ado/2008/10/edmx">
<!-- EF Designer content (DO NOT EDIT MANUALLY BELOW HERE) -->
<edmx:Designer xmlns="http://schemas.microsoft.com/ado/2008/10/edmx">
<!-- Diagram content (shape and connector positions) -->
<edmx:Diagrams>
<Diagram DiagramId="8576b1de6991436caba647ac89886831" Name="Diagram1">
<EntityTypeShape EntityType="EntityFrameworkSamplesModel1.Account" Width="1.5" PointX="7.5" PointY="0.875" IsExpanded="true" />
<EntityTypeShape EntityType="EntityFrameworkSamplesModel1.Customer" Width="1.5" PointX="9.75" PointY="0.875" IsExpanded="true" />
<EntityTypeShape EntityType="EntityFrameworkSamplesModel1.TransactionDetail" Width="1.5" PointX="14.25" PointY="0.875" IsExpanded="true" />
<EntityTypeShape EntityType="EntityFrameworkSamplesModel1.Transaction" Width="1.5" PointX="12" PointY="0.875" IsExpanded="true" />
<AssociationConnector Association="EntityFrameworkSamplesModel1.FK_Account_Account" ManuallyRouted="false" />
<AssociationConnector Association="EntityFrameworkSamplesModel1.FK_Customer_Account" ManuallyRouted="false" />
<AssociationConnector Association="EntityFrameworkSamplesModel1.FK_Transactions_Customer" ManuallyRouted="false" />
<AssociationConnector Association="EntityFrameworkSamplesModel1.FK_TransactionDetails_Transactions" ManuallyRouted="false" />
</Diagram>
</edmx:Diagrams>
</edmx:Designer>
</edmx:Edmx>
• Por último, o arquivo ModelName.tt que tem as informações de template para geração das classes de dados.

Uma olhada no arquivo .edmx pode ajudar na visualização de todos esses artefatos:

Isso é tudo para esse objetivo. O próximo post cobrirá o primeiro objetivo do capítulo 3 da certificação, Designing and implementing WCF Services.

Nos vemos lá!

Leia Mais

Olá pessoal! Esse post será sobre objetivo 2.4 da certificação Microsoft 40-487, Query and manipulate data by using ADO.NET. Embora já coberto no objetivo 1.1, esse objetivo é bem específico sobre o ADO.NET e suas classes, assim como métodos assíncronos.

Fazendo Queries com Connection, DataReader, Command, DataAdapter e DataSet

SqlConnection

Não há muito segredo sobre a classe SqlConnection. Ela herda de IDbConnection e você deve instanciá-la passando uma connection string, seja inline ou de um arquivo de configuração (web.config).

Todas as connections precisam ser abertas com o método Open e fechadas explicitamente com Close ou num bloco using.

using (SqlConnection connection = new SqlConnection("ConnectionStringName"))
{
connection.Open();
}

Sempre abra uma conexão num bloco try/catch, pois fatores fora do seu alcança podem impedir que isso aconteça.

SqlCommand

A classe SqlCommand, herdeira de IDbCommand, é a responsável por fazer comandos ao banco de dados. Algumas de suas características são:

• Uma SqlCommand precisa de uma SqlConnection aberta para operar;
• Além da propriedade Connection, o único outro item importante é setar a propriedade CommandText, que é o SQL a ser executado. É possível também passar somente o nome de uma stored procedure no lugar do SQL, sendo necessário nesse caso setar a propriedade CommandType para StoredProcedure;
• Você nunca deve concatenar valores como string numa query SQL. Instancie a classe SqlParameter e o adicione na propriedade Parameters;
• Há muito debate entre stored procedures e “SQLs dinâmicos” (queries na propriedade CommandText). O fato é que, sendo parametrizados corretamente, o plano de execução dos SQLs dinâmicos é cacheado, o que pode aumentar a performance e ser menos vulnerável à ataques;
• Há várias maneiras de executar um SqlCommand. Você pode usá-lo como input da propriedade SelectCommand de um SqlDataAdapter, chamar ExecuteScalar para retornar um valor ou ExecuteReader para retornar um SqlDataReader;
• Cada método de execução tem seu par assíncrono, indicados pelo nome começando com Begin;
• É bom chamar o método Dispose de um SqlCommand. Faça isso explicitamente ou faça uso de um bloco using.

SqlDataReader

A classe SqlDataReader, invocada pelo método ExecuteReader de um SqlCommand, é responsável pela obtenção de dados. Você deve fechar explicitamente quaisquer SqlDataReader abertos.

SqlDataReader tem uma característica que você deve ter em mente: ao obter um SqlDataReader pelo método ExecuteReader, o buffer é carregado do banco de dados, mas o stream dos dados não é feito até você iterar pelos itens com o método Read. É possível saber se há itens no buffer com a propriedade HasRows, mas não há como saber quantos itens existem sem iterar pelos dados, o que esvazia o buffer no processo. Isso significa que você só pode iterar pelos dados uma única vez.

SqlDataAdapter

SqlDataAdapter é uma classe designada para fazer todas as operações no banco de dados (CRUD).

Na leitura, ela funciona bem diferente do SqlDataReader: um DataSet é populado (com uma mais DataTables), permitindo que você itere quantas vezes quiser – até com LINQ. Outra diferença é que você pode obter facilmente a quantidade de registros retornados com o Count de uma DataTable.

O método Fill é o jeito mais básico de carregar um SqlDataAdapter. Passando um SqlCommand válido, o método conecta ao banco de dados, executa o comando e cria uma DataTable para cada query SELECT.

Cada coluna gera uma DataColumn na DataTable sendo construída. O próprio adapter infere o tipo da DataColumn, de acordo com o schema no banco de dados. Se houver mais de uma coluna com o mesmo nome ou alias, o adapter adiciona um número no final do nome (FirstName1, FirstName2, FirstName3). É possível também chamar o método Fill especificando o valor AddWithKey do enum MissingSchemaAction, resultando na adição de uma primary key e outras contraints existentes no banco de dados. Caso haja mais de uma primary key numa query, você pode criar uma manualmente na DataTable. Com a DataTable e as DataColumns criadas, o adapter cria uma DataRow para cada registro retornado do banco de dados.

Outro método importante é o Update. Ele funciona assim: todas as DataRows, quando retornadas, tem o RowState como Unchanged. Você pode alterar o RowState de uma DataRow para Added, Modified ou Deleted. Basicamente, quando o método Update é chamado, ele varre todas as DataRows e, dependendo do RowState, chama o SqlCommand correspondente (InsertCommand, UpdateCommand ou DeleteCommand) do SqlDataAdapter. Para funcionar corretamente, você precisa setar todas essas propriedades. Caso o command não seja encontrado, uma exceção é lançada.

A sintaxe do SqlDataAdapter é assim: (note que o próprio método Fill chama o método Open da SqlConnection, e ele se encarrega de fechá-la. Caso você a abra, a responsabilidade de fechá-la é sua)

Por último, você pode definir o comportamento de um SqlDataAdapter com algumas propriedades:

• AcceptChangesDuringFill: por padrão, o método Fill carrega todas as DataRows com o RowState Unchanged. Se você setar essa propriedade como false, todas as DataRows terão o RowState Added;
• AcceptChangesDuringUpdate: como dito anteriormente, o método Update examina o RowState de cada DataRow para saber qual Command invocar. Ao final do método, todos os RowStates são retornados para Unchanged. Setar essa propriedade como false não reseta o RowState; mantém o estado que estava antes do método Fill ser chamado;
• UpdateBatchSize: por padrão, o SqlDataAdapter atualiza uma DataRow por vez. Setando essa propriedade, as atualizações são feitas em grupos, o que diminui as chamadas ao banco de dados;
• OnRowUpdating/OnRowUpdated: eventos na atualização de uma DataRow;
• ContinueUpdateOnError: por padrão, quando há vários comandos a serem executados e um deles lança uma Exception, todos os outros comandos não são feitos. Setando essa propriedade como true, o comando que deu erro é ignorado e os outros comandos são executados normalmente;
• FillSchema: FillSchema usa o SelectCommand para construir o schema do DataTable correspondente, sem popular a tabela.

Fazendo Operações Síncronas e Assíncronas

Há três métodos de um SqlCommand que têm suas partes assíncronas: BeginExecuteReader, BeginExecuteXmlReader e BeginExecuteNonQuery. Eles são bem fáceis de usar. Basta examinar a propriedade IsCompleted e, quando completo, chamar o método End correspondente:

Obrigado pela leitura e fiquem ligados no post do objetivo 2.5, Create an Entity Framework data model.

Até mais!

Leia Mais

Olá pessoal! Chegamos ao objetivo 2.3 da certificação Developing Microsoft Azure and Web Services, o Query data by using LINQ to Entities.

Esse objetivo cobre como 1) fazer queries usando LINQ, 2) IQueryable vs. IEnumerable e 3) logar queries. Vamos lá?

Fazendo queries usando LINQ

O objetivo desse ponto é mostrar que é possível utilizar LINQ to Entities de versões antigas do Entity Framework com ObjectContext, assim como se faz com DbContext.

Com ObjectContext, você cria um ObjectQuery que é virtualmente idêntico à aqueles do DbContext. Por exemplo:

IQueryable query = from acct in Context.Accounts
where acct.AccountAlias == "Primary"
select acct;

É importante também saber que o ObjectQuery implementa IQueryable, IEnumerable e IListSource.

IQueryable vs. IEnumerable

IEnumerable é caracterizado por:

• Uso em LINQ to Objects e LINQ to XML;
• São performados em memória;
• São performados no heap.

IQueryable são notavelmente diferente na maioria dos casos:

• Rodam fora do processo;
• Suportam diferentes datasources, incluindo remotos;
• São usados em LINQ to Entities e LINQ to DataServices.

Logando Queries

Usando Entity Framework, às vezes se torna necessário você saber exatamente qual a query SQL o framework gerou automaticamente. Por exemplo:

IQueryable Query = from Acct in Context.Accounts
where Acct.AccountAlias == "Primary"
select Acct;

Com ObjectQuery (ObjectContext), você pode obter a query fazendo um cast explícito para ObjectQuery e usar o método ToTraceString:

String Tracer = (Query as ObjectQuery).ToTraceString();

Com DbContext, é possível de maneira similar:

String Output = (from Acct in ContextName.ContextSet select Acct).ToString();

Isso é tudo para o conteúdo desse objetivo.
Obrigado pela leitura e acompanhe a continuação das postagens da certificação Microsoft 70-487, que será sobre o próximo objetivo Query and manipulate data by using ADO.NET.

Até mais!Query and manipulate data by using ADO.NET

Leia Mais

Olá pessoal! Continuando a série de posts sobre a certificação Microsoft 70-487, vamos ao objetivo 2.2, Query and manipulate data by using Data Provider for Entity Framework. Esse é um objetivo bem curto que fala sobre como fazer queries usando o namespace System.Data.EntityClient.

O namespace System.Data.EntityClient é um superset do namespace System.Data, e suas classes operam de forma bem similar. As diferenças se referem ao Entity Framework.

Em todos os cenários de acesso ao banco de dados, uma conexão é necessária. No namespace SqlClient, há a classe SqlConnection. Para o EntityClient, a classe de conexão é a EntityConnection. Ela tem três construtores: um vazio (new EntityConnection()), um que recebe uma connection string normal e o terceiro em que você deve especificar informações (metadados) para o EDM. Para fazer isso, a melhor maneira é usar a classe EntityConnectionStringBuilder em conjunto com a classe SqlConnectionStringBuilder:

String provider = "System.Data.SqlClient";
String serverName = "localhost";
String databaseName = "dbname";

SqlConnectionStringBuilder connBuilder = new SqlConnectionStringBuilder();
connBuilder.DataSource = serverName;
connBuilder.InitialCatalog = databaseName;

EntityConnectionStringBuilder efBuilder = new EntityConnectionStringBuilder();
efBuilder.Provider = Provider;
efBuilder.ProviderConnectionString = connBuilder.ToString();
efBuilder.Metadata = @"*csdl, *ssdl, *msl";
EntityConnection Connection = new EntityConnection(efBuilder.ToString());

O resto opera de forma bem igual à uma SqlConnection, como os métodos Open, Close e BeginTransaction.

O EntityCommand também trabalha como o SqlCommand. Há os métodos CreateParameter, ExecuteNonQuery, ExecuteReader e ExecuteScalar, por exemplo, e todos eles funcionam como sugerido. Todos eles também têm suas versões Async, onde a única diferença é a presença da propriedade CancellationToken.

Há também a classe EntityTransaction, que funciona também de forma idêntica à TransactionScope (explicada aqui).

Fazendo Transações

Há duas opções para se fazer transações diretamente.

A primeira é usando a classe DbTransaction. Você a obtém pelo DbContext, no método Database.Connection.BeginTransaction():

EntityFrameworkSamplesEntities Context = new EntityFrameworkSamplesEntities();
IDbTransaction TransactionInstance = Context.Database.Connection.BeginTransaction();
try
{
// Do Something
Context.SaveChanges();
TransactionInstance.Commit();
}
catch (EntityCommandExecutionException)
{
TransactionInstance.Rollback();
}

O próximo método, bem mais provável de se encontrar no exame, é pela classe TransactionScope. A vantagem dela é que você só precisa chamar o método Complete após SaveChanges; não é necessário nenhum tratamento especial em caso de falha:

EntityFrameworkSamplesEntities Context = new EntityFrameworkSamplesEntities();
using (TransactionScope CurrentScope = new TransactionScope())
{
try
{
Context.SaveChanges();
CurrentScope.Complete();
}
catch (EntityCommandExecutionException)
{
//Handle the exception as you normally would
//It won't be committed so transaction wise you're done
}
}

E isso é tudo para esse objetivo 🙂 O próximo post será sobre o objetivo 2.3, Query data by using LINQ to Entities.

Até mais!

Leia Mais

Olá pessoal! Esse será o post do primeiro objetivo do segundo grande tópico da certificação, o Querying and manipulating data by using the Entity Framework. Esse tópico foca especificamente em LINQ e Entity Framework e cobre aproximadamente 20% das questões do exame. Esse primeiro objetivo, Query and manipulate data by using the Entity Framework (que recebe quase o mesmo nome do tópico), cobre aspectos específicos do EF e os componentes que o compõe. Vamos lá?

Fazendo Queries, Updates e Deletes Usando DbContext

Fazer queries usando DbContext é bem direto e simples, usando LINQ:

var query = (from acct in context.Accounts
where acct.AccountAlias == "Primary"
select acct).FirstOrDefault();

Após uma entidade ser retornada de uma query, você pode interagir com o objeto como qualquer outro. Você faz quaisquer modificações necessárias e chama o método SaveChanges do context para fazer um update das informações alteradas.

É possível também atualizar um item que você criou usando o método Add ou Attach e chamando o mesmo método SaveChanges para persistir as alterações. É importante entender bem a diferença entre os dois métodos: incluir uma entidade usando Add faz o item ter o EntityState como Added. Pelo objeto não ter valores originais no ObjectStateEntry, quando SaveChanges é chamado, o contexto vai tentar inserir a entidade no banco de dados. Attach, por outro lado, cria o item com o EntityState Unchanged. Então o momento que você faz o Attach é muito importante. Se você fizer depois de todas as alterações, nada vai acontecer, pois o EntityState vai continuar como Unchanged. Se você fizer o Attach e depois fazer as modificações na entidade, aí sim o context vai fazer o update das propriedades no banco na chamada do SaveChanges.

Para deletar uma entidade do banco, você deve especificar o tipo da entidade usando o método Set e depois chamar o método Remove passando uma query. O item será deletado após a chamada ao SaveChanges.

context.Set().Remove(query);

Deferred Execution e Lazy Loading

Esse assunto pode ser bem extenso, por isso vamos simplificar bastante aqui.

Veja o seguinte código:

var query = from acct in context.Accounts
where acct.AccountAlias == "Primary"
select acct;

Suponha que no banco de dados há 20 registros com o nome da conta Primary. É lógico pensar que na próxima linha o count da query será 20, certo? Errado. Nesse ponto, nada aconteceu em termos de banco de dados. A essência de Deferred Execution (execução adiada) é que somente quando você pede o dado, explicitamente referenciando-o, que o acesso ao banco de dados é de fato feito. O código abaixo, por exemplo, potencialmente dispara muitas idas ao banco de dados:

var query = from acct in Context.Accounts
where acct.AccountAlias == "Primary"
select acct;
foreach (var currentAccount in query)
{
Console.WriteLine("Current Account Alias: {0}", currentAccount.AccountAlias);
}

Já o código abaixo, por exemplo, ao invés de retornar uma coleção de itens, retorna somente um valor (count). Como é impossível obter esse valor sem ir ao banco de dados, ao chamar Count (ou qualquer função Aggregate como Average e Max), o acesso ao banco de dados é feito imediatamente:

var query = (from acct in context.Accounts
where acct.AccountAlias == "Primary"
select acct).Count();

Resumindo: no conceito de Deferred Execution, usado pelo EF, dados só são recuperados quando necessário.

O Lazy Loading é um conceito parecido com o Deferred Execution, mas aplicado para relacionamentos no banco de dados.

Imagine uma estrutura onde um Bank tem vários Customers, um Customer tem várias Accounts, uma Account tem várias Transactions e uma Transaction tem várias TransactionDetails. Ao obter um Customer para uma atualização simples de dados, você iria querer que todas as Accounts (com todas as Transactions e as TransactionsDetails) fossem retornadas? Provavelmente não.

As opções de Loading são:

• Lazy Loading: quando uma query é executada, somente os dados da entidade alvo são retornados. Por exemplo, se houver um relacionamento entre Account e Contact, uma query para Account retornaria inicialmente os dados da Account. Informações da Contact associada seriam retornadas quando uma NavigationProperty fosse acessada ou se você explicitamente pedisse;
• Eager Loading: todos os dados relacionados são retornados. Nesse exemplo, ao fazer uma query para uma Account, os dados da Contact já seriam retornados. Essencialmente, é o oposto de Lazy Loading;
• Explicit Loading: quando Lazy Loading está desabilitado, você pode usá-lo para carregar entidades de forma Lazy explicitamente. O método Load permite que você execute queries individualmente.

Você pode achar que Lazy Loading sempre é a melhor opção, mas não se engane. Se você sabe quais dados vai usar, o Lazy Loading pode afetar a performance por fazer várias idas as banco de dados ao invés de uma. Se por outro lado você não tiver certeza do número de requisições ao banco de dados e provavelmente não vai utilizar todos os dados retornados, aí sim o Lazy Loading é a melhor opção.

É possível habilitar ou desabilitar o Lazy Loading visualmente ou por código. Pelo Designer, basta ir ao EF Model, depois Properties, e escolher True ou False na propriedade Lazy Loading Enabled. Por código, o DbContext possui uma propriedade Configuration.LazyLoadingEnabled: context.Configuration.LazyLoadingEnabled = true;.

Dê uma olhada no código abaixo:

Se você colocar um breakpoint na linha do primeiro foreach, vai perceber bem a diferença do Lazy Loading. Caso esteja desabilitado, toda a cascata de relacionamento será carregada na primeira ida ao banco de dados. Caso habilitado, você vai notar que as propriedades Customers, Transactions e TransactionDetails não serão carregadas. Elas irão sendo carregadas conforme forem usadas (foreach). Algumas outras operações também fazem com que os relacionamentos sejam carregados, como ToList, ToArray ou ToDictionary.
É importante notar também que se uma função Aggregate for chamada, uma query será executada imediatamente para retornar aquele valor. Então se você chamar o método Count de query.Customers e depois iterar pela lista (foreach), duas chamadas ao banco de dados serão feitas. Iterando primeiro (ou chamando o método ToList), você já saberia o tamanho da lista e não seriam necessárias duas chamadas.

Criando Compiled Queries

Usando LINQ, o EF cuida de traduzir a query para a linguagem SQL em tempo de execução, o que leva algum tempo. Por isso, o EF suporta compiled queries, onde ele cacheia o SQL de uma determinada query e somente muda os parâmetros na hora de executá-la. A partir do .NET 4.5, isso é feito automaticamente, mas você pode ainda fazer esse processo manualmente:

static readonly Func compiledQuery =
CompiledQuery.Compile(
(ctx, email) => (from p in ctx.People
where p.EmailAddress == email
select p).FirstOrDefault());

E usar a query assim: Person p = compiledQuery.Invoke(context, "foo@bar");. É importante o método ser estático para evitar a compilação a cada chamada. Outro ponto é que se a query for modificada, o EF vai precisar recompilá-la. Então o ganho de performance será perdido se você adicionar um Count ou ToList numa query compilada.

Usando Entity SQL

O EF permite que você execute queries SQL diretamente no DbContext, com todo o conhecimento do seu model. Outro benefício é o maior controle sobre a query SQL que será executada no banco de dados. Você pode fazer uso do Entity Framework Object Services assim:

var queryString = "SELECT VALUE p " +
"FROM MyEntities.People AS p " +
"WHERE p.FirstName='John'";
ObjectQuery people = context.CreateQuery(queryString);

Outro cenário é quando você não precisa do objeto inteiro ou quer trabalhar somente com os valores retornados para ganho de performance. Isso é efetuado através da classe EntityDataReader, bem parecida com a classe DataReader do System.Data. Segue um código de exemplo:

Isso é tudo para esse objetivo. Obrigado pela leitura e fique de olho no próximo post, que será sobre o objetivo 2.2 da certificação Microsoft 70-487: Query and manipulate data by using Data Provider for Entity Framework.

Até mais!

Leia Mais

Olá pessoal!

Continuando a série sobre a certificação Microsoft 70-487, esse post será sobre o objetivo 1.6, Manipulate XML data structures, o último do primeiro tópico da certificação, Accessing data. Vamos lá?

Lendo, Filtrando, Criando e Modificando Estruturas XML

XML é um arquivo que estrutura dados em formato de texto baseado em elementos e atributos. Elementos são estruturas que representam um componente de dados, enquanto atributos são propriedades dos elementos.

O primeiro componente de um documento XML é o XML declaration. Esse elemento não é obrigatório e geralmente inclui a versão do XML e o encoding:

<?xml version="1.0" encoding="utf-8" ?>

Um XML válido tem os seguintes requerimentos:

• Deve ter somente um elemento raiz;
• Elementos que são abertos devem ser fechados na ordem que foram abertos;
• Todos os elementos precisam ser válidos ou bem formados.

Considere o seguinte XML. Name, FirstName, MiddleInitial e LastName são elementos, enquanto MiddleName é um atributo do elemento MiddleInitial:

<?xml version="1.0" encoding="utf-8" ?>
<Name>
<FirstName>John</FirstName>
<MiddleInitial MiddleName="Quartz">Q</MiddleInitial>
<LastName>Public</LastName>
</Name>

Existem mais dois elementos que você deve conhecer para o exame: comentários e namespaces. Comentários são definidos dessa forma:

<!-- this is a comment about the Name element. Blah blah blah-->

Namespaces servem para identificar quem escreveu o XML, geralmente uma empresa. Você pode definir o namespace no elemento raiz como o seguinte:

xmlns:Prefix="SomeValueUsuallyACompanyUrl"

xmlns é a abreviação de XML NameSpace.

Você pode definir também dois namespaces no elemento raiz. Isso é útil quando duas ou mais pessoas (ou empresas) estão escrevendo o mesmo XML, talvez com elementos com o mesmo nome. Por exemplo:

<DocumentCore xmlns:johnco="http://www.yourcompany.com/Companies" xmlns:billco="http://
www.mycompany.com/Customers">
<johnco:Name>
<johnco:Company>JohnCo</johnco:Company>
</johnco:Name>
<billco:Name>
<billco:FirstName>John</billco:FirstName>
<billco:MiddleInitial>Q</billco:MiddleInitial>
<billco:LastName>Public</billco:LastName>
</billco:Name>
</DocumentCore>

Outra opção é definir o namespace no nível de cada elemento:

<DocumentCore>
<johnco:Name xmlns:johnco="http://www.yourcompany.com/Companies">
<johnco:Company>JohnCo</johnco:Company>
</johnco:Name>
<billco:Name xmlns:billco="http://www.mycompany.com/Customers">
<billco:FirstName>John</billco:FirstName>
<billco:MiddleInitial>Q</billco:MiddleInitial>
<billco:LastName>Public</billco:LastName>
</billco:Name>
</DocumentCore>

Manipulando Dados em XML

Para o exame, você deve se familiarizar com 5 classes que manipulam XML no .NET Framework: XmlWriter, XmlReader, XmlDocument, XPath e LINQ-to-XML (XElement e XDocument). O exame foca mais em LINQ-to-XML por ser mais recente e elegante, então dê atenção especial a esse tópico.

XmlWriter

XmlWriter é uma classe fácil, antiga e intuitiva de se entender. Você obtém uma instância pelo método estático Create passando um nome de arquivo e chama os métodos WriteStartDocument, WriteStartElement ou WriteElementString, WriteEndElement e WriteEndDocument. Entenda rapidamente como a classe funciona e o XML gerado:

<?xml version="1.0" encoding="UTF-8"?>
<Customers>
<Customer>
<FirstName>John</FirstName>
<MiddleInitial>Q</MiddleInitial>
<LastName>Public</LastName>
</Customer>
<Customer>
<FirstName>Bill</FirstName>
<MiddleInitial>G</MiddleInitial>
<LastName>Ryan</LastName>
</Customer>
<Customer>
<FirstName>William</FirstName>
<MiddleInitial>G</MiddleInitial>
<LastName>Gates</LastName>
</Customer>
</Customers>

XmlReader

XmlReader é a contraparte do XmlWriter, e é também simples de usar. Você cria um XmlReader passando o nome do arquivo que quer ler, faz um while chamando o método Read e faz sua operação olhando para a propriedade NodeType. Uma rápida olhada no código vai deixar as coisas mais claras:

XmlDocument

XmlDocument é o “pai” dos antigos XmlWriter e XmlReader, ainda mais fácil de usar. Para ler um XML, você instancia um novo XmlDocument, chama o método Load apontando para um arquivo ou stream, extrai a lista de nodos (elementos) e itera por eles.

Para escrever um arquivo XML, basta criar elementos com o método CreateElement e dar AppendChild neles, respeitando a regra de que os elementos abertos primeiro devem ser fechados por último.

XPath

XPath, que significa XML Path Language, é um tipo de query para documentos XML. Você obtém a classe XPathNavigator chamando o método CreateNavigator de um XmlDocument.

Considere o seguinte XML:

<?xml version="1.0" encoding="utf-8" ?>
<People>
  <Person firstName="John" lastName="Doe">
    <ContactDetals>
      <EmailAddress>john@unknown.com</EmailAddress>
    </ContactDetals>
  </Person>
  <Person firstName="Jane" lastName="Doe">
    <ContactDetals>
     <EmailAddress>jane@unknown.com</EmailAddress>
      <PhoneNunmber>001122334455</PhoneNunmber>
    </ContactDetals>
  </Person>
</People>

Para obter os elementos Person pelo firstName, você usaria o seguinte código:

LINQ-to-XML

LINQ-to-XML será bastante coberto no exame pois usa bastante os recursos modernos do .NET Framework como método anônimos, genéricos, tipos nullable e a semântica de query LINQ. É bem importante que você conheça bem a sintaxe do LINQ para o exame como um todo.

As classes estão no namespace System.Xml.Linq. Uma das mais importantes é a classe XElement, que tem 5 construtores:

• public XElement(XName someName);
• public XElement(XElement someElement);
• public XElement(XName someName, Object someValue);
• public XElement(XName someName, params Object[] someValueset);
• public XElement(XStreamingElement other);
  /li>

Lembra de como você cria um elemento Customer dentro de Customers com XmlDocument? Veja como se faz com XElement:

XElement customers = new XElement("Customers", new XElement("Customer",
new XElement("FirstName", "John"), new XElement("MiddleInitial", "Q"),
new XElement("LastName", "Public")));

Outra vantagem é que XElement faz o escape automaticamente de caracteres usados na semântica do XML como <, > e &.

Há também a classe XDocument, que representa o documento XML por inteiro. Ela contém as seguintes características:

• Um objeto XDeclaration quer permite a especificação da versão do XML e do encoding;
• Um objeto XElement que serve como raiz;
• Objetos de XProcessingInstruction que representam instruções de processamento do XML;
• Objetos de XComment que representam comentários.

Você pode instanciar um XAttribute da seguinte forma: XAttribute sampleAttribute = new XAttribute("FirstName", "John");.

Namespaces, representados pela classe XNamespace , são usados assim:

XNamespace billCo = "http://www.billco.com/Samples";
XElement firstNameBillCo = new XElement(billCo + "FirstName", "John");

As coisas começam a ficar mais difíceis nas queries com LINQ, e isso é uma coisa que “can’t be emphasized enough”: é muito importante saber LINQ e suas nuances, não só para esse objetivo.

Uma característica é entender a diferença entre os métodos Descendants e Elements de um XContainer. Considere o seguinte código:

O output de ambos os casos é 3. Inicialmente eles podem parecer idênticos, mas eles têm uma grande diferença. O método Descendants nesse caso procura por elementos Customer em qualquer nível abaixo do XContainer que o chamou, nesse exemplo o Root. Já o Elements procura por elementos Customer apenas um nível abaixo do XContainer. Nesse caso ele encontra os três elementos Customer pois o Root é o elemento Customers. Se a estrutura fosse como abaixo, por exemplo, o método Elements não encontraria nenhum elemento Customer:

<Root>
<Customers>
<Customer><FirstName>John</FirstName></Customer>
<Customer><FirstName>Bill</FirstName></Customer>
<Customer><FirstName>Joe</FirstName></Customer>
</Customers>
</Root>

Manipulação Avançada de XML

Nessa seção do objetivo, a ideia é ter mais questões de manipulações e queries com LINQ-to-XML.

Um ponto a destacar é que você deve conhecer a classe XmlConvert para dar escape de caracteres especiais se você não estiver usando uma classe que faz isso para você, como XElement. XmlConvert é irmã da classe Convert, focada para XML. Ela automaticamente faz o escape de caracteres reservados e provê vários métodos de conversão para arquivos XML.

A lista abaixo contém os métodos não óbvios como ToInt32, ToDateTime, etc. e seus comportamentos:

• DecodeName: faz o decode de um nome encodado;
• EncodeName: faz o encode de uma string para que possa ser usada como um nome de nodo XML;
• EncodeLocalName: faz o mesmo de EncodeName, com uma diferença: encoda também o caracter “:”, assegurando que o nome pode ser usado em elementos que contenham namespace;
• EncodeNmToken: retorna um nome válido para um nodo de acordo com a XML Language Spec;
• IsStartNCNameChar: determina se o parâmetro não é o caracter “:”;
• IsPublicIdChar: determina se o parâmetro é um identificador XML público (algumas magic strings que existem por legado);
• ToDateTimeOffset: converte para DateTimeOffset, um DateTime com identificador em relação ao UTC.

Segue um código de aplicação dos métodos mais relevantes da classe XmlConvert (DecodeName, EncodeName e EncodeLocalName):

Um último ponto desse objetivo como um todo é que você pode usar diferentes classes do .NET Framework para lidar com o mesmo XML. Você pode juntar implementações onde julgar necessário; usar uma metodologia não te força a usá-la até o fim.

Esse foi o último objetivo do primeiro grande tópico da certificação, Accessing Data. O próximo post será sobre o primeiro objetivo do segundo tópico da certificação, Querying and manipulating data by using the Entity Framework.

Obrigado pela leitura e até mais!

Leia Mais

A discussão sobre WCF Data Services no objetivo 1.1 foi curta porque há um objetivo específico para ele, o Create and implement a WCF Data Services service, que será coberto nesse post.

Esse objetivo cobre como endereçar recursos, criar uma query, acessar formatos de carga (incluindo JSON) e trabalhar com interceptores e operadores de serviço. Vamos lá?

Endereçando Recursos

Para criar um WCF Data Service, basicamente você deve seguir os seguintes passos:

• Criar uma aplicação ASP.NET (para hostear o Data Service);
• Usar o EF para criar seu EntityModel;
• Adicionar um WCF Data Service;
• Especificar um tipo para o serviço (que é o nome do model container do projeto do EF);
• Habilitar acesso ao Data Service configurando explicitamente algumas propriedades do DataServiceConfiguration (SetEntitySetAccessRule, SetServiceOperationAccessRule e DataServiceBehavior)

Quando você adicionar um WCF Data Service, você verá classes geradas assim: public class ExamSampleService : DataService. Essas classes herdam de System.Data. Services.DataService, que recebem um tipo genérico. O código gerado terá também o método InitializeService com alguns comentários que ajudam na sua configuração:

// This method is called only once to initialize service-wide policies.
public static void InitializeService(DataServiceConfiguration config) {
// TODO: set rules to indicate which entity sets and service operations are visible, updatable, etc.
// Examples:
// config.SetEntitySetAccessRule("MyEntityset", EntitySetRights.AllRead);
// config.SetServiceOperationAccessRule("MyServiceOperation", ServiceOperationRights.All); config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
}

Como já citado, é importante se familiarizar com os métodos SetEntitySetAccessRule e SetServiceOperationAccessRule e a propriedade DataServiceBehavior.MaxProtocolVersion.

SetEntitySetAccessRule

Esse método recebe dois parâmetros: uma string com o nome do EntitySet e um enum EntitySetRights. Como o enum é decorado com Flags, você pode passar mais de um valor dessa forma: config.SetEntitySetAccessRule("Courses", EntitySetRights.AllRead | EntitySetRights.WriteMerge);. Os possíveis valores desse enum são:

• None: todos os acessos são revogados;
• ReadSingle: um item pode ser lido;
• ReadMultiple: sets de dados podem ser lidos;
• WriteAppend: novos itens podem ser adicionados;
• WriteReplace: dados podem ser atualizados;
• WriteDelete: dados podem ser deletados;
• WriteMerge: dados podem ser mergeados;
• AllRead: tudo pode ser lido;
• AllWrite: tudo pode ser escrito;
• All: todas as operações são permitidas.

SetServiceOperationAccessRule

Esse método dá permissões para uma ServiceOperation e funciona da mesma forma que o método SetEntitySetAccessRule, mas o enum é um ServiceOperationRights. Os valores desse enum são:

• None: todos os acessos são revogados;
• ReadSingle: um item pode ser lido;
• ReadMultiple: sets de dados podem ser lidos;
• AllRead: um e vários itens podem ser lidos;
• All: todos os direitos são garantidos;
• OverrideEntitySetRights: indica se sobrescreve os valores configurados em SetEntitySetAccessRule.

DataServiceBehavior.MaxProtocolVersion

Essa propriedade indica qual versão do protocolo OData será usado no serviço. Os possíveis valores do enum DataServiceProtocolVersion são V1 e V2.

Criando Uma Query

Uma das principais vantagens do WCF Data Services é que seus recursos são endereçáveis por URIs via OData, e você pode fazer queries nas URIs de uma forma bem simples.

Suponha que você criou um WCF Data Service com o nome ExamPrepService baseado num Entity Model que tem tópicos, questões e respostas como entidades.

Para obter todos os registros de uma entidade, a query Service/EntitySetName pode ser usada. Para obter todos os tópicos do serviço, por exemplo, a seguinte query pode ser usada:
http://servicehost/ExamPrepService.svc/Topics

A query Service/EntitySetName(‘KeyValue’) retorna a entidade que tem uma key com o valor passado. Por exemplo, para obter o tópico que tem o nome First, a query fica http://servicehost/ExamPrepService.svc/Topics('First').

Se você precisa somente da propriedade Description, a query fica http://servicehost/ExamPrepService.svc/Topics('First')/Description. Se quiser somente o valor primitivo e não o XML, basta adicionar /$value no final: http://servicehost/ExamPrepService.svc/Topics('First')/Description/$value.

As queries funcionam bem com relacionamentos, se esses estiverem definidos no Entity Model. Para obter todas as Answers da Question com a key 1, por exemplo, a seguinte query deve ser usada:
http://servicehost/ExamPrepService.svc/Questions('1')/Answers

O caminho inverso também é possível: http://servicehost/ExamPrepService.svc/Answers('1:4')/Question.

Até agora, só filtramos os resultados pela key da entidade. Mas o protocolo OData e o WCF Data Service oferecem várias opções de query que se traduzem em queries SQL. É bem importante entender o efeito de todos eles no resultado.

• $orderby: define uma ordem para o resultado. Uma ou mais propriedades podem ser usadas, separadas por vírgula: /Questions?$orderby=Id,Description;
• $top: define quantos resultados serão retornados: /Questions?$top=5
• $skip: indica quantos registros devem ser ignorados. Suponha que há 30 tópicos, mas você quer ignorar os 10 primeiros e os 10 últimos. A query fica assim: /Questions?$skip=10&$top=10;
• $filter: especifica uma ou mais condições: /Questions?$filter=Id gt 5;
• $expand: indica quais entidades relacionadas serão retornadas: /Questions?$expand=Answers;
• $select: por padrão, todas as propriedades de uma entidade são retornadas. Usando $select, você pode especificar quais propriedades serão retornadas separando por vírgula: /Questions&$select=Id,Text,Description,Author;
• $inlinecount: retorna o número de registros retornados no elemento <count>: /Questions?$inlinecount=allpages.

Você também pode executar queries por meio de código usando a classe DataServiceQuery:

String ServiceUri = "http://servicehost/ExamPrepService.svc";
ExamServiceContext ExamContext = new ExamServiceContext(new Uri(ServiceUri); DataServiceQuery = ExamContext.Question
.AddQueryOptions("$filter", "id gt 5")
.AddQueryOptions("$expand", "Answers");

Acessando Formatos De Carga

o WCF Data Service dá suporte aos formatos Atom e JSON de forma fácil.

Basta usar a opção $format na query com o valor atom ou json. Caso esteja consultando via WebClient ou queira especificar isso em um request header, funciona da mesma maneira. Para JSON, coloque o header Content-Type para application/json. Para Atom, application/atom+xml.

Trabalhando Com Interceptor e Service Operator

O WCF Data Service permite que você intercepte um request para prover uma lógica customizada.

Há dois tipos de Interceptors: ChangeInterceptor, que serve para interceptar operações NON-Query, e QueryInterceptor, que intercepta operações de Query.

ChangeInterceptors têm retorno nulo e aceitam dois parâmetros: o tipo da entidade e um UpdateOperations, que referencia o request. A definição de um método ChangeInterceptor fica assim:

[ChangeInterceptor("Topics")]
public void OnChangeTopics(Topic topic, UpdateOperations operations)


QueryInterceptors são decorados com QueryInterceptor e retornam uma Expression>, que servem como filtro para a entidade. A assinatura fica assim:

[QueryInterceptor("Topics")]
public Expression> FilterTopics(){}

A dica para o exame é que, para identificar se um método é ChangeInterceptor ou QueryInterceptor, basta olhar para o tipo do retorno.
Para saber qual Interceptor deve ser implementado para fazer alguma coisa, é necessário saber o comportamento e determinar se é uma operação NON-Query ou Query. Por exemplo, DeleteTopics seria um ChangeInterceptor; já um método GetAdvancedTopics seria um QueryInterceptor.

Qualquer dúvida, fique à vontade para fazê-la nos comentários.
Fique ligado para o post do próximo objetivo, Manipulate XML data structures.

Até mais!

Leia Mais

Olá pessoal! Vamos ao primeiro (e um dos poucos) objetivo que fala de Azure na certificação de Azure, o Implement data storage in Windows Azure. Para acompanhar os objetivos já postados, clique aqui.

O primeiro tópico desse objetivo é sobre armazenamento de dados. Comparado com mecanismos de armazenamento de dados tradicionais, as soluções do Azure oferecem um suporte bem parecido com o que já existe. Mas é claro que coisas novas geram mudanças, ainda mais com um paradigma mais recente que é a nuvem. Por exemplo, acesso à internet é fundamental para que qualquer armazenamento no Azure funcione.

As opções de armazenamento de dados no Azure são: Local Storage; Blob, Table e Queue (fazendo parte do Windows Azure Storage); e SQL Database. Para o exame, é bem provável que você encontre alguma pergunta onde um cenário é dado e você deve escolher quais desses itens resolveriam o problema. Vamos às explicações básicas: quando você ler vídeo, áudio ou imagem, a pergunta está se tratando de Blob. Quando é algum dado estruturado, pode ser Table ou SQL Database, se a estrutura for relacional. Queue se trata de garantir um mecanismo de envio de mensagens em fila. Local Storage é um armazenamento temporário igual a um sistema de arquivos. Vamos nos aprofundar na implementação desses itens.

Blob Storage

A estrutura de Blob foi feita para armazenamento de dados binários, como os já mencionados vídeo, áudio e imagem. É possível também armazenar um arquivo Excel como binário sem nenhum problema. Um dos principais benefícios é que as informações são acessíveis via HTTP. Basta ter a URL e você pode acessar uma imagem, por exemplo. Os arquivos podem ter o tamanho de até 100 TB. Acho que já deu para entender o conceito, mas as coisas ideais de serem armazenadas em Blob são: imagens que podem ser vistas diretamente no browser, documentos, backups de banco de dados, vídeos e áudios.

A estrutura do Blob funciona assim: no nível mais alto está a Storage Account. Dentro dela temos Containers e, dentro dos Containers, Blobs. Há o limite de 100 TB em uma Storage Account, porém ela pode ter quantos Containers forem necessários. Pense em um Container como um subdiretório para organizar os blobs (a diferença é que Containers não podem conter Containers). Um Blob é um arquivo, sem restrição de formato. Há duas categorias de Blobs: Block (limite de 200 GB) e Page (limite de 1 TB).

Você pode acessar um Blob de duas formas. A primeira, como citado, é por uma URL HTTP. A URL tem o seguinte formato: http://.blob.core.windows.net/{container}/{blob}.

A segunda maneira é pela API do Azure SDK. Você deve adicionar uma referência ao assembly Microsoft.WindowsAzure.Storage.dll. A Storage Account é representada pela classe CloudStorageAccount. Para instanciá-la, você pode usar um de seus dois construtores. O primeiro recebe uma StorageCredentials e três URIs representando o endpoint do Blob, Queue e Storage, nessa ordem. O segundo construtor recebe uma StorageCredentials e um bool que indica se será utilizado HTTPS. Vamos ao código:

Outra maneira (bem melhor) de instanciar a classe CloudStorageAccount é usando o método estático Parse ou TryParse, que possui dois overloads: é possível usar a classe CloudConfigurationManager e chamar o método GetSetting(), que obtém a informação do arquivo .CSCFG do seu projeto Windows Azure Cloud, ou passar somente uma connection string no formato certo (<add name=”StorageConnection” connectionString=”DefaultEndpointsProtocol=https;AccountName=ACCOUNT_NAME_GOES_HERE;AccountKey=ACCOUNT_KEY_GOES_HERE” />).

Depois de instanciada a classe CloudStorageAccount, você precisa criar um CloudBlobClient e obter uma referência ao CloudBlobContainer. Lembre-se de que há dois tipos de Blobs e cada um tem seu método para obter a referência (GetBlockBlobReference e GetPageBlobReference).

Do Container é possível obter a referência para o blob desejado e salvar o conteúdo do arquivo chamando o método UploadFromStream. Há outros dois métodos para realizar o upload (UploadFromByteArray e UploadFromFile). Todos eles sobrescrevem os dados se eles já existirem e têm sua versão assíncrona (com Async no final do nome), o que é ideal para fazer o upload de Blobs grandes. É também recomendado envolver a chamada de qualquer Upload em um try/catch para tratar quaisquer erros de rede. Para fazer o download de um Blob, basta chamar o método DownloadToStream. Para deletar um Blob, há os métodos Delete e DeleteIfExists.

A criação padrão de um Container é com acesso privado. Você pode mudar a permissão chamando o método SetPermissions de um CloudBlobContainer, passando um BlobContainerPermissions com PublicAccess habilitado, por exemplo. Você pode também distribuir assinaturas de acesso temporárias com o método GetSharedAccessSignature, tanto de um Container quanto de um Blob.

Table e Queue Storage

Uma Table storage serve armazenar dados não relacionais, como os bancos de dados NoSQL (CouchDB ou MongoDB, por exemplo). Uma Queue storage serve para armazenar mensagens no esquema de fila, onde o primeiro item que entra é o primeiro a sair (FIFO, First In First Out). Queues são úteis em sistemas de entrega de mensagens ou longos processamentos.

As APIs de Table e Queue são bem parecidas com as do Blob. Você instancia a classe CloudStorageAccount, chama o método CreateCloudTableClient ou CreateCloudQueueClient e voilà. Tables e Queues são sempre privadas.

Queues são mais simples porque não há métodos de busca. Além de poder obter uma quantidade aproximada de itens na fila, basicamente há métodos para colocar e obter mensagens da fila (push-and-pop). Um aspecto interessante é que obter uma mensagem da fila não a remove completamente, só a deixa invisível por um período de tempo (1 minuto por padrão). Se seu processamento demorar mais do que esse tempo, você deve atualizar o status da mensagem como escondida para que outros processos não a vejam na fila. Após terminar seu processamento, aí sim você pode deletar a mensagem da fila.

Tables são um pouco mais interessantes pois é possível interagir com os dados. O jeito principal de obter um registro é executar uma TableOperation, mas você pode obter vários registros com uma TableQuery. Vamos a um trecho de código que adiciona um registro, obtém esse registro e o deleta. Note que a classe Record herda de TableEntity, sendo possível criar classes que representam os dados na Table.

Distribuição de Dados Usando Windows Azure Content Delivery Network (CDN)

O Windows Azure Content Delivery Network (CDN) é uma maneira de cachear conteúdos estáticos (Blobs). A ideia é usar uma localidade próxima ao client para melhorar a performance e largura de banda. Os dois principais benefícios, segundo a MSDN, são:

• Melhorar a performance para usuários que estão longe da fonte de conteúdo e estão utilizando aplicações que necessitam de muitas requisições;
• Escalar a distribuição para lidar melhor com uma alta carga instantânea, como um lançamento de produto.

Para usar o CDN, você deve habilitar no portal do Azure. Depois, o CDN vai funcionar assim: quando um request for feito para um Blob, ele vai redirecionar transparentemente o request para a localização mais próxima, para evitar uma viagem muito grande. O primeiro request será feito normalmente, mas os próximos serão cacheados naquela região. O tempo de expiração é importante, pois como os itens são cacheados, alguns problemas podem acontecer caso o item seja atualizado frequentemente. O que controla o tempo de expiração é a configuração Time To Live (TTL) no portal.

Para deixar um conteúdo disponível para CDN, ele deve estar em um container público e disponível para acesso anônimo. Containers públicos podem ser setados via API, como citado acima. A propriedade PublicAccess deve ser configurada como BlobContainerPublicAccessType.Container.

Com tudo configurado, basta acessar o Blob. A URL tradicional vai funcionar normalmente (http://.blob.core.windows.net/{container}/{blob}), mas uma nova URL ficará disponível pelo CDN: http://.vo.msecnd.net/{container}/{blob}.

Só relembrando: quanto mais um item for dinâmico, menos provável que ele seja um bom candidato para usar CDN, por causa do cache.

Windows Azure Caching

Cacheamento no nível do Windows Azure é bem diferente do que temos em nível de aplicação, como nesse objetivo. Esse cacheamento é role-based, ou seja, disponível em qualquer role no Windows Azure.

Há dois mecanismos: dedicated topology e co-located topology. Em uma dedicated topology, você define uma role que será especificamente designada para lidar com cache, por exemplo, toda a memória de uma Worker Role. Em um cenário de co-located topology, apenas parte dos recursos podem ser utilizado para cache. Caso você tenha 4 Worker Roles, por exemplo, pode usar 25% de cada para lidar com cache.

Existe também um serviço opcional chamado Windows Azure Shared Caching. Diferente dos anteriores, ele existe em nível de serviço, e não de role.

Lidando Com Exceções Usando Retries (SQL Database)

SQL Database, sendo um banco de dados na nuvem, tem vários benefícios como escalabilidade e facilidade de configuração. Uma desvantagem é que, com a distância física entre o servidor de aplicação e o de banco de dados, a latência aumenta, podendo causar timeouts na conexão com o banco. Como esse erro é temporário, faz sentido ter uma lógica de retentativa (retry) nas conexões com o banco de dados.

O Azure oferece um framework para implementação de lógicas de retentativa. Segue um código de retentativa em deadlocks e timeouts com ADO.NET:

Isso é tudo para esse objetivo 🙂 Obrigado pela leitura e fique ligado no post do próximo objetivo, Create and implement a WCF Data Services service.
Até lá!

Leia Mais

Olá pessoal! Nesse post vou falar sobre o objetivo 1.3 do exame de certificação Microsoft 40-487, Implement transactions. Para acompanhar desde o começo e ver os primeiros posts, clique aqui.

Para o exame, é necessário que você saiba características gerais de transações e como implementá-las com ADO.NET e Entity Framework. Vamos lá?

Entendendo Transações

Basicamente, transações servem para fazer os dados do banco de dados serem consistentes. Elas são necessárias em caso de falha no meio de uma execução de comandos, servindo para que todos eles sejam revertidos. Por exemplo, ao tentar fazer a inserção de uma Account e depois uma AccountDetails, as duas inserções devem ser feitas com sucesso para que não haja um registro de AccountDetails sem Account e vice-versa. Entender esse conceito é fundamental para esse objetivo.

Outro aspecto importante de transações é se elas são simples ou distribuídas. Essencialmente, uma transação simples envolve apenas um banco de dados, enquanto uma distribuída envolve diversos bancos de dados, provavelmente de aplicações diferentes. Uma limitação da classe System.Data.SqlClient.SqlTransaction é que ela só trabalha com bancos de dados SQL Server.

Há também o conceito de nível de isolamento (isolation level) de uma transação. O enum IsolationLevel serve para controlar o comportamento de lock na execução de um comando. Esse enum existe em dois namespaces (System.Data e System.Transaction), mas ambos fazem a mesma coisa e têm os mesmos valores. A diferença apenas é que eles trabalham com as classes dos seus respectivos namespaces. O IsolationLevel pode ser mudado durante a execução da transação sem problemas. Vamos ao valores e comportamento deles:

• Unspecified: Não determinado. O nível de isolamento será determinado pelo driver do banco de dados.
• Chaos: As alterações pendentes de transações mais altamente isoladas não podem ser substituídas. Esse valor não é suportado no SQL Server ou Oracle, por isso tem uma utilização bem limitada.
• ReadUncommitted: Nenhum shared lock é emitido. Isso implica que a leitura pode ser imprecisa, o que geralmente não é desejado.
• ReadCommitted: Emite shared locks nas leituras. Isso evita leituras imprecisas, mas os dados ainda podem ser mudados antes do fim da execução da transação. Pode resultar em nonrepeatable reads ou phantom data.
• RepeatableRead: Locks são colocados em todos os dados usados na query, o que previne quaisquer alterações durante a execução da transação. Isso acaba com o problema de nonrepeatable read, mas phantom data ainda pode ocorrer.
• Serializable: Um range lock é colocado em um específico DataSet, o que previne quaisquer inserções ou alterações até que a transação termine. Deve ser usado rapidamente.
• Snapshot: Uma cópia dos dados é feita, então uma execução de transação pode ler enquanto outra pode modificar os mesmos dados. Não é possível ver os dados de outras execuções de transações, mesmo rodando a query novamente. O tamanho disso pode também causar problemas se não for usado rapidamente.

Implementando Transações com TransactionScope (System.Transactions)

TransactionScope é simples e poderoso. Vamos ao código e algumas características importantes:

• O método Complete() faz com que todas as alterações sejam comitadas. Se não for chamado, todas elas são desfeitas.
• Caso alguma Exception seja lançada dentro do bloco using, todas as alterações serão desfeitas também.
• A transação é promovida de simples para distribuída automaticamente quando a segunda SqlConnection é aberta.
• Mesmo numa transação distribuída, há algumas limitações óbvias. Cópias de arquivos e chamadas para web services, por exemplo, não são revertidas (alguns web services podem até suportar transações, mas isso não acontece automaticamente). Há também o requerimento de que o banco de dados suporte transações, o que não acontece com todos.

Implementando Transações com EntityTransaction

Você pode implementar transações com a classe EntityTransaction para as classes EntityCommand e EntityConnection. Ela tem duas principais propriedades: Connection e IsolationLevel. Tem também dois métodos importantes e óbvios: Commit() e Rollback().

Um ponto não óbvio e importantíssimo é que, usando DbContext ou ObjectContext (explicados aqui), não é necessário usar a classe EntityTransaction. Em qualquer DbContext.SaveChanges(), por exemplo, o Entity Framework usa uma transação para salvar todas as modificações feitas. Caso aconteça algum erro, uma Exception é lançada e todas as alterações são desfeitas.

Caso queira usar a classe EntityTransaction para explicitamente fazer uma transação, o caminho é bem simples. Basta criar uma EntityCoonnection, declarar uma Entity Transaction chamando BeginTransaction() e, no final, chamar o método Commit() ou Rollback(). Segue o código:

Implementando Transações com SqlTransaction

O comportamento de uma SqlTransaction é quase idêntico ao de uma EntityTransaction. As mudanças estão nos nomes dos objetos e seus tipos.

Você deve criar uma SqlConnection, chamar o método BeginTransaction() passando um IsolationLevel e criar um ou mais SqlCommands passando como parâmetro o CommandText, a SqlConnection e a SqlTransaction. Ao invés de um CommandText, também é possível passar o nome de uma Stored Procedure e mudar o tipo do CommandType para StoredProcedure.

Depois de toda a lógica feita, basta chamar o método Commit() ou Rollback().

Uma última dica para o exame: se você for perguntado qual é o melhor cenário para aplicar uma transação entre uma query longa que envolve várias tabelas e uma query rápida que envolve uma tabela, escolha a última opção. Embora aparentemente uma query que envolve várias tabelas pareça o ideal, o livro alega que a duração e complexidade geraria colocaria problemas de lock e contenção. Então tá, né?

O próximo post será sobre o objetivo 1.4, Implement data storage in Windows Azure.
Até lá!

Leia Mais

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