OrmLite внутри модуля Android

Я пытаюсь поместить все запросы к базе данных в модуль в Android, чтобы централизовать весь доступ к DDBB в одном месте.

Мне интересно, делаю ли я какую-либо ошибку, делая это. Приложения работают правильно, но меня беспокоят лучшие практики.

У меня есть статический класс с именем DatabaseRequest, где все запросы находятся внутри, например:

public static void insertUser(Context context, User user) {
    DataBaseHelper mDataBaseHelper = OpenHelperManager.getHelper(context, DataBaseHelper.class);

    try {
        Dao<User, Integer> dao = mDataBaseHelper.getUserDao();
        dao.createOrUpdate(user);

    } catch (SQLException e) {
        e.printStackTrace();
    } finally {
        if (mDataBaseHelper != null) {
            OpenHelperManager.releaseHelper();
        }
    }
}

Параметр контекста — это контекст действия, которое делает запрос.

Есть ли проблемы с производительностью, связанные с этим кодом?

Заранее спасибо ;)


android android-database ormlite
person MarcForn    schedule 07.11.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Нет, как сказал Грей (создатель ORMlite) в этом посте:

можно ли создать помощник базы данных ORMLite в приложении класс?

Что наиболее важно в вашем коде, так это то, что он гарантирует единственный экземпляр databaseHelper. Каждый экземпляр имеет собственное соединение с базой данных, и проблемы возникают, когда в программе открыто более одного (1) соединения с базой данных. Sqlite обрабатывает несколько потоков, использующих одно и то же соединение одновременно, но не справляется с несколькими соединениями должным образом, что может привести к несогласованности данных.

И в вашем случае у вас может быть несколько подключений одновременно.

Я могу задать вам мой подход к тому, как я использую ORMlite, у меня есть один единственный класс public class DbHelper extends OrmLiteSqliteOpenHelper, который заботится о создании соединения с базой данных и содержит все поля Dao. У вас будет код обновления базы данных и некоторые другие вещи, поэтому рассмотрите возможность создания фасадных классов. В моем случае каждый фасад содержит один объект Dao для одного класса модели, где я сохраняю логику для получения сложного элемента (а для простых случаев я просто делегирую ее объекту Dao.

person Than    schedule 07.11.2015
comment
По словам Грея, вы сочтете более подходящим поместить всю логику в класс приложения, как объясняется в сообщении? - person MarcForn; 07.11.2015
comment
Вы когда-нибудь явно выпускали свой DBHelper, @Than? Или вы просто создаете Singleton, подключенный к жизненному циклу Application. - person Sakiboy; 26.06.2017