c# - Interface best practices -

i'm working on application split in following way (simplified bit)

app | framework | data (persistance) | data.couchbase 

inside app we're setting di container , registering concrete implementations used when particular interface needed.

i.e. iuserrepository in data namespace fulfilled couchbaseuserrepository in data.couchbase namespace. in future if swap out persistance layer technology, mongo, update di registration , fulfilled mongouserrepository

all , good....

question 1

there obvious benefit providing interfaces cross system boundaries whatabout within data.couchbase namespace itself. there point in having icouchbaseuserrepository interface if doesn't provide functionality itself? seems though if register iuserrepository -> couchbaseuserrepository should enough? similary within concrete implementations there point in splitting components further interfaces wont swapped out

question 2

similarly worth having bunch of interfaces in framework whos purpose proxy on interfaces in data, therefore app can have dependency on framework , not have depend on data. can see advantage.... maybe can't..... seems we're going have hundreds of interfaces in framework whereby have dependency on 'data' if these assemblies going live on same tin

cheers

answer 1

couchbaseuserrepository implementing iuserrepository makes great sense. of application logic uses interface, if later switch mongo have make mongouserrepository implement same interface.

answer 2

if you're building large application, go 2 layers of interfaces: db level, , framework level. if it's not big, might much. in either case not incorrect create interfaces @ framework level well.