I am trying to find out which is the best practice when organising the PreparedStatement strings in a application which uses JDBC to connect to the database.Usually this is the way I retrieve the data from the database:PreparedStatement select = null;String prepQuery = SELECT * FROM user JOIN details ON user.id = details.user_id WHERE details.email = ? AND details.password = ?;select = con.prepareStatement(prepQuery);select.setString(1, email);select.setString(2, pass);ResultSet result = select.executeQuery();// Handle the result.This is a method which retrieves a user entity using the email and a password. For all my methods this is how I save the query strings.The first drawback which comes to mind is that this is quite messy and difficult to manage if I'm changing the SQL provider (Maybe if I would place all the queries in a Constants file would be a better solution). Furthermore JPA offers tools like @NamedQuery which is said to improve the performance of the application.Is there a best practice when it comes to organising the query strings in an application using JDBC. Thank you!
Manage query strings in JDBC methods
java;programming practices;jdbc
Consider JDBIIf you want to work closely with JDBC so that you create your own SQL and have your application manage the binding between the query parameters, then JDBI might be a good approach for you. Essentially, you create an annotated interface that describes your DAO, and JDBI will provide an implementation at runtime. A typical DAO could look like this:public interface MyDAO{  @SqlUpdate(create table something (id int primary key, name varchar(100)))  void createSomethingTable();  @SqlUpdate(insert into something (id, name) values (:id, :name))  void insert(@Bind(id) int id, @Bind(name) String name);  @SqlQuery(select name from something where id = :id)  String findNameById(@Bind(id) int id);  /**   * close with no args is used to close the connection   */  void close();}This approach lends itself to a very lightweight handling of SQL. If your needs are more geared towards supporting multiple databases or abstracting those databases away from the SQL and into a pure object model, then JPA is probably a better approach.