Является ли хорошей практикой использование статического соединения с базой данных?
Я использую платформу SQLite.swift для своего приложения iOS. У меня есть класс DatabaseService, в котором я создаю соединение с базой данных и выполняю все операции CURD. Я создавал экземпляр этого класса и создавал соединение на каждом контроллере, но недавно я изменил переменную базы данных на static и создал соединение один раз для всех контроллеров. Я не уверен, что это хорошая практика. Вот как я это делаю:
static var db: Connection?
init() {
if DatabaseService.db != nil {
return
}
let path = NSSearchPathForDirectoriesInDomains(
.documentDirectory, .userDomainMask, true
).first!
do {
let fileManager = FileManager()
try fileManager.copyfileToUserDocumentDirectory(forResource: "db", ofType: "sqlite3")
// Empty database will be created if file does not exist
DatabaseService.db = try? Connection("\(path)/db.sqlite3")
print("Connection successful")
} catch let error {
print("Unable to connect with the database. \(error)")
}
}
Ответы 1
Я предполагаю, что настоящий ответ таков: если вы знаете, что делаете, и хорошо разбираетесь в том, как это делать безопасно, тогда конечно.
Но раз уж вы спрашиваете: мой ответ - нет.
Статическая переменная, которую вы здесь показываете, является одноэлементным шаблоном, если вы используете его везде. одноэлементный образец часто кажется правильным, но в тот момент, когда вы начинаете добавлять потоки и хотите использовать другого поставщика данных, все начинает глючить, становиться более сложным и некрасивым. Лучше использовать внедрение зависимости с заводской образец, используя объект вы создали только один раз.
На самом деле кода для этого не так уж много. Выбор просто появляется, когда вы хотите внедрить его (во время компиляции или во время выполнения), и Swift упрощает все это. Дайте мне знать, если вы хотите отредактировать пример. Это немного больше кода, чтобы сделать это заранее, но в долгосрочной перспективе для большинства ситуаций это избавит вас от многих душевных страданий. Изучите плюсы и минусы синглтона. Большинство согласны с тем, что в большинстве ситуаций это плохая идея.
Я собираюсь добавить отрывок из книга, который НАСТОЯТЕЛЬНО РЕКОМЕНДУЮ:
Major problems can be caused by global states, for example, the usage of Singletons or static members in your unit under test. Not only is it that Singletons increase the coupling between software units. They also often hold a global state that circumvents unit test independence. For instance, if a certain global state is the precondition for a successful test, but the previous test has mutated that global state, it can cause serious trouble. Especially in legacy systems, which are often littered with Singletons, this begs the question: how can I get rid of all those nasty dependencies to those Singletons and make my code better testable? Well, that’s an important question I discuss...
В этой книге также цитируется интервью с авторами знаменитой книги Шаблоны проектирования, где авторы в основном заявляют, что не прочь отказаться от одноэлементного шаблона, потому что он никогда не используется правильно.
Авторы знаменитой и влиятельной книги об абстрактных шаблонах дизайна шутят (я думаю, что это шутка) об исключении шаблона проектирования синглтона из недавно отредактированной версии своей книги ...
Может быть, настоящий ответ на самом деле всегда отрицательный.
@Moritz Я чувствую, что теперь могу считать себя одним из многих, кто оказал огромную услугу индустрии, сделав сообщение с предупреждением о синглтоне. Надеюсь, мой пост и ваш комментарий увидят тысячи глаз ... Сегодня хороший день ...
Согласовано. Они могут создать класс-оболочку с методами для операций с базой данных и передать этот служебный класс (через инициализаторы, переходы и т. д., По выбору) объектам, которым он нужен. Или получите доступ к нему через шаблон делегата. Есть много лучших вариантов, чем статический / синглтон. Также критически важен доступ к базе данных, поэтому вы все равно не хотите открывать его для всего приложения.