Eu trabalho em uma empresa que usa apenas procedimentos armazenados para todo o acesso a dados, o que torna muito irritante manter nossos bancos de dados locais sincronizados, a cada confirmação que temos para executar novos procs. Eu usei algumas ORMs básicas no passado e acho a experiência muito melhor e mais limpa. Gostaria de sugerir ao gerente de desenvolvimento e ao restante da equipe que analisemos o uso de um ORM de algum tipo para desenvolvimento futuro (o restante da equipe conhece apenas os procedimentos armazenados e nunca usou mais nada). A arquitetura atual é o .NET 3.5, escrito como o .NET 1.1, com "classes god" que usam uma implementação estranha do ActiveRecord e retornam DataSets não digitados que são repetidos em arquivos code-behind - as classes funcionam da seguinte forma:
class Foo {
public bool LoadFoo() {
bool blnResult = false;
if (this.FooID == 0) {
throw new Exception("FooID must be set before calling this method.");
}
DataSet ds = // ... call to Sproc
if (ds.Tables[0].Rows.Count > 0) {
foo.FooName = ds.Tables[0].Rows[0]["FooName"].ToString();
// other properties set
blnResult = true;
}
return blnResult;
}
}
// Consumer
Foo foo = new Foo();
foo.FooID = 1234;
foo.LoadFoo();
// do stuff with foo...Não há praticamente nenhuma aplicação de padrões de design. Não há nenhum teste (ninguém mais sabe como escrever testes de unidade, e o teste é feito carregando manualmente o site e bisbilhotando). Examinando nosso banco de dados, temos: 199 tabelas, 13 visualizações, 926 procedimentos armazenados e 93 funções. Cerca de 30 tabelas são usadas para tarefas em lote ou externas, e as demais são usadas em nosso aplicativo principal.
Vale a pena seguir uma abordagem diferente nesse cenário? Estou falando de avançar apenas porque não temos permissão para refatorar o código existente, pois "funciona", portanto não podemos alterar as classes existentes para usar um ORM, mas não sei com que frequência adicionamos novos módulos. de adicionar / corrigir módulos atuais, portanto, não tenho certeza se um ORM é a abordagem correta (muito investido em procedimentos armazenados e DataSets). Se for a escolha certa, como devo apresentar o caso para usar uma? Em primeiro lugar, os únicos benefícios que consigo pensar são em ter um código mais limpo (embora possa não ser, pois a arquitetura atual não é " t construído com ORMs em mente, para que basicamente integrássemos os ORMs para módulos futuros, mas os antigos ainda usariam os DataSets) e menos problemas para lembrar quais scripts de procedimento foram executados e quais precisam ser executados, etc, mas é isso, e eu não sei o quão convincente seria um argumento. A manutenção é outra preocupação, mas que ninguém, exceto eu, parece se preocupar.