Избежание глобальной зависимости от базовых данных (или аналогичных сред персистентности)

Question

Каркас персистентности данных, такой как Core Data, может значительно ускорить разработку приложений за счет сокращения объема кода, необходимого для поддержки хранения данных.

Однако одним из основных недостатков принятия такой структуры является введение того, что неизбежно становится глобальной и сквозной зависимостью, прямо через кодовую базу.

Зависимость от таких платформ бывает в нескольких формах, включая, помимо прочего:

1. Ссылка или создание подклассов ключевых классов API - поэтому для Core Data это будут такие вещи, как NSManagedObjectContext и NSManagedObject и т. Д.

2. Поведенческая зависимость - платформа предоставляет некоторые менее очевидные неявные функциональные возможности, от которых приложение каким-то образом зависит в своей работе. В случае базовых данных это может быть автоматическое управление обратными отношениями.

3. Зависимость функций - платформа предоставляет функции, которых нет у других опций. В случае базовых данных это может быть многоуровневая отмена.

С этим умом мои вопросы:

1. Какие стратегии лучше всего использовать при работе с новым кодом, чтобы избежать введения такой сквозной зависимости, как эта?

2. Какие методы лучше всего использовать, когда существует существующая зависимость, которую необходимо устранить? Скажем, например, Apple устарела Core Data, и поэтому ее необходимо заменить, на iOS-приложении должно стать кроссплатформенным приложением.

Answer 1

Изолируйте модель вашего домена от вашей модели постоянства. Изолируйте свой уровень персистентности от уровня вашего домена, используя DAL или шаблоны репозитория, чтобы сохранить его изолированным. Это дорогое, часто утомительное, сопоставление моделей доменов с постоянными сущностями, и разрушает значительную часть инструментов автоматического реляционного сопоставления доменов.

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