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.

A escrita deste texto foi inspirada pelo seguinte post, encontrado no blog do Rodrigo Yoshima, figura carimbada na comunidade Java.

Nem faz tanto tempo assim que trabalho com software, mas o meu grande interesse pela indústria me traz diversos tipos de reflexões e conclusões a seu respeito.

Uma das conclusões é a de que pessoas têm preguiça de pensar e inovar.

É onde entra o fácil.
Fácil é desenvolver software do mesmo jeito, sempre.
Tornando-se imperceptível o quão ineficiente e falho são os métodos de trabalho empregados.

Há aqueles que enaltecem o difícil.
Desenhando arquiteturas engenhosas, mas incrivelmente improdutivas e mal empregadas.

A pegadinha acontece quando se fala no simples.
Chegar a uma solução simples é mais difícil do que chegar a uma solução fácil, e também mais difícil do que fazer algo complexo.

A solução simples é aquela que viabilizará maior produtividade, resultando em entregas mais frequentes.
É também aquela que exigirá maior know-how técnico durante sua concepção.

Você já parou para pensar que tipo de pessoa arquitetou o software em que você está trabalhando?

Ou em quão produtivo tem sido o seu trabalho?

Que tal começar analisando a quantidade de código que você precisa escrever para entregar software.

É incrivelmente grande a quantidade de trabalho repetitivo e desnecessário sendo realizado por aqueles que não estão em contato com uma solução simples.

E caso você se encontre neste cenário, considere-se acima da média simplesmente por ter reconhecido o fato.

Este texto está disponível apenas em Inglês.

Este texto está disponível apenas em Inglês.

Este texto está disponível apenas em Inglês.