Durante meu aprendizado, useiNHibernate para alguns projetos menores que eu principalmente codifiquei e desenhei por conta própria. Agora, antes de iniciar um projeto maior, surgiu a discussão sobre como projetar o acesso a dados e se deve ou não usar uma camada ORM. Como ainda estou aprendendo e ainda me considero iniciante em programação corporativa, não tentei expressar minha opinião, que é o fato de que o uso de um mapeador relacional de objeto no banco de dados pode facilitar bastante o desenvolvimento. Os outros codificadores da equipe de desenvolvimento são muito mais experientes que eu, então acho que farei o que eles dizem. :-)

No entanto, não entendo completamente duas das principais razões para não usar o NHibernate ou um projeto semelhante:

É possível criar os próprios objetos de acesso a dados com consultas SQL e copiá-las do Microsoft SQL Server Management Studio.Depurar um ORM pode ser difícil.

Então, é claro que eu poderia criar minha camada de acesso a dados com bastanteSELECTs etc, mas aqui sinto falta da vantagem de junções automáticas, classes de proxy de carregamento lento e menor esforço de manutenção se uma tabela obtiver uma nova coluna ou uma coluna for renomeada. (Atualizando váriosSELECT, INSERT eUPDATE consultas versus atualização da configuração de mapeamento e possivelmente refatoração das classes de negócios e DTOs.)

Além disso, usando o NHibernate, você poderá encontrar problemas imprevistos se não conhecer muito bem a estrutura. Pode ser, por exemplo, confiar no Table.hbm.xml, onde você define o comprimento de uma string para ser validado automaticamente. No entanto, também posso imaginar erros semelhantes em uma camada de acesso a dados "simples" SqlConnection baseada em consulta.

Finalmente, esses argumentos mencionados acima são realmente uma boa razão para não utilizar um ORM para um aplicativo corporativo não trivial baseado em banco de dados? Provavelmente existem outros argumentos que eles / eu posso ter esquecido?

(Devo acrescentar que acho que esse é o primeiro aplicativo "grande" baseado em .NET / C # que exigirá trabalho em equipe. Boas práticas, que são consideradas bastante normais no Stack Overflow, como teste de unidade ou integração contínua, não são -existindo aqui até agora.)