Следует ли Абстрагироваться от Базы Данных?
Мнение, что, имея слой абстракции, можно легко переключиться с одной БД на другую широко распространено среди многих программистов. Но даже при том, что оно довольно популярно, оно неверно. Это явление называется ложным мифом об абстрагировании от базы данных.
Давайте проанализируем его и посмотрим, что именно тут не так.
Привязка к поставщику
Основное преимущество абстрагирования вашей БД — это избежание привязки к поставщику. Другими словами, если по какой-либо причине вы захотите отказаться от текущей СУБД, вы легко сможете это сделать. Чтобы сделать возможным такой переход, вы должны спроектировать свой уровень доступа к данным так, чтобы он поддерживал несколько реализаций базы данных. Для этого вы вводите интерфейс, вроде
IDataAccess, а затем предлагаете реализацию для вашей текущей СУБД.Видимое и невидимое
Поначалу это звучит разумно, но, принимая решение, вы должны учитывать обе стороны:
- Желаемые результаты, которые являются видимой частью уравнения.
- Непредвиденные последствия, невидимая часть.
В контексте абстрагирования от базы данных:
- Видимая часть — это преимущества, которые даёт вам абстракция.
- Невидимая часть — это (часто скрытая) стоимость этой абстракции.
Какова же стоимость этой абстракции?
Стоимость — это всё время, которое потребовалось вам для реализации этой возможности. Вот почему абстрагирование от базы данных — это антипаттерн. Люди часто ценят преимущества этой абстракции, потому что они очевидны: тот факт, что переключиться легко, очевиден для всех.
Но они редко учитывают его недостатки, потому что недостатки невидимы. Как только вы вводите дополнительную сложность для абстрагирования от базы данных, вы воспринимаете это как данность. Вам просто не с чем сравнивать, поэтому дополнительное время, которое вам потребовалось для поддержания этой абстракции, остаётся незамеченным.
Но это дополнительное время огромно. Как говорится, «недели программирования могут сэкономить вам часы планирования». Именно это получается, когда кто-то хвастается, что сэкономил 2 дня при переходе на другую базу данных. Вероятно, им потребовалось несколько недель дополнительного времени, чтобы сделать это возможным. И в будущем это будет стоить дороже! Внедрение абстракции — не просто одноразовое действие, вам придётся поддерживать её на протяжении всего проекта, даже если больше никогда не придётся переключаться снова.
Наименьший общий делитель
Другая проблема заключается в том, что вы не сможете использовать расширенные функции, имеющиеся в вашей текущей СУБД. Вы привязаны к наименьшему общему делителю — функциональности, которая присутствует во всех реляционных базах данных, что означает, что вы не можете полностью раскрыть потенциал своей базы данных.
Это не сработает, и вы обнаружите это слишком поздно
Основная проблема заключается в том, что как бы вы ни старались, между разными СУБД будут возникать мелкие, а то и не очень мелкие различия, которые могут кардинально повлиять на то, как будет работать ваше приложение.
Что же делать?
Просто следуйте YAGNI и работайте со своей текущей базой данных, как будто вы никогда не собираетесь отказываться от нее. Скорее всего, вы никогда этого не сделаете, и все ваши абстракции в любом случае пропадут зря.
А если вам всё же нужно переключиться, подходите к процессу переключения не просто как к отказу от одной реализации
IDataAccess в пользу другой, а как к портированию: вы портируете своё приложение с одной СУБД на другую.Главный инструмент, который поможет добиться успеха при портировании, —качественные интеграционные тесты, т.е. тесты, которые не имитируют вашу базу данных, а реально обращаются к ней.
Источник: https://enterprisecraftsmanship.com/posts/should-you-abstract-database/