Devemos usar o Entity Framework?

Atualmente, temos a seguinte pilha:

• VS 2005
• Formulários da Web
• SQL Server 2005
• IIS 6

Estamos planejando fazer a transição para isso:

• VS 2010
• MVC e Web Forms
• SQL Server 2008
• IIS 7

Minha pergunta é: quando passamos para o MVC com o VS 2010, devemos usar o Entity Framework (ou outro ORM), um micro ORM (como Massive ) ou simplesmente SQL?

Todos os tutoriais que li sobre o VS 2010 são todos voltados para o uso do Entity Framework para transações de dados, mas isso estará disponível no futuro próximo (mais de 5 anos)?

Se isso for importante, os aplicativos de nossos clientes podem ter de 10 a 1.000 usuários ativos.

Recentemente, mudei de usar consultas SQL em linha para usar EF e eis o que encontrei:

Prós

• Muito mais rápido para criar o DAL (adoro não escrever as consultas SQL!)
• Muito mais fácil de manter
• Não preciso mais me lembrar de analisar minha entrada antes de criar uma instrução sql em linha, o que significa menos chances de um ataque de injeção SQL (é claro, ainda é possível dependendo das suas consultas, mas muito menos provável)

Contras

• Não é possível estender vários bancos de dados ... pelo menos não facilmente
• Todas as entidades (tabelas, visualizações etc.) precisam de uma chave primária
• Se você deseja atualizar uma única coluna em uma tabela de mais de 100 colunas necessárias (não o design da minha tabela), você deve puxar para baixo todas as 100 colunas para fazer a atualização. Ou use um procedimento armazenado.
• Eu tive problemas com alguns valores padrão definidos no servidor SQL que não são atraídos para o modelo de entidade após a adição de um novo registro. Geralmente, isso ocorre com valores computados ou valores adicionados em um acionador INSERT
• Ocasionalmente, as consultas SQL são mal gravadas e demoram para serem executadas. Se você tiver uma consulta de execução lenta, execute um rastreamento SQL para ver o que a EF está fazendo. É possível que você possa refazer essa consulta como SP ou View. Isso não acontece com muita frequência.
• Eu tive alguns problemas ao tentar criar uma associação entre tabelas que não possuem uma chave estrangeira definida no SQL Server. Geralmente é porque estou tentando criar um 1:0-1relacionamento em que a EF queira usar um1:0-*

Eu não sou especialista em EF, então provavelmente perdi algumas coisas. Esses são apenas os itens que eu sei que contei no passado ao alternar do SQL embutido para o Entity Framework. Estou feliz por ter mudado, mas houve momentos em que odiei a EF devido às suas peculiaridades.

O Entity Framework é uma ferramenta de produtividade. A menos que você tenha um bom motivo para não fazê-lo (por exemplo, você está no SQL 2000 ou não tem tempo para aprimorar a tecnologia), use as melhores ferramentas à sua disposição.

Dito isto, acho que o conceito de Entidades se traduz muito bem no Modelo do padrão MVC. Embora ter um relacionamento 1: 1 com modelos e tabelas seja uma prática ruim, pensar em termos de entidades tende a produzir designs limpos e fáceis de ler código (especialmente com LINQ).

O Entity Framework é suportado ativamente pela Microsoft. Ninguém tem uma bola de cristal mágica para dizer "o suporte durará X anos". Não vejo razão para acreditar que a Entidade morrerá nos próximos 5 anos.

Outra solução potencial é usar uma Entity Framework Library alternativa que não é a fornecida com o VS. Existem algumas disponíveis na Web.

O conceito de estrutura do Entity / 3 layers já existe há algum tempo e trabalha com várias bibliotecas personalizadas, como muitos outros desenvolvedores, antes da Microsoft lançar seu próprio framework "oficial".

Prós

Tenha os benefícios da estrutura Entity (DAL), sem ficar preso às alterações constantes das bibliotecas / estruturas da Microsoft.

Adicionar recursos a uma biblioteca que talvez não estejam disponíveis para a biblioteca oficial existente, como o uso de várias marcas dtabase.

Contras

Tem que suportar a biblioteca ou ferramentas. É muito comum ter uma ferramenta de código gerador de entidades para gerar os enitites.

Você precisa tomar uma decisão arquitetural com base no problema e na solução existente. Como em qualquer tecnologia, existem vantagens e desvantagens.

Pessoalmente, normalmente usaria a estrutura da entidade para um novo desenvolvimento, mas não reescreveria o código existente em funcionamento. Você obtém a velocidade para o futuro delelopment, mas não precisa investir muito tempo convertendo o código. A desvantagem dessa abordagem é que ela reduz a consistência.

Na sua situação, eu definitivamente usaria o Entity Framework, descobri que funciona bem com o MVC.
Aqui estão alguns motivos reais e dicas.

• O Linq é um prazer de usar, e a execução atrasada também é extremamente útil.
• Você pode gerar seus modelos (no entanto, ao usar com o mvc, recomendo que você use os modelos de visualização em conjunto com os modelos de dados, isso facilita muito a validação e a associação de modelos; se você seguir essa abordagem, use o automapper para mapear as alterações de volta ao seu modelo. modelo de dados).

No entanto, você precisará aprender várias coisas sobre o uso de um ORM.

• O que o contexto faz por você (rastreamento de entidade)
• Que um contexto deve ser usado como uma unidade de trabalho
• Lembre-se de considerar a simultaneidade, a EF pode informar quando seu objeto está desatualizado, mas pode ser complicado se você deseja lidar com a simultaneidade corretamente entre solicitações (pois é necessário manter um carimbo de data / hora ou algo assim).

Coisas a considerar

• Gatilhos e ORMs não funcionam juntos, use os eventos ORM.
• Verifique se todas as suas tabelas possuem chaves preliminares.

Também recomendo a primeira abordagem de código, mesmo se você tiver um banco de dados existente.

• As convenções significam que você não precisa regenerar mapeamentos ou classes quando altera o banco de dados.
• É mais fácil colocar validação e outra lógica nos modelos.
• Você pode usar o gerador de código para ajudá-lo a criar, se você tiver um enorme banco de dados existente.