Изменения в архитектуре проекта, предлагается объединить слои UI, Application и Domain для упрощения доступа к данным уже через привычную и долгосрочно используемую базу данных MS SQL. В случае отказа от использования UnitOfWork и Repository из-за их избыточности при работе с EntityFramework, волнует возможное изменение названия слоя Application и в целом, целесообразность подобного подхода. Возможно ли такое решение и как оно классифицируется в общей системе архитектурных паттернов?
Предложенный подход к изменению архитектуры проекта путем объединения слоев UI, Application и Domain для доступа к данным через базу данных MS SQL может быть оценен как архитектурный шаблон или стиль, который подходит для конкретного проекта. Отказ от использования UnitOfWork и Repository в пользу работы с EntityFramework действительно может быть обоснованным в определенных ситуациях, однако важно помнить, что каждый проект уникален, и решения должны быть приниматься с учетом специфики задачи. Подобный подход можно классифицировать как комбинацию различных архитектурных паттернов, таких как MVC (Model-View-Controller), MVVM (Model-View-ViewModel) и Active Record. Объединение слоев UI, Application и Domain позволяет упростить доступ к данным и сделать архитектуру проекта более гибкой и расширяемой. Однако, прежде чем внедрять подобные изменения, рекомендуется провести дополнительный анализ и оценку существующей архитектуры проекта, чтобы убедиться в целесообразности и эффективности предлагаемого решения.
то уже нет смысла ни в UnitOfWork, ни в Repository. То есть можно избавиться от Infrastructure слоя, чтобы схема была уже такая: UI, Application, Domain.
Infrastructure слой нужен не для того чтобы заменять базу в будущем, а чтобы работа с базой не захламляла домен.
Да и "никогда переходить не планируется" - это достаточно громкое заявление.
Просто в случае с UnitOfWork и Repository накладывают только лишнюю нагрузку, потому что это и так реализовано в EntityFramework.
Тогда будет усложнено тестирование, так как ты не сможешь замокать EF.
Лучше всю работу по построению запроса тоже вынести куда-то в инфраструктурный слой - тогда и UoW и "Repository" не придётся тащить в домен.