adiciona automaticamente um arquivo com a extensão .edmx e este grande arquivo é o objeto final do mapeamento realizado. Agrupam-se, portanto, todas as classes necessárias para o trabalho com o banco de dados.
A figura 4.14 apresenta a estrutura do arquivo edmx gerado. Com um duplo
clique sobre as classes, é possível visualizar suas estruturas, que seguem fielmente o modelo físico do banco de dados.
67
4.5. Banco de dados primeiro?
Casa do Código
Figura 4.14: A estrutura do arquivo EDMX
Outra mudança que pode ser percebida na estrutura da aplicação, mas que não
é visível através da solution explorer, é a adição da string de conexão no arquivo Web.config, conforme ilustra a listagem 9.
Listagem 4.9 - Adição da string de conexão no arquivo Web.config pelo Entity
Framework:
<connectionStrings>
<add name="EntidadesCadeMeuMedicoBD"
connectionString="metadata=res://*/Models.ModeloDeDados.csdl|
res://*/Models.ModeloDeDados.ssdl|
res://*/Models.ModeloDeDados.msl;provider=System.Data.SqlClient;
provider connection string="
data source=.\SQLEXPRESS;initial catalog=CadeMeuMedicoBD;
integrated security=True;
MultipleActiveResultSets=True;App=EntityFramework""
providerName="System.Data.EntityClient" />
</connectionStrings>
Pronto. Neste momento, temos tudo o que precisamos para conseguir trabalhar
com o banco de dados tendo como foco o modelo recém-gerado. Para este capítulo, já reunimos toda informação necessária para seguir com os próximos passos. À medida que a aplicação for ganhando forma, você entenderá como se dá o processo de interação com o modelo que criamos aqui.
68
Casa do Código
Capítulo 4. Models: Desenhando os modelos da nossa aplicação
4.6
Model first x Code first: Quando utilizar um
ou outro?
Nas seções anteriores, apresentamos os dois modelos de trabalho mais usuais quando o ORM em questão é o Entity Framework. Levando-se em consideração o fato de
que ambos os modelos são funcionais e objetivam a mesma coisa (isto é, manipular dados), uma pergunta natural surge na cabeça de grande parte dos desenvolvedores:
quando utilizar a abordagem X ou Y?
Como é de se esperar
para perguntas deste tipo, a resposta mais prudente é: depende.
Existem diversos aspectos que devem ser considerados em um projeto de soft-
ware ao se optar por determinada tecnologia e/ou metodologia. Alguns dos que devem ser considerados são: robustez, conectividade, segurança, performance e produtividade. Isso sem falar na preferência do gestor do projeto atrelado ao expertise de seu time.
Quando falamos de estratégia de acesso a dados utilizando EF, os aspectos men-
cionados também são decisivos. Assim, se não podemos dar uma resposta defini-
tiva para a pergunta inicial desta seção, podemos ao menos apresentar vantagens e desvantagens de cada modelo para que você possa reunir insumos para escolher de forma mais assertiva a estratégia de acesso a dados para sua aplicação.
Code first: vantagens e desvantagens
Quando falamos em um modelo em que o código da aplicação poderá gerar a
estrutura do banco de dados, imediatamente algumas características positivas já nos vêm a cabeça, certo? Vamos a elas:
Isolamento do código fonte da aplicação em relação ao banco de dados: esta é, sem dúvida, a grande vantagem do EF code first. Como o modelo é todo
baseado em classes e seus respectivos objetos, é possível que desenvolvedores
consigam criar aplicações com estruturas de bancos de dados complexas sem
escrever uma linha sequer de SQL (Structured Query Language);
Produtividade: como o modelo de desenvolvimento proporcionado pelo code first é bem familiar, de forma geral, é possível obter boa produtividade por
parte dos desenvolvedores;
Código limpo: a criação das classes POCO ajudam a manter o código limpo, 69
4.6. Model first x Code first: Quando utilizar um ou outro?
Casa do Código
uma vez que os desenvolvedores podem seguir os padrões de desenvolvimento
de seus projetos;
Controle completo de código: como as classes POCO são criadas e mantidas pelo próprio desenvolvedor, o controle sobre aquilo que é gerado no banco
de dados é bem mais fácil de ser realizado. Classes geradas automaticamente
tendem a ser de difícil manutenção;
Simplicidade: de forma geral, o trabalho com code first tende a ser mais simples. Isso porque não existe a necessidade de se manter um arquivo .edmx.
Qualquer problema gerado neste arquivo implicará necessariamente em pro-
blemas com a engine de acesso a dados.
Mas nem tudo são flores. Code first possui um problema intrínseco, proveni-
ente do seu esquema de trabalho que limita sua utilização em boa parte dos projetos: de forma geral, ele pode ser aplicado apenas a novos projetos, já que, dependendo da complexidade do banco de dados de aplicações já existentes, fica inviável gerar classes POCO manualmente para obter a equivalência no banco de dados físico.
Dica: Se um novo projeto for seu objeto de estudo, considere utilizar o modelo code first. Os resultados deste tipo de abordagem para esta natureza de projeto cos-tumam render excelentes frutos.