Question posted in 
I have two projects, say App and Data. Data has some methods in it which are used by the App project so that the App project doesn’t have to worry about any data access / database connections etc. I guess the nice things about this set up is that 1. Data has no dependency on App and 2. If the database was changed, say from MS SQL to Oracle, you wouldn’t have to change the App project at all – just develop a new Data project.
It seems like there should be an interface defined for all the methods used by the App project for data access. This way, someone can develop the App project without caring about the Data project, and difference Data projects can be plugged into the App project and as long as it implements the interface everything will work.
Why question is this: where should the interface live? If it lives in App, then Data now has a dependency on App. But if it lives in Data, it has to be copied to any new Data projects that might want to be plugged in.
I’ll give another example: suppose App is a online selling tool. You might want 2 instances of the same App project, one for eBay and one for Amazon. The eBay instance would have a Data project that did things with eBay, and the Amazon instance would have a different Data project. How can I structure the application so the same App component can be deployed to both instances? Is an interface the right thing to use?
2
Answers
Yes, interfaces are exactly the right thing to use and you would normally put them in separate files – often each interface in its own file – and then simply reference the file (or module or assembly, depending on platform) where the interface is declared when implementing a new object that supports said interface.
This scheme allows for separation of concerns, easier unit testing, mocking, and so on.
If you want to keep your dependencies isolated, the cleanest way to do this is to encode the interface in a distinct AppDataInterface project, on which both App and Data can depend.