Внедрение зависимостей и разделение программных слоев

Question

Я пытаюсь внедрить Dependency Injection, чтобы мой тестер приложений был дружественным. У меня есть довольно основные сомнения.

Уровень данных использует объект SqlConnection для подключения к базе данных сервера SQL. Объект SqlConnection является зависимостью для уровня доступа к данным. В соответствии с законами внедрения зависимостей, мы не должны создавать новые () зависимые объекты, а должны принимать их через аргументы конструктора. Не желая расстраивать богов DI, я покорно создаю конструктор в моем DAL, который принимает SqlConnection.

Бизнес уровень называет DAL. Следовательно, бизнес-уровень должен перейти в SqlConnection. Уровень представления называется бизнес-уровнем. Следовательно, он тоже должен перейти в SqlConnection на бизнес-уровень.

Это отлично подходит для изоляции класса и тестируемости. Но разве мы не просто связали пользовательский интерфейс и бизнес-уровни с конкретной реализацией уровня данных, которая использует реляционную базу данных?

Почему уровни презентаций и бизнеса должны знать, что основным хранилищем данных является SQL? Что, если приложению необходимо поддерживать несколько источников данных, отличных от SQL-сервера (например, файлы XML, файлы с разделителями-запятыми и т. Д.) Кроме того, что делать, если я добавлю другой объект, от которого зависит мой уровень данных (скажем, вторая база данных). Теперь мне нужно изменить верхние слои, чтобы передать этот новый объект.

Как я могу избежать этой карусели и пожинать все преимущества DI без боли?

Answer 1

Честно говоря, вам нужно создать общий интерфейс для доступа к вашим данным. Репозиторий, а затем создать Sql-реализацию этого интерфейса и не внедрять SqlConnection.

Таким образом, при тестировании вы просто заменяете Sql Implementation общего интерфейса на реализацию тестирования (макет) и все готово.

Я думаю, что вы слишком далеко зашли в DI. В случае реализации Sql вы, возможно, должны внедрить строку подключения, но не саму SqlConnection.