заключается в том как прописать зависимости в Solution?
Есть 4 проекта:
1. Front-end
2. API
3. Business Logic
4. Data Acess Layer
Насколько правильно это будет
Для Fron-End в зависимостях ток API ( или вообще нет зависимости у него )
У API зависимость FE BL
У BL зависимость API DL
У DL ток BL
Если BL зависит от DL, а DL зависит от BL, то что получится?
что
Но dl не должен от bl зависеть
Ок, тогда BL от DL А DL просто как база данных
Те же вопросы выше, у тебя там тоже циклические зависимости
Тоесть если в одном прописываю зависимость то нет смысла писать в другом И получаю Front как Front API от FE и BL И BL от DL DL как база данных
Не "нет смысла", а "не работает"
Ок И получаю Front как Front API от FE и BL И BL от DL DL как база данных
Если ты хочешь делать фронт отдельно от бэка, то почему у тебя у API зависимость от фронта?
Лучше чтоб dl от bl
Спасибо
Чтоб отправлять запросы через API на back
А можно узнать почему такое решение лучше ?
Чтоб бл ничего не знала про бд, а отвечала только бизнесовым требованиям и ограничениям
И чтобы dl знал про бизнес требования? Раз у тебя dl зависит от bl
А в bl я передаю как экземпляр модельки какой-то а не саму модельку
Нет, dl реализует интерфейсы которые лежат в bl,
Никак напрямую, через di
А как в DI попадет реализация из DL?
Регает какой нибудь composition root
Посмотрите примеры луковой архитектуры)
Что такое DI 😁
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-7.0
Контейнер зависимостей наверн
Ну почитайте же теорию
Например web проект
Получается WEB проект референсит DL и BL, а DL референсит BL. И это якобы с твоих слов общепринятая теория (поправил опечатки только что)
Я выше написал про composition root. Web - как вариант да, так делают. И я утверждаю что это луговая архитектура
Обсуждают сегодня