Mudando para ORMs

Question

Estou pensando em incorporar um ORM em um aplicativo que apoio.O aplicativo não é muito estruturado e não possui testes unitários.Portanto, qualquer mudança será arriscada.Obviamente estou preocupado por ter um motivo bom o suficiente para mudar.A ideia é que haja menos código padrão para acesso a dados e haja maior produtividade.

Isso soa verdadeiro com suas experiências?
É possível ou mesmo uma boa ideia implementá-lo gradualmente?
Quais são as desvantagens de um ORM?

Answer 1

Eu recomendo fortemente obter uma cópia do livro de Michael Feather Trabalhando de forma eficaz com código legado (por "Código Legado" Feathers significa qualquer sistema que não seja adequadamente coberto por testes de unidade).Ele está cheio de boas ideias que devem ajudá-lo na refatoração e na introdução progressiva das melhores práticas.

Claro, você poderia introduzir gradualmente um ORM, inicialmente usando-o para acessar algum subconjunto do seu modelo de domínio.E sim, descobri que o uso de um ORM acelera o tempo de desenvolvimento - esse é um dos principais benefícios e certamente não sinto falta dos dias em que eu criava laboriosamente camadas de acesso a dados.

Desvantagens do ORM - por experiência própria, há inevitavelmente uma certa curva de aprendizado para se familiarizar com os conceitos, configuração e idiossincrasias da solução ORM escolhida.

Editar:nome do autor corrigido

Answer 2

O livro "Robert C Martin", que na verdade foi escrito por Michael Feathers ("Tio Bob" é, ao que parece, uma marca hoje em dia!) É obrigatório.

É quase impossível - sem mencionar que consome muito tempo - colocar testes de unidade em um aplicativo que não foi desenvolvido com eles.O código simplesmente não será receptivo.

Mas isso não é um problema.Refatorar é mudar o design sem mudar a função (espero não ter corrompido muito o significado aqui) para que você possa trabalhar de uma forma muito mais ampla.

Comece com pedaços grandes.Configure uma execução repetível e capture o que acontece como resultado esperado para execuções subsequentes.Agora você tem seu aplicativo, ou pelo menos parte dele, em teste.Não é um teste muito bom ou abrangente, claro, mas é um começo e as coisas só podem melhorar a partir daí.

Agora você pode começar a refatorar.Você deseja começar a extrair seu código de acesso a dados para que possa ser substituído pela funcionalidade ORM sem incomodar muito.Teste frequentemente:com aplicativos legados, você ficará surpreso com o que quebra;coesão e acoplamento raramente são o que poderiam ser.

Eu também consideraria dar uma olhada no livro de Martin Fowler Reestruturação, que é, obviamente, o trabalho definitivo do processo.

Answer 3

Eu trabalho em um grande aplicativo ASP.net onde recentemente começamos a usar o NHibernate.Movemos um grande número de objetos de domínio que persistíamos manualmente para o Sql Server e para o NHibernate.Simplificou bastante as coisas e tornou muito mais fácil mudar as coisas ao longo do tempo.Estamos felizes por termos feito as alterações e estarmos usando o NHibernate quando apropriado para muitos dos nossos novos trabalhos.

Answer 4

Ouvi dizer que o TypeMock costuma ser usado para refatorar código legado.

Answer 5

Eu realmente acho que introduzir ORM em um aplicativo legado está causando problemas (e pode ser a mesma quantidade de problemas que uma reescrita completa).

Fora isso, ORM é uma ótima opção e definitivamente deve ser considerada.

Answer 6

A regra para refatoração é.Faça testes unitários.

Então, talvez primeiro você deva colocar alguns testes de unidade, pelo menos para as coisas principais/principais.

O ORM deve ser projetado para diminuir o código padrão.O tempo/problema vs.O ROI para ser empreendedor depende de você estimar :)

Answer 7

A menos que seu código já esteja arquitetado para permitir a "troca a quente" do back-end da camada de modelo, alterá-lo de qualquer forma sempre será extremamente arriscado.

Tentar construir uma rede de segurança de testes unitários em código mal arquitetado não garantirá o sucesso, apenas fará você se sentir mais seguro em alterá-lo.

Portanto, a menos que você tenha um forte argumento comercial para assumir os riscos envolvidos, provavelmente é melhor deixar tudo de lado.