Многие разработчики, используют в своих проектах библиотеку Retrofit, которая позволяет превратить HTTP API в java-интерфейс. Это очень удобно, так как позволяет избавиться от лишнего кода и использовать ее очень легко. Нужно лишь создать интерфейс и навесить несколько аннотаций.
Недавно я занимался разработкой приложения для Android, которому необходимо было делать запросы к базе данных через JDBC- драйвер. Тогда мне пришла идея создать нечто подобное Retrofit только для запросов к базе данных. Так появился RetroBase, о котором я Вам сейчас и расскажу.
Для того, чтобы интерфейс и аннотации превратились в рабочий код, потребуется Annotation Processing, который открывает поистине огромные возможности для автоматизации написания однотипного кода. А в сочетании с JavaPoet процесс генерации java-кода становится удобным и простым.
На хабре, как и на просторах интернета, имеется несколько хороших статей по этой теме, поэтому разобраться с Annotation Processing не составляет труда, а необходимый мануал библиотеки JavaPoet умещается в ее README.md.
Основу RetroBase составляют две аннотации DBInterface
и DBQuery
вместе с DBAnnotationProcessor
, который и выполняет всю работу. С помощью DBInterface
отмечается интерфейс с методами-запросами к БД, а DBQuery
отмечает сами методы. Методы могут иметь параметры, которые будут использованы в SQL-запросе. Например:
@DBInterface(url = SpendDB.URL, login = SpendDB.USER_NAME, password = SpendDB.PASSWORD)
@DBInterfaceRx
public interface SpendDB {
String USER_NAME = "postgres";
String PASSWORD = "1234";
String URL = "jdbc:postgresql://192.168.1.26:5432/spend";
@DBMakeRx(modelClassName = "com.qwert2603.retrobase_example.DataBaseRecord")
@DBQuery("SELECT * from spend_test")
ResultSet getAllRecords();
@DBMakeRx
@DBQuery("DELETE FROM spend_test WHERE id = ?")
void deleteRecord(int id) throws SQLException;
}
Самое интересное происходит в DBAnnotationProcessor
, где осуществляется генерация класса, реализующего интерфейс, сгенерированный класс будет иметь имя *название_интерфейса* + Impl
:
TypeSpec.Builder newTypeBuilder = TypeSpec.classBuilder(dbInterfaceClass.getSimpleName() + GENERATED_FILENAME_SUFFIX)
.addSuperinterface(TypeName.get(dbInterfaceClass.asType()))
.addField(mConnection)
.addMethod(waitInit)
.addModifiers(Modifier.PUBLIC, Modifier.FINAL);
После этого создается соединение с БД:
FieldSpec mConnection = FieldSpec.builder(Connection.class, "mConnection", Modifier.PRIVATE)
.initializer("null")
.build();
Также создается PreparedStatement
для каждого запроса:
FieldSpec fieldSpec = FieldSpec
.builder(PreparedStatement.class, executableElement.getSimpleName().toString() + PREPARED_STATEMENT_SUFFIX)
.addModifiers(Modifier.PRIVATE)
.initializer("null")
.build();
… и реализация метода для этого запроса:
MethodSpec.Builder methodBuilder = MethodSpec.methodBuilder(executableElement.getSimpleName().toString())
.addAnnotation(Override.class)
.addModifiers(Modifier.PUBLIC)
.returns(returnTypeName);
При этом учитывается тип возвращаемого значения метода. Он может быть либо void
, если SQL-запрос представляет собой INSERT, DELETE или UPDATE. Либо ResultSet
, если SQL-запрос представляет собой SELECT.
Также выполняется проверка на то, может ли метод выбрасывать SQLException
. Если может, они будут выброшены и из реализации метода. А если нет — пойманы и выведены в stderr
.
Все параметры аннотированного метода добавляются в переопределяющий метод, а также для каждого параметра генерируется выражение позволяющее передать значение параметра в PreparedStatement
:
insertRecord_PreparedStatement.setString(1, kind);
Конечно же, количество и типы параметров метода должны соответствовать параметрам запроса, переданного с помощью аннотации DBQuery
.
После того, как файл был сгенерирован, он записывается средствами Annotation Processing:
JavaFileObject sourceFile = processingEnv.getFiler().createSourceFile(filename);
Writer writer = sourceFile.openWriter();
writer.write(javaFile.toString());
Rx it!
Конечно, удобно получать ResultSet
, определяя лишь интерфейс. А еще удобнее было бы воспользоваться популярной RxJava и получать Observable
. К тому же, это позволит легко решить проблему с выполнением запросов в другом потоке.
Для этого был создан DBMakeRxAnnotationProcessor
вместе с DBInterfaceRx
и DBMakeRx
, которые позволяют создать класс с методами-обертками. Применение этих аннотаций Вы уже могли увидеть в примере выше. Созданный класс будет иметь имя *название_интерфейса* + Rx
, а также будет иметь открытый конструктор, принимающий объект интерфейса, аннотированного DBInterfaceRx
, которому он будет перенаправлять запросы, возвращая результаты в реактивном стиле.
Все, что нужно — это добавить к методу аннотацию DBMakeRx
и передать ей название класса модели. Сгенерированный метод-обертка будет возвращать Observable<*класс модели*>
. При этом, название класса модели можно и не определять. В этом случае сгенерированный метод будет возвращать Observable<java.lang.Object>
, что удобно для SQL-запросов INSERT, DELETE или UPDATE, для которых не требуется возвращение результата.
Например, для метода интерфейса ResultSet getAllRecords();
из примера выше будет сгенерирован следующий метод-обертка:
public rx.Observable<com.qwert2603.retrobase_example.DataBaseRecord> getAllRecords() {
return Observable.create(subscriber -> {
try {
ResultSet resultSet = mDB.getAllRecords();
while (resultSet.next()) {
subscriber.onNext(new com.qwert2603.retrobase_example.DataBaseRecord(resultSet));
}
subscriber.onCompleted();
}
catch (Exception e) {
subscriber.onError(e);
}
} );
}
Здесь mDB
представляет собой объект интерфейса, аннотированного DBInterfaceRx
, который был передан в конструктор.
Как видно из сгенерированного метода, нам потребуется создание объектов класса модели из ResultSet
, поэтому у класса модели должен быть открытый конструктор, который принимает ResultSet
.
Естественно, что параметры сгенерированного метода будут точно соответствовать параметрам метода, вызов которого происходит:
public rx.Observable<Object> insertRecord(String kind, int value, Date date) {
...
mDB.insertRecord(kind, value, date);
...
}
Все исключения, которые происходят при выполнении запроса, передаются Subscriber'у как и положено в Rx.
Пример использования всего описанного выше может выглядеть следующим образом:
private SpendDB mSpendDB = new SpendDBImpl();
private SpendDBRx mSpendDBRx = new SpendDBRx(mSpendDB);
public Observable<List<DataBaseRecord>> getAllRecords() {
return mSpendDBRx.getAllRecords()
.toList()
.compose(applySchedulers());
}
А если нужно подменить new SpendDBImpl();
или new SpendDBRx(mSpendDB);
для выполнения тестов, можно воспользоваться популярным Dagger.
На github Вы можете найти исходники с комментариями, а также рабочий пример этой небольшой библиотеки.
Целью этой статьи было показать насколько полезным может быть Annotation Processing, позволяющий избавиться от написания однотипного кода. И, надеюсь, у Вас могут появиться новые идее по использованию этого инструмента в своих проектах.
Автор: qwert2603