Страницы

суббота, 7 апреля 2012 г.

Старый недобрый Repository.

  Уже долгие годы шаблон репозиторий будоражит умы опытных (и не очень) программистов, но актуален ли он сейчас? Позвольте объясню.

В чём проблема?

  Еще лет 10 назад хороших  технологий доступа к данным просто не существовало. Обращение к БД приосходило в виде хранимых процедур, или зашитых в код приложения запросов, или некой обёртки над ними. Весь этот ад SQL-кода был весьма некстати в коде логики доменных объектов, поэтому репозиторий и был рождён на свет. Но что сейчас даёт нам репозиторий? Когда я задаю этот вопрос, то чаще всего слышу эпический  ответ::реализацию репозитория легко заменить другой реализацией. Хотя один раз удалось услышать честный ответ: по привычке.

  Звучит красиво, и очень привлекательно для апологетов абстракционизма. Даже если не рассматривать реальное положение вещей, когда 99% проектов никода не меняют базу данных и метод доступа к ней, а обобщить немного теории становится понятно – утверждение о лёгкой замене реализации репозитория невозможно в принципе. Каждый раз мы строим репозиторий в оглядке на конкретный слой доступа к данным. Наш код может не знать о конкретной реализации, но всегда полагается на неё. Для примера. NHibernate LINQ не поддерживает left join через DefaultIfEmpty, а EF – поддерживает. Кто-нибудь может мне сказать, как легко (строчкой в конфигурации DI-контейнера) заменить EF на NHibernate в таком случае?

  Мы не можем положиться на абстракцию репозитория. Суровая правда жизни в том, что доступ к данным чрезвычайно сложен по своей природе. Мы по-прежнему должны решать когда, сколько и какие данные вытащить из базы, когда их можно положить в базу, управлять транзакциями и т.д.  Если мы считаем репозиторий коллекцией объектов в памяти, то как мы можем игнорировать обрыв соединения, взаимоблокировки и БД, задержки сети? Ответ шире самого вопроса, и проистекает из закона дырявых абстракций:

Все нетривильные абстракции в некоторой степени дырявы.

  В истинности я убедился на собственном горьком опыте. Несмотря на суровую правду жизни, попытки найти серебряную пулю продолжаются, Новую эру среди них открыл LINQ, и почтенный интерфейс IQueryable<T>, с аналогичным  результатом

Как жить дальше?

  Так, если мы не можем полагаться на абстракции, то стоит ли вообще от них отказаться? И да и нет. Во-первых, надо отказаться от рассмотрения слоя доступа к данным как абстракции. Смотрите на него как на API, и оценивайте с точки зрения удобства использования. Если доступ к данным осуществляется на голом ADO.NET – спрятать мелкие детали доступа к данным за неким самописным API. Но если у вас в руках уже хороший иструмент, вроде NHibernate или EF – репозиторий вам не нужен (и даже вреден). API хорошего фреймворка доступа к данным остаётся честным с вами, не пытаясь спрятать тех процессов, которые происходят под ним, но существенно ускоряет разработку.

  Напоследок могу посоветовать пару сообщений в тему от Ayende, и закон дырявых абстракций на языке Пушкина.

Комментариев нет:

Отправить комментарий