Где лучшее место для вызова методов, которые взаимодействуют с моей базой данных?

Question

Я создаю приложение, которое взаимодействует с базой данных Firestore. На данный момент у меня есть одноэлементный класс DatabaseManager, который имеет все методы, относящиеся к базе данных Firestore (т.е. методы get / post).

У меня есть модель User под названием User, которая имеет такие свойства, как name, email, photoURL и некоторые свойства, специфичные для приложения. Любой пользователь может отредактировать свой профиль для обновления информации из контроллера представления с именем EditProfileViewController.

Теперь мой вопрос: лучше ли позвонить DatabaseManager.shared.updateInfo(forUser: user) (где user - это User экземпляр) из EditProfileViewController, User или из какого-то другого места?

Извините, если это очевидный вопрос, но в приложении будет много моментов, где мне понадобится аналогичная логика, поэтому я хотел знать, какой дизайн лучший. Также я уверен, что этот вопрос больше связан с MVC, чем с Firebase / Swift.

Answer 1

Пара мыслей:

1. Вместо прямого доступа к синглтону с помощью DatabaseManager.shared.update(for:) я мог бы вместо этого иметь свойство для менеджера базы данных, инициализировать / внедрить его с помощью DatabaseManager.shared и иметь все, что нужно для взаимодействия с базой данных, используя ссылка, например, dataManager.update(for:). Цель состоит в том, чтобы позволить вашим модульным тестам издеваться над менеджером базы данных, если и когда это необходимо.

2. Я бы не хотел, чтобы контроллер вида взаимодействовал напрямую с DatabaseManager. Многие из нас рассматривают контроллер представления, который напрямую взаимодействует с объектами UIKit / AppKit, как часть более широкой буквы «V» в MVC / MVP / MVVM / что угодно. Мы часто выводим бизнес-логику (включая взаимодействие с менеджером баз данных) из контроллера представления.

   Лично я бы тоже не похоронил его под объектом User. Я поместил бы его в расширение менеджера баз данных и вызвал его из модели представления, докладчика или из того, что вы лично хотите назвать этим объектом с помощью бизнес-логики.

Answer 2

Есть ли причина, по которой вы используете синглтон для хранения всей логики Firestore? Пользовательская модель должна содержать метод updateInfo.

Вот пример, который я использовал с Firestore:

class Group {

    // can read the var anywhere, but an only set value in this class
    private(set) var groupName: String!
    private(set) var guestsInGroup: Int!
    private(set) var joinedGroup: Bool!
    private(set) var timeStampGroupCreated: Date!
    private(set) var documentId: String!

    init(groupName: String, guestsInGroup: Int, joinedGroup: Bool, timeStampGroupCreated: Date, documentId: String) {
        self.groupName = groupName
        self.guestsInGroup = guestsInGroup
        self.joinedGroup = joinedGroup
        self.timeStampGroupCreated = timeStampGroupCreated
        self.documentId = documentId
    }


    // method to parse Firestore data to array, that table view will display
    class func parseData(snapshot: QuerySnapshot?) -> [Group]{
        var groups = [Group]()

        guard let snap = snapshot else { return groups }
        for document in snap.documents {
            let data = document.data()
            let groupName = data[GROUP_NAME] as? String ?? "No Group Name"
            let guestsInGroup = data[GUESTS_IN_GROUP] as? Int ?? 0
            let joinedGroup = data[JOINED_GROUP] as? Bool ?? false
            let timeStampGroupCreated = data[TIMESTAMP_GROUP_CREATED] as? Date ?? Date()
            let documentId = document.documentID

            // add objects with fetched data into thoughts array
            let newGroup = Group(groupName: groupName, guestsInGroup: guestsInGroup, joinedGroup: joinedGroup, timeStampGroupCreated: timeStampGroupCreated, documentId: documentId)

            groups.append(newGroup)
        }
        return groups
    }
}