Репозиторий через ADO на ASP.NET

Здравствуйте. Подскажите пожалуйста. Реализую репозиторий доступа к бд через адо, без использования ЕФ.
В самом асп проекте использую Онион архитектуру. так вот встал вопрос как на нижележащем уровнем подключиться к бд, ведь все для подключения, включая веб конфиг находится на самом верху. Буду очень благодарен за любые наводки. А то в гугле, по всей видимости, все только ЕФ используют...

0

privetprivet, какая разница, EF или голый ADO.NET? Смысл архитектурного подхода вообще никак не меняется. EF тоже строку подключения требует.

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

На том же верхнем уровне находится и реализация этих репозиториев. А в "центре" только интерфейсы репозиториями реализуемые. Так что никаких противоречий тут нет.

0

Сообщение от Usaga На том же верхнем уровне находится и реализация этих репозиториев. А в "центре" только интерфейсы репозиториями реализуемые. Так что никаких противоречий тут нет.

То что я смотрю, как организуют это с ЕФ, то репозиторий реализуют гораздо ниже верхнего уровня. по крайней мере в этой архитектуре

Добавлено через 4 минуты

Сообщение от Usaga какая разница, EF или голый ADO.NET? Смысл архитектурного подхода вообще никак не меняется. EF тоже строку подключения требует.

Может вы сможете подсказать как в этом примере еф заменить на голый адо? https://metanit.com/sharp/mvc5/23.1.php
заранее благодарю.
или хотя бы хоть какие то наводки дать.

Добавлено через 1 час 21 минуту
Просто если я начну реализовывать доступ к бд на самом верху, тогда придется и логику всю туда запихивать, если я правильно понимаю

0

Сообщение от privetprivet То что я смотрю, как организуют это с ЕФ, то репозиторий реализуют гораздо ниже верхнего уровня. по крайней мере в этой архитектуре

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

Сообщение от privetprivet Просто если я начну реализовывать доступ к бд на самом верху, тогда придется и логику всю туда запихивать, если я правильно понимаю

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

Сообщение от privetprivet Может вы сможете подсказать как в этом примере еф заменить на голый адо

Вопрос крайне странный. Серьёзно. В примере по ссылке есть интерфейс IBookRepository, который совершенно никаких ограничений не накладывает на свою реализацию. Т.е. вы его как угодно можете реализовать. Если умеете работать с ADO.NET, то уже умеете и заменить EF в реализации интерфейса.

Единственное, что в в том примере не канонично - автор разместил модельку Book в ядре и её же добавил в контекст EF'а. И вот это не правильно, ибо EF будет диктовать то, как эта моделька (и последующие) должна выглядеть. Эта моделька неизбежно будет отражать представление данных в таблицах в СУБД. В небольших приложениях, где луковая архитектура вообще имеет смысл, это не смертельно. Но в более крупных начнутся конфликты между тем, что нужно EF'у и тем, что хотело бы видеть "ядро" приложения.

Корректнее было бы разместить модели EF'а на том же внешнем уровне и мапить (проецировать) на модели из бизнес-логики. В случае использования голого ADO.NET (может быть в купе с Dapper.NET) каких-то требований к наличию структур хранения (модели EF'а) нет. Поэтому отдельные модели в инфраструктурном слое работы с СУБД не требуются (но могут заводиться по необходимости). Вот и вся разница.

1