envoltório jdbc simples

Question

Para implementar o código de acesso de dados em nossa aplicação nós precisamos de alguma estrutura para envolver em torno de jdbc (ORM não é nossa escolha, por causa da escalabilidade).

O mais legal framework Eu costumava trabalhar com é Spring-Jdbc . No entanto, a política da minha empresa é evitar dependências externas, especialmente primavera, J2EE, etc. Então, estamos pensando em escrever própria estrutura jdbc handy-feita, com jdbc Primavera-funcionalidade semelhante:. Mapeamento linha, manipulação de erro, apoiando características de java5, mas sem suporte a transações

Alguém tem experiência de escrever tal quadro invólucro jdbc? Se alguém tiver experiência no uso de outros frameworks de wrapper JDBC, por favor partilhe a sua experiência.

Agradecemos antecipadamente.

Answer 1

Nós escrevemos nossa própria embalagem. Este tópico é digno de um papel, mas eu duvido que alguma vez vai ter tempo para escrevê-lo, então aqui estão alguns pontos-chave:

• nos abraçamos sql e não fez nenhuma tentativa de escondê-lo. a única emenda foi para adicionar suporte para parâmetros nomeados. parâmetros são importantes porque nós não encorajamos o uso do SQL on-the-fly (por razões de segurança) e sempre usar PreparedStatements.

• para gerenciamento de conexão, usamos Apache DBCP. Este foi conveniente no momento, mas não está claro o quanto isso é necessário com implementações de JDBC modernos (os documentos sobre este material está faltando). DBCP também piscinas PreparedStatements.

• que não se preocupou com o mapeamento de linha. vez (para consultas) usamos algo semelhante a ResultSetHandler do Apache DBUtil, que lhe permite "alimentar" o conjunto de resultados em um método que pode despejar as informações onde quer que você gostaria. Esta é mais flexível e, de fato, não seria difícil de implementar um ResultSetHandler para mapeamento linha. para inserções / atualiza criamos uma classe de registro genérico (basicamente um hashmap com alguns sinos e assobios extra). o maior problema com o mapeamento de linha (para nós) é que você está preso, logo que você faz uma consulta de "interessante" porque você pode ter campos que são mapeados para diferentes classes; porque você pode ter uma estrutura de classe hierárquica, mas um conjunto de resultados plana; ou porque o mapeamento é complexo e dependente de dados.

• nós construímos no registro de erros. para manipulação de exceção: em uma armadilha consulta nós e log, mas para uma armadilha de atualização que, log, e relançar uma exceções não verificadas

.

• nós fornecemos suporte a transações usando uma abordagem wrapper. o chamador fornece o código que executa a transação, e temos certeza de que a transação for adequadamente gerida, sem chance de esquecer de concluir a transação e com reversão e manipulação de erro interno.

• Mais tarde, nós adicionamos um esquema de relação muito simplista que permite que uma única atualização / inserção para aplicar a um registro e todas as suas dependências. para manter as coisas simples, nós não usar isso em consultas, e decidimos não especificamente para apoiar esta com exclusões, porque é mais confiável para usar exclusões em cascata.

Este invólucro tem sido usado com sucesso em dois projectos até à data. É, claro, leve, mas estes dias toda a gente diz seu código é leve. Mais importante, ele aumenta a produtividade do programador, diminui o número de erros (e faz com que os problemas mais fáceis de rastrear), e é relativamente fácil de rastrear através caso de necessidade, porque não acreditamos em adicionar muitas camadas apenas para fornecer bela arquitetura.

Answer 2

Spring-JDBC é fantástico. Considere-se que para um projeto de código aberto como Primavera do lado de baixo da dependência externa é minimizado. Você pode adotar a versão mais estável de Primavera que satisfaça suas necessidades de captação de JDBC e você sabe que você sempre será capaz de modificar os mesmos código fonte Se você já se deparou com um problema - sem depender de uma parte externa. Você também pode examinar a aplicação de quaisquer preocupações de segurança que sua organização possa ter com o código escrito por uma parte externa.

Answer 3

O que eu prefiro: Dalesbred . É do MIT licenciado.

Um exemplo simples de obter todas as linhas para uma classe personalizada (Departamento).

List<Department> departments = db.findAll(Department.class,
    "select id, name from department");

quando a classe personalizada é definido como:

public final class Department {
    private final int id;
    private final String name;

    public Department(int id, String name) {
        this.id = id;
        this.name = name;
    }
}

Disclaimer:. É por uma empresa que eu trabalho para

Answer 4

Isso soa como uma decisão míope muito curto. Considere o custo de desenvolvimento / manutenção de estrutura tal, especialmente quando você pode obtê-lo, e de código fonte gratuitamente. Não só você não tem que fazer o desenvolvimento, você pode modificá-lo à vontade, se necessário.

Dito isto, o que você realmente precisa para duplicar é a noção de JdbcTemplate e é retornos de chamada (PreparedStatementCreator, PreparedStatementCallback), bem e RowMapper / RowCallbackHandler. Não deve ser demasiado complicada para escrever algo como isto (especialmente considerando que você não tem que fazer o gerenciamento de transações).

Howver, como eu disse, por que escrevê-lo quando você pode obtê-lo gratuitamente e modificar o código-fonte como você vê o ajuste?

Answer 5

Tente JdbcSession de jcabi-jdbc . É tão simples como JDBC deve ser, por exemplo:

String name = new JdbcSession(source)
  .sql("SELECT name FROM foo WHERE id = ?")
  .set(123)
  .select(new SingleOutcome<String>(String.class));

É isso.

Answer 6

mJDBC: https://mjdbc.github.io/

Eu uso isso há anos e achei muito útil.

É inspirado pela biblioteca JDBI mas não tem dependências, adiciona suporte transações, fornece contadores de desempenho e permite mudar para o nível mais baixo SQL possível em Java (planície antiga API JDBC) facilmente no caso, se você realmente precisa dele.