Quais são as práticas padrão para acesso ao banco de dados no .net?

5

Eu tenho visto práticas estranhas de acesso ao banco de dados em .net. Eu vi procedimentos armazenados para todas as tarefas do banco de dados. Eu vi que cada nome de propriedade do banco de dados é precedido pelo nome da tabela. Eu vi camada / .dll totalmente separada por muito pouca ou nenhuma lógica de negócios. Eu vi junto com ORMs, há camada de acesso a dados separados desempenhando o mesmo papel. E com eles, eu sempre ouvi: "Esses são os padrões que você tem que manter".

Então, quais são os padrões reais para o acesso a dados no .net? Quais são as regras que você segue?

    
por Gulshan 21.02.2011 / 17:08
fonte

5 respostas

3

Os padrões são definidos para o seu projeto pela sua equipe. Eles variam de acordo com a situação.

"Eu vi procedimentos armazenados para todas as tarefas do banco de dados" : Todos os procedimentos armazenados não são um mau caminho para aplicativos pequenos (para evitar a injeção de SQL) ou para bancos de dados que contêm dados que podem ser atualizados por várias fontes (banco de dados de acesso, aplicativo da Web, etc.)

"Vi que todo nome de propriedade do banco de dados é precedido pelo nome da tabela" Eu vejo isso em muito em bancos de dados mais antigos, então eu me pergunto se poderia ter sido um padrão um tempo atrás. Eu acho que é exagero.

"Eu vi camada / .dll totalmente separada por pouquíssimas ou nenhuma lógica de negócios" : Provavelmente alguém tentando implementar um bom padrão de design para um pequeno aplicativo que realmente não precisa dele.

"Vi junto com ORMs, há camadas de acesso a dados separadas que desempenham o mesmo papel" : Talvez o aplicativo tenha começado com um estilo de acesso a dados e, à medida que cresceu, outro foi implementado e ninguém foi refatorado.

    
por 21.02.2011 / 17:17
fonte
2

Realmente não existe padrão na prática, infelizmente.

No entanto , para um aplicativo com complexidade real (ou seja, modelagem de domínio), os ORMs são a abordagem defendida por:

por 21.02.2011 / 17:16
fonte
1

Não há padrões. Use o que funciona para você, sua equipe e seu projeto e, em seguida, assista a esse padrão.

    
por 21.02.2011 / 19:21
fonte
0

Não existe um padrão, mas não vejo isso como algo ruim. Na agricultura, a monocultura é a prática de plantar apenas um tipo de cultura em todos os lugares - um tipo específico de milho, soja e algodão. O pensamento foi que deveria haver uma melhor resposta para a pergunta: "Qual é o melhor tipo de X?" (Nota: A idéia de "um dos melhores" foi empurrada pelas grandes empresas da Europa, assim como grandes empresas de software e blogueiros impulsionam a ideia com tecnologia.)

Acontece que esta ideia está errada. As monoculturas são catastroficamente vulneráveis a doenças. Normalmente, se a lavoura de um fazendeiro adoece, o fazendeiro perde a colheita. Com uma monocultura, uma doença se espalhará por todas as fazendas com perdas incríveis. Diversidade impede isso.

A diversidade é poderosa.

    
por 21.02.2011 / 18:20
fonte
0

Uma pergunta melhor seria: "O que devo fazer quando vejo padrões de codificação que parecem absurdos?"

So, what are the real standards for data access in .net?

Não há padrões "reais". Toda organização tem que criar as suas próprias. Se os padrões da sua organização não fizerem sentido, tente descobrir por que eles estão lá. Se você descobrir por que e ainda acha que eles não fazem sentido, desafie-os . As chances são de que eles o sugiram para o comitê que define os padrões, ou pedem para você escrever o seu próprio, se não houver nenhum padrão "escrito para baixo" para o seu grupo.

Naturalmente, isso pressupõe que você tenha abordado isso de maneira ponderada, respeitosa e madura. Se você não fez isso, espere ser desligado ou ignorado.

    
por 22.02.2011 / 22:47
fonte