Есть ли такая архитектура?
Сейчас используется луковичная архитектура: UI, Application, Infrastructure, Domain слои.
Но, т.к. в дальнейшем изменяться схема доступа к данным не будет от слова совсем (используется MS SQL уже ни один десяток лет и уходить от него никуда не планируется вообще), то уже нет смысла ни в UnitOfWork, ни в Repository. То есть можно избавиться от Infrastructure слоя, чтобы схема была уже такая: UI, Application, Domain.
Но в данном случае слой Application уже не будет так называться? Да и вообще, нормальная ли это практика? Просто в случае с UnitOfWork и Repository накладывают только лишнюю нагрузку, потому что это и так реализовано в EntityFramework.
Похожих примером в гугле на нашел, либо всё делают в 1 проекте, либо уже по луковичной с выделением отдельного слоя доступа к БД.
Есть ли вообще такая архитектура? Если да, то как она называется?
Ответы (1 шт):
Не нужно быть заложником шаблонных решений. Подберите наиболее подходящий для вашей задачи шаблон решения и смело меняйте его в соответствии с вашими целями: вы хотите достичь большей производительности, или вы хотите сделать ваш проект основой для других проектов, или ожидаете существенных изменений в самом проекте.
Технологический прогресс очень сильно влияет на программные решения: увеличение производительности вычислительных систем, увеличение ОЗУ, долговременной памяти, появление глобальной сети Интернета, увеличение скорости Интернета, увеличение покрытия Интернета, появление мобильных устройств – всё это существенно меняло программные архитектуры.
На данный момент никаких технологических прорывов нет (кроме псевдо-ИИ), так что опирайтесь на существующие архитектуры.