#ios #core-data #architecture #dependencies #dependency-management
#iOS #core-data #архитектура #зависимости #управление зависимостями
Вопрос:
Фреймворки сохранения данных, такие как Core Data, могут значительно ускорить разработку приложений за счет сокращения объема кода, необходимого для поддержки хранения данных.
Однако одним из основных недостатков внедрения такого фреймворка является внедрение того, что неизбежно становится глобальной и сквозной зависимостью прямо через кодовую базу.
Зависимость от таких фреймворков бывает нескольких форм, включая, но не ограничиваясь ими:
-
Ссылки на ключевые классы API или их подклассы — итак, для Core Data это были бы такие вещи, как
NSManagedObjectContextиNSManagedObjectetc. -
Поведенческая зависимость — фреймворк предоставляет некоторые менее очевидные неявные функциональные возможности, от работы которых каким-то образом фундаментально зависит приложение. В случае Core Data это может быть автоматическое управление обратными связями.
-
Функциональная зависимость — фреймворк предоставляет функции, которых нет в других вариантах. В случае Core Data это может быть многоуровневая отмена.
Имея это в виду, мои вопросы таковы:
-
Какие стратегии лучше всего использовать при работе над новым кодом, чтобы избежать введения такой серьезной сквозной зависимости, как эта?
-
Какие методы лучше всего использовать, когда существует существующая зависимость, которую необходимо разорвать? Скажем, например, Apple устарела Core Data, и поэтому ее необходимо заменить, приложение только для iOS должно стать кроссплатформенным приложением.
Ответ №1:
Изолируйте свою модель домена от своей модели сохранения. Изолируйте свой уровень сохранения от уровня домена, используя DALS или шаблоны репозиториев, чтобы сохранить его изолированным. Это дорого, часто утомительно, сопоставление моделей предметной области с постоянными объектами и сводит на нет большую часть ценности инструментов автоматического сопоставления домена-> отношения.
Здесь вам действительно придется принять трудное решение, хотите ли вы независимости, если да, вам придется архитектурно изолировать, что будет дорого. Это упростит другие задачи, хотя тестирование изолированной модели предметной области — прекрасная вещь. Тестирование моделей, поведение которых скрыто в фреймворках, — это мучительное упражнение.