3-х слойная архитектура. EF на уровне представления - PullRequest
0 голосов
/ 16 февраля 2020

Я пытаюсь создать приложение с 3-х уровневой архитектурой. Есть 2 библиотеки классов (доступ к данным, бизнес логи c) и asp. net MVC (презентация). Для подключения к БД я использую Entity Framework. В DataAccess я настроил DatabaseContext хранилище строк моего подключения в web.config. Если я пытаюсь добавить raw в базу данных из Presentation, я получаю сообщение об ошибке

Не найден поставщик Entity Framework для ADO. NET поставщик с неизменным именем System.Data.SqlClient. "

Насколько я понимаю, это плохая практика - установить EF на уровне презентации. Я думаю о добавлении ссылки System.Data.SqlClient, но думаю, что это тоже плохая практика. Возможно, кто-то сталкивался с подобной проблемой. Я буду благодарен за любую помощь .

1 Ответ

1 голос
/ 16 февраля 2020

Если вы придерживаетесь истинной трехуровневой архитектуры и используете интерфейсы и внедрение зависимостей между уровнями, то проблема, скорее всего, заключается в том, что Visual Studio не видит, что вы на самом деле используете уровень данных, и не развертывает зависимости , Я изучал эту проблему несколько лет назад, и решить ее немного больно. Я не совсем уверен, что это ваша проблема из-за минимальной информации, которую вы предоставили, но если это звучит как ваша проблема, вы можете проверить, добавив жесткую зависимость из Интернета в слой данных и посмотреть, что произойдет. Если это решит ошибку, то есть несколько способов исправить проблему.

Поскольку веб-проект также считается Композицией Root, он должен предоставить конфигурацию для уровня данных, такого как строка подключения , Таким образом, между сетью и слоями данных уже есть некоторые знания. Создание действительно отдельных слоев почти, если не невозможно.

Если добавление жесткой зависимости решает проблему, то вы можете создать метод stati c именно для этой цели и документировать метод, чтобы будущие разработчики не пытались и удали его. Другой - изменить файл решения, чтобы скопировать целевой DLL в папку bin. Это кажется лучшим решением, но я помню, что оно часто ломалось, и мне приходилось возвращаться назад и добавлять ручную запись обратно в решение, что приводило в замешательство, когда оно ломалось.

Я также обнаружил еще одно обсуждение стекового потока, которое охватывает эту же топику c:

Не найден поставщик Entity Framework для ADO. NET поставщик с инвариантным именем 'System.Data .SqlClient '

...