Qual é a sua maneira favorita de interagir com bancos de dados da sua linguagem de programação?[fechado]

Question

Existem inúmeras maneiras de conectar e interagir com a camada de banco de dados.Em Java, por exemplo, usos comuns são JDBC chamadas de SQL bruto, mapeadores relacionais de objetos, JDBCTemplate (Primavera), procedimentos armazenados, etc.

No seu idioma, qual opção é sua preferência e por quê?Quando você consideraria os outros?

Answer 1

ORM sempre, quanto menos eu tiver que pensar em bancos de dados, melhor.

Answer 2

Eu realmente gosto da maneira 3 + 1 de fazer as coisas.Uma camada para UI, uma para lógica de negócios e para dados persistentes.O último que você diz?Objetos de domínio e interfaces.Isso torna possível carregar qualquer uma ou duas das camadas principais mais a "camada" do domínio, e o código deve funcionar.

Depende muito de Injeção de dependência e Inversão de controle princípios.A camada de dados/persistência faz apenas duas coisas.Ele cria, lê, atualiza e exclui dados e os mapeia para o formato do objeto de domínio.

A camada da UI faz exatamente o oposto.Ele exibe e recebe dados de uma forma que o usuário possa relacionar e mapeia essa saída/entrada de e para o formato do objeto de domínio.

A camada lógica de negócios só precisa saber uma coisa.Logíca de negócios.Ele não se importa com a origem dos dados e não se importa com onde a camada de dados os está colocando.Ele sabe que deve sinalizar uma conta que acabou de ficar a descoberto, mas como fazer isso fisicamente não faz realmente parte do seu trabalho.

Os objetos de domínio em si não possuem lógica, são apenas contêineres para passagem de dados entre as camadas.Isso significa que você pode carregar os objetos e interfaces do domínio sem precisar pensar nas dependências.

No final das contas, sinto que tenho uma base de código bastante clara, com camadas claramente separadas.E com algumas interfaces rígidas e boas classes base, a maior parte da codificação consiste apenas em dizer ao software o que fazer quando X acontecer.Exatamente como deveria ser.

</rant>

Editar:Oh sim.Isso é verdade tanto para o LINQ, SubSônico, e outros ORMs.

Answer 3

Ruby on Rails' Registro ativo limpa o chão com tudo o mais que vi até agora. LINQ parece que pode ser melhor em alguns casos, mas o ActiveRecord é muito flexível.

Answer 4

LINQ é o caminho a seguir para mim daqui em diante

Answer 5

Prefiro construir uma camada de modelo de objeto de negócios (objetos e coleções de objetos).

Eu desenvolvo a capacidade de interagir com o banco de dados em cada objeto/coleção (para SQL Server, eu uso System.Data.SqlClient).Usei esse padrão para SQL Server, MySQL e Oracle.

Então eu interajo com os objetos do código do meu aplicativo.

Ao abstrair meu banco de dados em objetos, o código do meu aplicativo é consistente, independentemente do banco de dados back-end.

Answer 6

ORM é realmente fantástico.

Eu uso o SQL Alchemy ao trabalhar em python - ele funciona com quase todos os SGBDs que encontrei.

Para aplicativos leves baseados em dados no MacOS X, eu uso Core Data, que possui uma ótima ferramenta de modelagem de dados acessível via Xcode.

Ambos mostram que o ORM bem feito é excelente.Tive menos sucesso e prazer com o EJB.

Answer 7

Ainda não entrei no mundo LINQ, mas realmente adorei as classes DataTable/TableAdapter que o Visual Studio fez por meio de um conjunto de dados XSD.Por meio de alguns arrastamentos e cliques após criar meu esquema de banco de dados, agora tenho um objeto DataSet/DataTable que é fortemente tipado e tenho métodos adaptadores que usam consultas parametrizadas para meus procedimentos armazenados para todas as minhas instruções CRUD.Ele até criará adaptadores de tabela de consulta para alguns desses procedimentos que não estão diretamente vinculados a uma tabela.

Ah, e se você ainda não criou os procedimentos armazenados e possui apenas as tabelas, o assistente criará os procedimentos ou as instruções SQL ad hoc para você.

Isso foi lançado desde o Visual Studio 2005 e reduziu drasticamente meu tempo de "estrutura" com meus novos aplicativos da web e posso me concentrar mais na lógica de negócios e de apresentação.

Answer 8

Usamos uma abordagem mista, dependendo do que for adequado para a situação específica da aplicação:

• Ao ler uma página com informações para exibir e para um usuário atualizar, usamos o Hibernate
• Ao processar um lote de atualizações ou resumir onde a maioria dos dados já está no banco de dados (por exemplo,processamento de final de dia) usamos PL/SQL (e tentamos pensar em conjuntos)
• Quando um usuário realiza uma pesquisa ou executa um relatório resumido, usamos ibatis sqlmaps para construir algum SQL e trazer de volta apenas os campos nos quais estamos interessados ​​(nem todas as colunas e certamente nenhuma linha filha desnecessária, urggh)
• Qualquer coisa que realmente precise ser executada rapidamente, usaremos a abordagem que funcionar melhor

Isso é com java/Oracle.

Answer 9

Registro ativo, que é um padrão documentado primeiro (eu acho) no livro de Fowler Padrões de arquitetura empresarial.Acredito que seja implementado em outras linguagens além do Ruby, embora seja bem conhecido como uma tecnologia central no Rails.Seja como for, é uma abstração bacana do banco de dados, embora eu deva confessar que acho um pouco desajeitado e na área find_by_sql.Mas isso pode ser apenas eu.

Mas (colocando o chapéu do Velho Mal-humorado agora) todos os ORMs do mundo não substituem um bom conhecimento de SQL, sem o qual eu realmente não gosto de ver o acesso a um RDBMS sendo permitido.

Answer 10

Usamos Delphi e Oracle Data Access Components (ODAC) e ADO via Oracle.OleDBProvider.

Answer 11

A maneira favorita é usar Smalltalk com um repositório de objetos GemStone.Por que?Nenhum problema de ORM para lidar.Eu só consideraria outra coisa se fosse forçado ou ameaçado pelo meu empregador.

Answer 12

Minha maneira favorita é ter uma camada de abstração de objetos.Idealmente, isso é apenas local que trabalha com SQL.Mas, na prática, os objetos às vezes também precisam fazer coisas SQL.Mas nada fora do objeto.

Até agora, eu mesmo escrevi essas camadas porque o que estava disponível era muito estranho, muito lento ou muito grande.

Answer 13

Eu uso JDBC simples porque estou desenvolvendo um aplicativo baseado em dados e meu modelo de banco de dados é muito complexo.Tudo está descrito no banco de dados, até estrutura de outras tabelas.Além disso eu uso muito procedimentos armazenados.Portanto ORM não é uma opção para mim.

Answer 14

Eu gosto Hibernar bastante :)

Eu sei que tem uma curva de aprendizado, mas depois de dominá-lo, é muito bom.

Escusado será dizer que mal posso esperar para colocar as mãos no novo Estrutura de entidade no .NET 3.5 SP1 (sei que já está disponível, mas estou com preguiça de digitar XML :))

Answer 15

Em C# eu adoro LINQ para SQL para qualquer coisa nova, mas eu realmente gosto de usar .netTiers + Gerador CodeSmith para obter uma camada de dados rápida e suja no banco de dados se eu estiver usando C # no .NET 2.0.

Answer 16

No momento estamos usando ODAC conversar com o banco de dados Oracle e usar muitos pacotes Oracle (PL/SQL).O sistema de n camadas é feito por meio de RemObjects, o que significa que nosso cliente não possui nenhum SQL e só precisa da capacidade de enviar solicitações HTTP, sem sobrecarga de instalação.

Tudo isso é feito utilizando Borland Delphi e trabalha há 2 anos em ambiente de produção.