Всем привет! Меня зовут Игорь Сорокин. В этой статье я поделюсь историей о том, куда нас завёл очередной рефакторинг, как мы оттуда выбрались, попутно разработав слой хранения данных. Также приведу практические примеры реализации, покажу подход, который удалось разработать, и расскажу об особенностях, с которыми мы столкнулись. Но обо всём по порядку.
Статья будет полезна, если вы задумались о внедрении базы данных в своё приложение или уже используете её, но без единого подхода. Если же вы не используете базу данных, то, скорее всего, вы счастливый человек.
Предыстория
Исторически так сложилось, что для работы с сетью и сохранения ответов в базу данных в Юле использовался RestKit — мощная библиотека с большим функционалом, написанная ещё на старом добром Objective-C. Она позволяет делать api-запросы, декодить JSON в NSManagedObject сущности и тут же сохранять их в CoreData. Однако библиотека неумолимо постарела, а её поддержка и вовсе остановлена. Да и ребята в iOS-команде неохотно ею пользовались.
Так, однажды на пятничной встрече в офисе за круглым столом и со вкусной пиццей, мы вместе с командой платформы окончательно решили выпилить RestKit и заменить его на Alamofire. Почему именно Alamofire? Все просто: это современная библиотека, написанная на Swift. У неё большое комьюнити и хорошая поддержка. К тому же, большинство iOS-разработчиков с ней знакомы. Одним словом, profit!
Написать новый api-клиент — задача несложная, но перед нами встал вопрос: как быть с сохранением ответов в базу? Работа с CoreData была размазана по всему проекту, отсутствовал единый подход, и это порождало некоторые проблемы: запутанность кода, сложности онбординга, трудности с многопоточностью.
Мы решили, что если уж переписывать api-менеджеры, то качественно! Так, перед нами встала новая задача — спроектировать слой хранения данных. Вот какие особенности реализации мы учли в целях:
цель №1: описать общий интерфейс так, чтобы при необходимости можно было заменить CoreData на другое хранилище;
цель №2: скрыть детали реализации — разработчик должен оперировать доменными моделями, а не сущностями и контекстами;
цель №3: иметь возможность в одну и ту же сущность сохранять разные модели.
Мы запаслись терпением, пиццей и смузи, и пошли работать…
Проектирование интерфейса
Отталкиваясь от наших целей, мы накидали желаемый интерфейс и назвали это Repository. Ниже представлены его методы:
class Repository<DomainModel, DBEntity> {
func persist<Model, PersistMapper>(_ model: Model,
mapper: PersistMapper,
completion: ((Result<DomainModel, Error>) -> Void)?) where PersistMapper: PersistableMapper,
PersistMapper.FromModel == Model,
PersistMapper.ToModel == DBEntity { ... }
func persist<Model, PersistMapper>(_ models: [Model],
mapper: PersistMapper,
completion: ((Result<[DomainModel], Error>) -> Void)?) where PersistMapper: PersistableMapper,
PersistMapper.FromModel == Model,
PersistMapper.ToModel == DBEntity { ... }
func fetch<Query>(searchQuery: Query, completion: @escaping (Result<[DomainModel], Error>) -> Void) where Query: SortedDatabaseQuery, Query.DBEntity == DBEntity { ... }
func fetchAll(completion: @escaping (Result<[DomainModel], Error>) -> Void) { ... }
func removeAll<Query>(matching query: Query, completion: ((Result<Void, Error>) -> Void)?) where Query: DatabaseQuery, Query.DBEntity == DBEntity { ... }
func removeAll(completion: ((Result<Void, Error>) -> Void)?) { ... }
func count<Query>(matching query: Query) -> Int where Query: DatabaseQuery, Query.DBEntity == DBEntity { ... }
func count() -> Int { ... }
func first<Query>(matching query: Query) -> DomainModel? where Query: SortedDatabaseQuery, Query.DBEntity == DBEntity { ... }
func first() -> DomainModel? { ... }
}Так как Repository дженериковый, мы решили использовать абстрактный класс, чтобы избежать танцев с бубнами при размывании типов. DomainModel — тип доменной модели, с которой работает репозиторий, а DBEntity — сущность, которая ассоциируется с доменной моделью. Repository содержит основные CRUD-методы, такие как сохранение/обновление, выборка, удаление, а также метод для запроса на количество элементов.
Руководствовались мы правилом инверсии зависимостей, поскольку именно оно позволит в будущем легко заменить одну реализацию на другую. А при проектировании не завязывались на деталях CoreData, а старались писать абстрактный интерфейс.
В общем виде работу с репозиторием мы представляли так:
Сохранение
Итак, как вы помните, важной целью репозитория для нас является возможность сохранять разные модели. Значит, помимо моделей нужно передать маппер, умеющий конвертировать их в нужные сущности. Мы специально вынесли логику конвертации в отдельный объект, потому что не хотели раздувать модели и сущности. Маппер описан специальным протоколом PersistableMapper.
protocol PersistableMapper {
associatedtype FromModel
associatedtype ToModel
func createEntity(from model: FromModel) -> ToModel
func updateEntity(_ entity: inout ToModel, from model: FromModel)
func keyPathsForPrimaryKeys() -> [PrimaryKeysPaths<FromModel, ToModel>]
}PersistableMapper содержит два дженериковых типа:
FromModel — модель, которую нужно конвертировать;
ToModel — сущность, в которую нужно конвертировать.
Для конвертации мы добавили два метода:
updateEntity(:from:) — для обновления полей, когда в базе уже есть нужная сущность;
createEntity(from:) — для создания сущности и заполнения её данными.
Помимо этого, протокол требует реализовать метод keyPathsForPrimaryKeys(), который возвращает массив PrimaryKeysPaths. Это структура, содержащая PartialKeyPath для модели и сущности. По сути, это первичные ключи, по которым мы будем понимать, есть ли у нас соответствующая сущность в базе или нет. Если значения всех первичных ключей равны, то считается, что модель и сущность описывают один и тот же объект.
Фильтрация и сортировка
Для выборки и удаления нужно было придумать способ фильтрования и сортировки элементов. Мы не хотели напрямую передавать NSPredicate и NSSortDescriptor, поскольку есть вероятность ошибиться — например, передать NSPredicate, предназначенный для другой сущности. Поэтому решили добавить новый уровень абстракции. Создали специальные протоколы: DatabaseQuery — для выборки, SortedDatabaseQuery — для выборки и сортировки.
protocol SortedDatabaseQuery: DatabaseQuery {
var sortDescriptors: [NSSortDescriptor] { get }
}
protocol DatabaseQuery {
associatedtype DBEntity
var predicate: NSPredicate? { get }
}Данные протоколы дженериковые — чтобы знать, для какой сущности предназначен Query-объект. Благодаря этому не получится передать Query, созданную для работы с одной сущностью, в Repository, работающий с другой. Это своеобразная защита, и мы получим ошибку на этапе компиляции.
На следующем этапе нужно было реализовать новый протокол, используя CoreData.
Реализация репозитория
Так как сущностью CoreData является NSManagedObject, а мы хотим получать от репозитория доменные модели, то понадобился ещё один маппер, задачей которого будет конвертация сущности в доменные модели. Так родился протокол DomainModelCoreDataMapper.
protocol DomainModelCoreDataMapper {
associatedtype DomainModel
associatedtype DBEntity: NSManagedObject
func model(from entity: DBEntity) -> DomainModel?
}Заметьте, что помимо метода конвертации, у протокола есть требование, что DBEntity должен быть NSManagedObject.
CoreDataRepository тоже дженериковый, но в отличие от Repository ему нужно указать не тип модели и сущности, а сразу маппер, который реализует протокол DomainModelCoreDataMapper, за счёт чего сущность всегда будет NSManagedObject или его наследником.
final class CoreDataRepository<DomainModelMapper: DomainModelCoreDataMapper>: Repository<DomainModelMapper.DomainModel, DomainModelMapper.DBEntity> {
typealias DomainModel = DomainModelMapper.DomainModel
typealias EntityMO = DomainModelMapper.DBEntity
init(domainModelMapper: DomainModelMapper, contextProvider: CoreDataContextProvider) {
self.contextProvider = contextProvider
self.domainModelMapper = domainModelMapper
}
...
}При создании также передаётся протокол CoreDataContextProvider. Его реализует YoulaCoreDataContextProvider. Это синглтон-объект, предоставляющий настроенный контекст для CoreDataRepository.
При сохранении модели мы должны проверить, есть ли такая сущность в базе. Если нет, то создать её. В рамках CoreData эту обязанность мы возложили на PersistableMapper, так как он знает первичные ключи и способ обновления сущности. Кроме того, мы могли бы добавить вложенный маппер, чтобы иметь возможность обновлять связи (relations) сущности. Наше расширение выглядит так:
extension PersistableMapper where ToModel: NSManagedObject {
typealias Model = FromModel
typealias DBEntity = ToModel
// Вспомогательные методы для получения значений по PartialKeyPath
private func modelPrimaryKey(_ model: Model, primaryKeyPath: PartialKeyPath<Model>) -> Any {
return model[keyPath: primaryKeyPath]
}
private func entityPrimaryKey(_ entity: DBEntity, primaryKeyPath: PartialKeyPath<DBEntity>) -> Any {
return entity[keyPath: primaryKeyPath]
}
// Реализуем обязательный метод протокола
func createEntity(from model: FromModel) -> ToModel {
return DBEntity(entity: DBEntity.entity(), insertInto: nil)
}
// Вспомогательные методы для создания/нахождения сущности и обновления полей
//
// Алгоритм:
// Запрашиваем/создаем сущность
// Если создаем сущность через метод createEntity(from:), то ее нужно вставить в контекст
// Обновляем поля с помощью метода протокола updateEntity(:from:)
// Возвращаем сущность
@discardableResult
func entity(from model: Model, in context: NSManagedObjectContext) -> DBEntity { ... }
@discardableResult
func entities(from models: [Model], in context: NSManagedObjectContext) -> [DBEntity] { ... }
}Теперь можно приступить к реализации методов репозитория. В качестве примера я привёл реализацию сохранения и выборки. Остальные методы реализованы похожим образом:
private func persistModel<Model, PersistMapper>(_ model: Model,
mapper: PersistMapper,
completion: ((Result<DomainModel, Error>) -> Void)?) where DomainModelMapper.DBEntity == PersistMapper.ToModel,
Model == PersistMapper.FromModel,
PersistMapper: PersistableMapper {
// Получаем worker context
let context = contextProvider.workerContext()
context.perform { [weak self] in
guard let self = self else {
return
}
// Маппер найдет в базе нужную сущность, если такой нет, то создаст ее
// Заполнит ее значениями из model
// Вернет NSManagedObject
let entity = mapper.entity(from: model, in: context)
// Конвертируем полученную сущность в доменную модель
guard let domainModel = self.domainModelMapper.model(from: entity) else {
// Вызываем completion на main потоке с ошибкой маппинга
DispatchQueue.main.asyncCompletion(completion: completion, with: .failure(CoreDataError.modelMapping))
return
}
// сохраняем контекст
self.safelySaveToPersistentStore(context: context, completion: { error in
if let error = error {
completion?(.failure(error))
} else {
completion?(.success(domainModel))
}
})
}
}
private func fetchModels(predicate: NSPredicate?,
sortDescriptors: [NSSortDescriptor]?,
completion: @escaping (Result<[DomainModel], Error>) -> Void) {
// Получаем worker context
let context = contextProvider.workerContext()
context.perform { [weak self] in
guard let self = self else {
return
}
// Создаем NSFetchRequest
let entityName = EntityMO.entity().name ?? ""
let fetchRequest = NSFetchRequest<EntityMO>(entityName: entityName)
fetchRequest.sortDescriptors = sortDescriptors
fetchRequest.predicate = predicate
do {
// Получаем все сущности
let entities = try context.fetch(fetchRequest)
var domainModels: [DomainModel] = []
// Конвертируем сущности в доменные модели
for entity in entities {
guard let domainModel = self.domainModelMapper.model(from: entity) else {
// Вызываем completion на main потоке с ошибкой маппинга
DispatchQueue.main.asyncCompletion(completion: completion, with: .failure(CoreDataError.modelMapping))
return
}
domainModels.append(domainModel)
}
// Вызываем completion на main потоке с переданным результатом
DispatchQueue.main.asyncCompletion(completion: completion, with: .success(domainModels))
} catch {
DispatchQueue.main.asyncCompletion(completion: completion, with: .failure(error))
}
}
}Попробуем?
Посмотрим, что у нас получилось. Допустим, перед нами стоит задача: сделать запрос на пользователя и сохранить его в базу. Вместо использования CoreData напрямую попробуем использовать репозиторий. Для начала проверим, какие модели у нас есть.
// Модель ответа с сервера
struct UserResponse: Decodable {
let identifier: String
let name: String
let type: String
let image: ImageResponse
let isOnline: Bool
}
// Доменная модель
struct User {
let identifier: String
let name: String
let type: UserType
let image: Image
let isOnline: Bool
}
// Сущность в CoreData
final class UserMO: NSManagedObject {
@NSManaged var identifier: String?
@NSManaged var name: String?
@NSManaged var type: String?
@NSManaged var image: ImageMO?
@NSManaged var isOnline: NSNumber?
}Для сохранения моделей нужно реализовать Persistable-мапперы. Реализуем маппер из UserResponse в UserMO. Маппер из User в UserMO будет выглядеть аналогично:
struct UserResponsePersistableMapper: PersistableMapper {
typealias FromModel = UserResponse
typealias ToModel = UserMO
// Вложенный маппер, отвечающий за конвертацию ImageResponse в ImageMO
private let imageResponseMapper = ImageResponsePersistableMapper()
func updateEntity(_ entity: inout UserMO, from model: UserResponse) {
// Обновляем поля
entity.name = model.name
entity.type = model.type
entity.isOnline = model.isOnline as NSNumber
guard let context = entity.managedObjectContext else {
return
}
// Для обновления связи используем метод из нашего расширения
entity.image = imageResponseMapper.entity(from: model.image, in: context)
}
func keyPathsForPrimaryKeys() -> [PrimaryKeysPaths<UserResponse, UserMO>] {
// Указываем первичные ключи
return [PrimaryKeysPaths(modelKeyPath: \UserResponse.identifier,
entityKeyPath: \UserMO.identifier)]
}
}Также нужно написать CoreDataMapper для конвертации UserMO в доменный User.
final class UserCoreDataMapper: DomainModelCoreDataMapper {
typealias DomainModel = User
typealias DBEntity = UserMO
// Вложенный маппер, отвечающий за конвертацию ImageMO в Image
private let imageMapper = ImageCoreDataMapper()
func model(from entity: UserMO) -> User? {
guard
let identifier = entity.identifier,
let name = entity.name,
let type = UserType(rawValue: entity.type ?? ""),
let imageEntity = entity.image,
let image = imageMapper.model(from: imageEntity),
let isOnline = entity.isOnline?.boolValue
else {
return nil
}
return User(identifier: identifier,
name: name,
type: type,
image: image,
isOnline: isOnline)
}
}Модели готовы, мапперы написаны. Пристегнитесь, мы взлетаем! 🚀
final class ProfileInteractor: ProfileInteractorInput {
// Репозиторий для работы с базой
private let userRepository: Repository<User, UserMO>
// Сервис для работы с апи
private let userService: UserServiceDescription
// id пользователя, с которым работаем
private let userId: String
init(userId: String) {
self.userId = userId
// В качестве хранилища используем CoreData
userRepository = CoreDataRepository(domainModelMapper: UserCoreDataMapper(), contextProvider: YoulaCoreDataContextProvider.default)
userService = UserService()
}
func obtainUser(id: String, completion: @escaping (Result<User, Error>) -> Void) {
// Запрашиваем пользователя с сервера
userService.obtainUser(id: id, completion: { [weak self] result in
switch result {
case .success(let userResponse):
// Пользователь получен (UserResponse)
// Можем сохранить UserResponse, главное передать маппер, который умеет это делать
// На выходе репозиторий вернет доменную модель (User), поэтому результат мы сразу возвращаем в completion
self?.userRepository.persist(userResponse, mapper: UserResponsePersistableMapper(), completion: completion)
case .failure(let error):
completion(.failure(error))
}
})
}
func updateUserName(_ newName: String) {
// Создаем объект для фильтрации
// Объект содержит NSPredicate и массив NSSortDescriptor
let query = UserIdQuery(id: userId)
// Запрашиваем первого пользователя
guard var user = userRepository.first(matching: query) else {
return
}
// Меняем имя
user.name = newName
// Сохраняем обновленного пользователя, передаем соответствующий маппер
userRepository.persist(user, mapper: UserPersistableMapper(), completion: nil)
}
private struct UserIdQuery: SortedDatabaseQuery {
typealias DBEntity = UserMO
let id: String
var predicate: NSPredicate? {
return NSPredicate(format: "%K == %@", #keyPath(DBEntity.identifier), id)
}
var sortDescriptors: [NSSortDescriptor] {
return []
}
}
}Круто! Но это не конец
Казалось бы, всё готово! Но мы столкнулись ещё с одним челленджем. На один и тот же запрос наш бэкенд может возвращать разный набор полей. Нужно было добиться следующей логики: если поле пришло в ответе, то его следует перезаписать в сущности при сохранении, если же не пришло, то поле в сущности не трогать, поскольку там могло быть значение, которое приходило в других ответах.
Для декодинга мы собирались использовать Codable, но с ним решить эту проблему невозможно, так как поле, которое пришло со значением null, и поле, которое не пришло вообще, в модели будут представлены как nil. Поэтому при сохранении в базу мы не сможем узнать, надо обновлять поле или нет.
Немного покумекав, мы сделали специальный Property Wrapper, а чтобы его можно было использовать при декодинге, расширили KeyedDecodingContainer. Благодаря враперу можно обращаться к полю как к обычному опциональному полю, а если потребуется дополнительная информация, то обратиться к projectedValue через нотацию — $.
@propertyWrapper
public struct DetailedResponse<Value> {
public enum Response {
// поле не пришло
case notCome
// поле пришло, но null
case null
// поле пришло со значением
case value(Value)
}
public let wrappedValue: Value?
public let projectedValue: Response
public init(response: Response) {
self.projectedValue = response
if case let .value(value) = response {
self.wrappedValue = value
} else {
self.wrappedValue = nil
}
}
}
public extension KeyedDecodingContainer {
func decodeDetailResponse<T>(_ type: T.Type, forKey key: KeyedDecodingContainer<Key>.Key) throws -> DetailedResponse<T> where T: Decodable {
guard contains(key) else {
return DetailedResponse(response: .notCome)
}
if let result = try decodeIfPresent(type, forKey: key) {
return DetailedResponse(response: .value(result))
} else {
return DetailedResponse(response: .null)
}
}
}Разработчикам остаётся пометить нужное поле как @DetailedResponse и реализовать инициализатор Decodable. А в маппере при сохранении можно опираться на projectedValue, которое предоставит информацию о том, пришло поле или нет.
Предположим, что поле isOnline в модели нашего юзера иногда может не приходить. В этом случае наш декодинг надо переделать следующим образом:
struct UserResponse: Decodable {
let identifier: String
let name: String
let type: String
let image: ImageResponse
// Помечаем враппером
@DetailedResponse var isOnline: Bool?
enum CodingKeys: String, CodingKey { ... }
init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: CodingKeys.self)
identifier = try container.decode(String.self, forKey: .identifier)
name = try container.decode(String.self, forKey: .name)
type = try container.decode(String.self, forKey: .type)
image = try container.decode(ImageResponse.self, forKey: .image)
// Декодим с помощью специального метода
_isOnline = try container.decodeDetailResponse(Bool.self, forKey: .isOnline)
}
struct User {
let identifier: String
let name: String
let type: UserType
let image: Image
// Теперь поле опциональное
let isOnline: Bool?
}При сохранении смотрим на projectedValue.
struct UserResponsePersistableMapper: PersistableMapper {
typealias FromModel = UserResponse
typealias ToModel = UserMO
private let imageResponseMapper = ImageResponsePersistableMapper()
func updateEntity(_ entity: inout UserMO, from model: UserResponse) {
entity.name = model.name
entity.type = model.type
// Свичимся по DetailedResponse.Response
switch model.$isOnline {
case .notCome:
break
case .null:
entity.isOnline = nil
case .value(let newIsOnline):
entity.isOnline = newIsOnline as NSNumber
}
guard let context = entity.managedObjectContext else {
return
}
entity.image = imageResponseMapper.entity(from: model.image, in: context)
}
func keyPathsForPrimaryKeys() -> [PrimaryKeysPaths<UserResponse, UserMO>] {
return [PrimaryKeysPaths(modelKeyPath: \UserResponse.identifier,
entityKeyPath: \UserMO.identifier)]
}
}Вместо итога
На данный момент мы зарефакторили более половины менеджеров с использованием новых подходов: api-сервисы на Alamofire + репозиторий. И уже видим улучшения, ради которых это всё затевали. А именно:
постепенно уменьшаем зависимость от RestKit и скоро сможем его выпилить;
писать и понимать код стало проще, выработался единый подход для работы с базой;
нет нужды заморачиваться с деталями CoreData — можно оперировать доменными моделями.
Велком в комменты — обсудить нашу реализацию, поделиться болью или предложить рекомендации.
PS: При разработке вдохновлялись статьей https://habr.com/ru/post/542752/
