Para a criação do nosso exemplo, manteremos o padrão utilizado pelo EF para
esta geração;
public virtual ICollection<Posts> Posts { get; set; }:
em uma ferramenta tradicional para composição de banco de dados re-
lacionais, conseguimos explicitar os relacionamentos de 1 para muitos ou
muitos para muitos de forma bem simples. Para expressar esse tipo de rela-
cionamento através de code first, utilizamos uma coleção de objetos tipada;
justamente o que estamos fazendo com a linha em destaque neste tópico.
Estamos dizendo ao EF que uma Categoria deverá suportar múltiplos
Posts. Legal, não?!
Para que a classe Categorias possa existir, é preciso que Posts também
exista. Desta forma, você pode conferir através da listagem 5 a estrutura da classe Posts.
Listagem 4.5 - Classe POCO que representa Posts:
public class Posts
{
[Key]
51
4.3. O Entity Framework
Casa do Código
public long PostID { get; set; }
public string TituloPost { get; set; }
public string ResumoPost { get; set; }
public string ConteudoPost { get; set; }
public DateTime DataPostagem { get; set; }
public int CategoriaID { get; set; }
[ForeignKey("CategoriaID")]
public virtual Categorias Categorias { get; set;
}
A observação válida em relação à listagem 5 fica por conta da última propriedade.
Diferentemente da classe Categorias onde possuímos uma coleção de objetos
(sim, uma Categoria pode possuir vários Posts), aqui, possuímos uma instância
de Categoria, já que, pela definição da regra de negócio, um Post pode pertencer a apenas uma Categoria. O atributo [ForeignKey("CategoriaID")], como você já deve estar imaginando, informa ao EF que a propriedade imediatamente a seguir assumirá o comportamento de chave estrangeira e que, portanto, será o elo com outra tabela em nosso caso, a tabela Posts.
Para que a engine do Entity Framework possa ser capaz de gerar a estrutura
de banco de dados com base nas classes POCO, é preciso que exista uma classe de amarração, na qual são informados parâmetros cruciais no processo de geração
da estrutura final. Esta classe foi convencionada pelo EF como classe de contexto.
Nela, implementamos algumas ações que são fundamentais para que tudo funcione
de forma adequada. Confira o código apresentado pela listagem 6.
Listagem 4.6 - Classe de contexto para o Entity Framework:
public class BlogContext : DbContext
{
public DbSet<Posts> Posts { get; set; }
public DbSet<Categorias> Categorias { get; set; }
}
52
Casa do Código
Capítulo 4. Models: Desenhando os modelos da nossa aplicação
A classe de contexto a qual nos referimos foi criada nos mesmos moldes das
demais apresentadas até aqui. Em se tratando de modelos de dados, evidentemente está dentro do diretório Models.
Esta é a estrutura mais simplificada possível para a classe de contexto. Aqui
estamos dizendo ao EF, através das diretivas DbSet, que as classes Posts e Categorias deverão ser criadas no banco de dados de destino.
Uma pergunta que naturalmente surge neste ponto é: O banco de dados será
criado em qual servidor?.
Esta é uma pergunta interessante e a resposta está diretamente atrelada ao mo-
delo de convenções do qual falamos no segundo capítulo. Por padrão, seguindo uma convenção do EF e não do ASP.NET MVC, se nenhuma string de conexão com o servidor de destino for informada para o ORM, no momento da criação, o EF criará a estrutura de banco de dados no SQL LocalDB ou Express Edition. Aquele que estiver disponível se ambos estiverem disponíveis, LocalDB será a escolha.
Se for preciso apontar a criação da estrutura de banco de dados para um
servidor específico, uma das possibilidades disponíveis para se realizar tal operação é através da implementação de um método construtor na classe BlogContext. A
listagem 7 apresenta esta alteração.
Listagem 4.7 - Classe de contexto adaptada para utilizar um servidor especí-
fico:
public class BlogContext : DbContext
{
public BlogContext() : base("name=BlogContext")
{
Database.Connection.ConnectionString =
@"data source=FABRCIOSANC36FC\SQLEXPRESS;
initial catalog=BlogBDLivro; Integrated Security=SSPI";
}
public DbSet<Categorias> Categorias { get; set; }
public DbSet<Posts> Posts { get; set; }
}
A mudança em relação à listagem 6 anterior é simples: adicionamos o método
construtor da classe de contexto e, em seu interior, apontamos a engine do Entity 53
4.3. O Entity Framework
Casa do Código
Framework para o servidor local FABRCIOSANC36FC\SQLEXPRESS para a criação
do banco de dados BlogBD.
Testando a funcionalidade do code first
Agora que já possuímos a infraestrutura necessária para a aplicação exemplo,
podemos dar o passo no sentido de ver o Entity Framework code first funcionando.
Para isso, criaremos dois novos controllers: Categorias e Posts. Para cada um
deles, criaremos operações de CRUD (acrônimo para Create, Read, Update e Delete) utilizando um recurso muito interessante disponível desde a versão 2 da framework MVC: Scaffold.
Mais sobre Scaffold
Scaffold é o recurso do ASP.NET MVC que permite criar operações