Как правильно построить n-layer архитектуру приложения ASP.NET MVC?
Функциональные требования:
Приложение должно состоять из следующих подсистем:
1.Ежедневник.
2.Список контактов.
Как правильно выстроить архитектуру? На ум приходит, что должен быть 1 Pl(проект), раздробить бизнес-логику на 2 части(2 проекта), и 1 DAL.
Обычно выделяют по отдельному проекту на слой: DAL (с репозиториями), BL (с сущностными моделями) и UI (с composition root и, собственно, UI). Все в разные проекты одного солюшена. В базе это две таблички со связью many-to-many (события и относящиеся к ним люди).
Но все зависит от задачи, конечно. Можно можно под каждую подсистему сделать микросервис, а можно и просто по разным папкам в едином проекте разложить.
Толстый Лорри, это понятно, просто словом "подсистема", в тестовом задании, я думал проверяющий хотел подчеркнуть, что они не должны зависеть друг от друга, чтобы можно было одну систему "выдернуть", а оставшаяся работала.
Иван Мурашкин, слово "подсистема" может означать составную часть в любом виде, фокус лишь на том, что это должна быть "черная коробочка", т.е. соответствовать принципу S-SOLID. Если вы "выдерните" из автомобиля переднюю подвеску, то задняя вряд ли пострадает, хоть автомобиль и не поедет. Зато никто не помешает вместо банального мак-ферсона поставить многорычажку и не перетестировать работу прикуривателя (образно говоря).
В отдельный слой следует выделять только то, что подвержено изменениям при поддержке, либо будет использоваться как компонент еще где-то. Стандартно это ui/web, dal, business-logic. Иногда в отдельный слой выносят модели, т.к. они могут использоваться как промежуток между разными слоями, особенно если это dto модели.
Простой
