Eu realmente preciso assistir a um debate honesto e ponderado sobre os méritos do paradigma de design de aplicativos corporativos atualmente aceito .
Não estou convencido de que objetos de entidade devam existir.
Por objetos de entidade, quero dizer as coisas típicas que costumamos criar para nossos aplicativos, como "Pessoa", "Conta", "Pedido" etc.
Minha filosofia atual de design é a seguinte:
- Todo acesso ao banco de dados deve ser realizado por meio de procedimentos armazenados.
- Sempre que você precisar de dados, chame um procedimento armazenado e itere sobre um SqlDataReader ou as linhas em um DataTable
(Nota: Eu também construí aplicativos corporativos com Java EE, pessoal de Java, substitua o equivalente pelos meus exemplos .NET)
Eu não sou anti-OO. Eu escrevo muitas classes para propósitos diferentes, mas não entidades. Admito que grande parte das classes que escrevo são classes auxiliares estáticas.
Eu não estou construindo brinquedos. Estou falando de aplicativos transacionais grandes e de alto volume implantados em várias máquinas. Aplicativos da Web, serviços do Windows, serviços da Web, interação B2B, o nome dele.
Eu usei OR Mappers. Eu escrevi alguns. Eu usei a pilha Java EE, CSLA e alguns outros equivalentes. Eu não apenas os usei, mas desenvolvi e mantive ativamente esses aplicativos em ambientes de produção.
Eu vim à conclusão de batalha-testado que objetos de entidade estão recebendo em nosso caminho, e nossa vida seria assim muito mais fácil sem eles.
Considere este exemplo simples: você recebe uma chamada de suporte sobre uma determinada página em seu aplicativo que não está funcionando corretamente, talvez um dos campos não esteja sendo mantido como deveria. Com o meu modelo, o desenvolvedor designado para encontrar o problema abre exatamente 3 arquivos . Um arquivo ASPX, ASPX.CS e SQL com o procedimento armazenado. O problema, que pode ser um parâmetro ausente para a chamada do procedimento armazenado, leva alguns minutos para ser resolvido. Mas com qualquer modelo de entidade, você invariavelmente inicia o depurador, começa a percorrer o código e pode acabar com 15 a 20 arquivos abertos no Visual Studio. Quando você desce até o final da pilha, você esqueceu onde começou. Só podemos manter tantas coisas em nossas cabeças ao mesmo tempo. O software é incrivelmente complexo sem adicionar camadas desnecessárias.
A complexidade do desenvolvimento e a solução de problemas são apenas um lado da minha queixa.
Agora vamos falar sobre escalabilidade.
Os desenvolvedores percebem que toda vez que escrevem ou modificam qualquer código que interaja com o banco de dados, eles precisam fazer uma análise completa do impacto exato no banco de dados? E não apenas a cópia de desenvolvimento, quero dizer uma imitação da produção, para que você possa ver que a coluna adicional que você precisa agora para o seu objeto invalidou o plano de consulta atual e um relatório que estava sendo executado em 1 segundo agora leva 2 minutos, apenas porque você adicionou uma única coluna à lista de seleção? E acontece que o índice que você precisa agora é tão grande que o DBA precisará modificar o layout físico dos seus arquivos?
Se você permitir que as pessoas se afastem demais do armazenamento de dados físicos com uma abstração, elas criarão estragos no aplicativo que precisa ser dimensionado.
Eu não sou fanático. Posso estar convencido de que estou errado, e talvez esteja, já que existe um forte impulso em direção ao Linq to Sql, ADO.NET EF, Hibernate, Java EE, etc. Por favor, pense nas suas respostas, se estiver faltando algo que eu realmente quero saber o que é e por que devo mudar meu pensamento.
[Editar]
Parece que esta pergunta está subitamente ativa novamente, então agora que temos o novo recurso de comentário que comentei diretamente em várias respostas. Obrigado pelas respostas, acho que é uma discussão saudável.
Eu provavelmente deveria ter sido mais claro que estou falando de aplicativos corporativos. Eu realmente não posso comentar, digamos, sobre um jogo que está sendo executado na área de trabalho de alguém ou em um aplicativo móvel.
Uma coisa que preciso colocar aqui no topo em resposta a várias respostas semelhantes: a ortogonalidade e a separação de preocupações são frequentemente citadas como razões para se tornar uma entidade / ORM. Procedimentos armazenados, para mim, são o melhor exemplo de separação de preocupações em que consigo pensar. Se você não permitir qualquer outro acesso ao banco de dados, exceto por meio de procedimentos armazenados, em teoria, poderá redesenhar todo o seu modelo de dados e não quebrar nenhum código, desde que mantenha as entradas e saídas dos procedimentos armazenados. Eles são um exemplo perfeito de programação por contrato (desde que você evite "selecionar *" e documente os conjuntos de resultados).
Pergunte a alguém que está no setor há muito tempo e já trabalhou com aplicativos de longa duração: quantas camadas de aplicativo e da interface do usuário surgiram e desapareceram enquanto um banco de dados vive? Quão difícil é ajustar e refatorar um banco de dados quando existem 4 ou 5 camadas de persistência diferentes gerando SQL para acessar os dados? Você não pode mudar nada! ORMs ou qualquer código que gera SQL bloqueiam seu banco de dados .