Считается ли хорошей практикой писать интерфейсы на более высоком уровне?

Я подумал, что было бы лучше написать на уровне приложения (бизнес) интерфейсы единицы работы и их реализации на уровне персистентности (DAL). Цель состоит в том, чтобы слои были максимально разделены.

Представьте себе сценарий, в котором вы решили изменить DAL с ядра EF на Dapper. Как этот переход был бы менее болезненным? Разве не лучше иметь интерфейсы, объявляющие, что мне нужен этот запрос, и это, и то, чтобы работать в моем бизнесе и сопоставить его с новым уровнем доступа к данным?


person Panos Skiadas    schedule 11.08.2020    source источник
comment
Да, вы должны объявить интерфейсы на уровне, который не должен зависеть от инфраструктуры (т. Е. От бизнес-уровня). Вы определяете контракт через интерфейс, и компоненты нижнего уровня должны реализовывать эти интерфейсы. Благодаря этому вы можете убедиться, что на вашем бизнес-уровне у вас есть зависимости только от того, что также хорошо определено на этом уровне. Например, у вас есть интерфейс репозитория, определенный на уровне бизнеса (домена), а реализация этого интерфейса определяется на уровне сохраняемости.   -  person afh    schedule 11.08.2020


Ответы (1)


Ваши мысли верны, они сосредоточат вашу бизнес-логику и превратят технические детали в плагины для вашей бизнес-логики.

См. Также «Чистую архитектуру» Роберта К. Мартина для более глубоких размышлений в том же направлении.

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

person plainionist    schedule 14.08.2020
comment
Если вы еще не видели, советую вам посмотреть и это видео youtube.com/watch?v= Nsjsiz2A9mg - person L.Petrosyan; 14.08.2020
comment
Меня вдохновляет именно то, что вы предлагали с самого начала. Большое тебе спасибо! - person Panos Skiadas; 16.08.2020