Трехуровневое приложение
В одноуровневом приложении, то есть Mvc, вы получаете папку с именем models и создаете и храните там свои классы, я знаю, что когда речь идет о трехуровневом приложении, из того, что я прочитал, кажется правильным хранить модели внутри бизнес-уровень (2-й уровень), а из пользовательского интерфейса (первый уровень) я бы добавил ссылку на проект на 2-й уровень, что позволит мне использовать модели и выполнять вызовы методов.
С точки зрения второго уровня он будет вызывать уровень данных (третий уровень) и выполнять грубые операции с базой данных, но для уровня данных потребуются модели из бизнес-уровня, поэтому при попытке добавить ссылку на проект из уровня данных в бизнес-уровень я понял ошибку
Ссылка на "Бизнес-уровень" не может быть добавлена, добавление этого проекта в качестве ссылки вызовет циклическую зависимость
Как я понимаю, ссылка уже сделана через бизнес-уровень на уровень данных
Как бы мне обойти это? создать дополнительные модели на уровне данных и заполнить их результатами из базы данных и передать их обратно на бизнес-уровень, который затем передает их обратно в пользовательский интерфейс? Я немного запутался в этом.
** Обновить **
От того, что я прочитал для уровня данных до эталонных моделей внутри бизнес-уровня, мне нужно было бы выполнить сопоставление моделей. Мое сопоставление моделей будет довольно большим, поэтому я думаю о включении 4-го уровня, который будет общей библиотекой, и это будет состоят из всех моделей, которые обеспечивают доступ к моделям уровня данных и бизнес-уровня по мере необходимости.
2 ответа
Немного не по теме, но...
В зависимости от размера вашего приложения может не быть причин вводить ненужные сложности, чтобы попытаться следовать шаблону, который вы не обязательно понимаете. Это вызовет у вас дополнительную головную боль.
При этом, если ваш проект имеет большой размер и требует хорошей организации, я настоятельно рекомендую провести дополнительные исследования и, возможно, несколько примеров проектов, в которых вы попробуете архитектуру, которую придумали. Ни в коем случае вы не поймете это правильно с первого раза.
Я бы лично предложил рассмотреть "луковую архитектуру" вместо "n-ярусного", и, конечно, вы найдете много разных взглядов на нее. Вам придется принимать свои собственные решения.
Вот общая настройка, с которой я бы начал.
Ядро Он не знает ни о каком другом проекте. Это где ваши занятия с вашим "бизнесом" идут. Такие как клиент, продукт, заказ и т. Д.
Данные. Он знает о ядре. Он отвечает за получение основного объекта и его хранение где-либо. Это все.
Сервис Он знает о ядре и данных. Его задача - раскрыть такие методы, как "Создать клиента", он будет отвечать за создание клиента и его хранение.
Web / Api / Mvc. Это будет знать о Сервисе. Его задача - показать ваш сервис пользователю. (Пользовательский интерфейс и тому подобное). (Он также может знать о Core / Data ... но это более широкое обсуждение.)
Вы на правильном пути, но мне проще представить уровень модели как данные (третий уровень), а контроллер (бизнес-уровень, второй уровень) управляет потоком данных между пользовательским интерфейсом (первый уровень) и слой данных.
Если вы измените свою архитектуру таким образом, вы должны избавиться от циклических ссылок.
Это также позволяет сопоставить объекты уровня данных с соответствующими менее / более сложными структурами среднего уровня таким образом, чтобы упростить интерфейс, отображаемый для пользовательского интерфейса, и инкапсулировать там также бизнес-логику.