@OwDafuq

Есть ли такая архитектура?

Сейчас используется луковичная архитектура: UI, Application, Infrastructure, Domain слои.

Но, т.к. в дальнейшем изменяться схема доступа к данным не будет от слова совсем (используется MS SQL уже ни один десяток лет и уходить от него никуда не планируется вообще), то уже нет смысла ни в UnitOfWork, ни в Repository. То есть можно избавиться от Infrastructure слоя, чтобы схема была уже такая: UI, Application, Domain.

Но в данном случае слой Application уже не будет так называться? Да и вообще, нормальная ли это практика? Просто в случае с UnitOfWork и Repository накладывают только лишнюю нагрузку, потому что это и так реализовано в EntityFramework.

Похожих примером в гугле на нашел, либо всё делают в 1 проекте, либо уже по луковичной с выделением отдельного слоя доступа к БД.

Есть ли вообще такая архитектура? Если да, то как она называется?
  • Вопрос задан
  • 211 просмотров
Решения вопроса 1
то уже нет смысла ни в UnitOfWork, ни в Repository. То есть можно избавиться от Infrastructure слоя, чтобы схема была уже такая: UI, Application, Domain.

Infrastructure слой нужен не для того чтобы заменять базу в будущем, а чтобы работа с базой не захламляла домен.
Да и "никогда переходить не планируется" - это достаточно громкое заявление.

Просто в случае с UnitOfWork и Repository накладывают только лишнюю нагрузку, потому что это и так реализовано в EntityFramework.

Тогда будет усложнено тестирование, так как ты не сможешь замокать EF.
Лучше всю работу по построению запроса тоже вынести куда-то в инфраструктурный слой - тогда и UoW и "Repository" не придётся тащить в домен.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@mvv-rus
Настоящий админ AD и ненастоящий программист
Есть несколько соображений.
Сображение первое, глубоко теоретическое. Логическая структура конкретного приложения - это вопрос специфичный именно для приложения. Думать о ней в терминах соответствия некой теоретической "архитектуре" (тем более - "чистой архитектуре") - это самоограничение, достойное только зеленых новичков. Настоящие программисты не используют чистую архитектуру. Кароче, как вы приложение напишете, такая у него архитектура и будет. Возможно, если ваше приложение будет в чем-то замечательным, то эта архитектура войдет в учебники по этой самой архитектуре, в качестве примера (может - положительного, но, скорее, отрицательного ;-) ). Но пока что вам нужно решать практические вопросы, и шаблоны т.н. "архитектуры" могут служить только в качестве подсказки, а решать придется вам, из чисто практических соображений.

Соображение второе, практическое. Раз, как вы пишете "Domain содержит только сущности, Enum'ы", то выбросьте из головы слово Domain, оно вас только запутывает. Потому что намекает на DDD, а то, что у вас есть, в DDD обзывают "анемичной моделью", и сильно не любят. Т.е. сейчас, с нынешней структурой приложения, DDD - оно не про вас.

Так что, по факту, у вас есть два слоя абстракций, описывающих функции классов и методов: UI и Application. И я подозреваю, что логика приложения - классы и методы, отнесенные к Application - использует в качестве средства доступа к БД EF напрямую. То есть - что там прямо в коде используются сущности под названием DbContext и DbSet.

А это означает, если по жизни, что от EF вы в таком раскладе никуда впоследствии не денетесь. Хорошо это или плохо - решать вам. Однако о намерении прибить гвоздями свое приложение к EF вы не упоминали и, предполагаю, не думали. Если это так, то задумайтесь именно об этом. Не о замене БД - EF может работать поверх разных БД, так что к MS SQL вы, по факту, с EF привязаны не будете (ну, разве что, сами того очень захотите).

А задуматься надо: EF - штука неоднозначная. Она, подобно любому средству ORM, полна абстракций, которые, так скажем, не совсем хорошо ложатся на логическую структуру реляционных БД, а потому в них есть заметные дыры, через которые эта структура будет проглядывать. В частности, это нередко касается вопросов производительности.

Но если вы выберети жизнь EF и ни с чем другим, то о Repository и UoW можете больше не думать: EF будет для вас и тем, и другим.

Кароче, выбирайте.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы