rafanoronha.speaking()

Já faz algum tempo que comentei com o pessoal do .Net Architects sobre um cenário onde enxergo um problema na utilização de abstrações.

Este cenário especificamente é a definição de uma interface sobre o uso de um framework ORM.

O problema de definir uma interface sobre o seu ORM é o fato de que você está tentando isolar algo que em situações normais não precisa ser isolado.

Um bom ORM por si só já é um componente de abstração.
Ele esconde de um software orientado a objetos a natureza relacional da comunicação com um banco de dados.

O motivo justo para se definir a interface seria a possibilidade de trocar de ORM alterando apenas um arquivo de configuração.

Mas deixo aqui dois argumentos que confrontam esta idéia:

1 – Na maior parte dos cenários, a flexibilidade de não depender de uma implementação de ORM é meramente um ornamento sobre o seu software.
Eu fico imaginando se realmente pode vir a fazer sentido que você deixe de utilizar o NHibernate e passe a utilizar o Entity Framework, ou algo do tipo, durante o decorrer de um projeto.

Diante disto, a recomendação é obviamente a de que devemos nos ater à solução mais simples possível.
A mudança de implementação do contrato jamais viria a tona.

2 – Digamos que para o seu contexto em específico, a troca de implementação realmente faça sentido.

No entanto, um fato que não deve ser ignorado é o de que o problema de persistência de dados é complexo, e o que está em jogo não é apenas a troca de mensagens entre o seu software e o componente de persistência, mas também o modo como este componente trata o ciclo de vida dos objetos mapeados, entre outras coisas.

Além disto, a API de um bom ORM é bastante extensa, e cobrí-la com uma interface genérica realmente não me parece a melhor das idéias.
Principalmente ao considerarmos os problemas de mapeamento ou construção de queries, e como estes variam dentre diferentes soluções.

Contratos são extremamente poderosos na construção de software.
No entanto, diferentes cenários podem tirar maior ou menor proveito da utilização destes com o objetivo de plugar diferentes implementações de um componente.

Antes de definir um contrato sobre uma dependência de seu software, é interessante que se faça uma análise do custo-benefício trazido pela abstração.

Não tome decisões em função da suposição de que em um belo e distante dia elas lhe trarão benefícios.
Trata-se de um dos erros mais cometidos por arquitetos de software.