Interface best practices [closed]

Question

I'm working on an application that is split in the following way (simplified a bit)

App
|
Framework
|
Data (Persistance)
|
Data.Couchbase

Inside App we're setting up the DI container and registering which concrete implementations will be used when a particular interface is needed.

I.e. IUserRepository in the Data namespace will be fulfilled by CouchbaseUserRepository in the Data.Couchbase namespace. In the future if we swap out the persistance layer with another technology, say Mongo, we could update the DI registration and it would be fulfilled by say MongoUserRepository

All well and good....

Question 1

There is an obvious benefit to providing interfaces that cross system boundaries but whatabout within the Data.Couchbase namespace itself. Is there any point in having an ICouchbaseUserRepository interface if it doesn't provide any extra functionality itself? It seems as though if we register IUserRepository -> CouchbaseUserRepository that should be good enough? Similary within concrete implementations is there any point in splitting those components up further into interfaces that probably wont be swapped out

Question 2

Similarly is it worth having a bunch of interfaces in Framework whos only purpose is to proxy on to interfaces in Data, therefore App can have a dependency only on Framework and not have to also depend on Data. I can see the advantage.... actually maybe I can't..... it seems like we're going to have hundreds of interfaces in the framework whereby we could just have a dependency on 'Data' especially if these assemblies are going to live on the same tin

Cheers

Answer 1

Answer 1

CouchbaseUserRepository implementing IUserRepository makes great sense. All of your application logic uses only the interface, so that if you later switch to Mongo you only have to make your MongoUserRepository implement the same interface.

Answer 2

If you're building a large application, definitely go with two layers of interfaces: db level, and framework level. If it's not so big, it might be too much. In either case it would not be incorrect to create interfaces at your framework level as well.