Steven Bey

@sohape my use of the phrase 'tightly coupled' may have been slightly erroneous but what I meant was that, even if you don't use the concrete class (e.g. when mocking/stubbing the interface for your tests), it's always 'there' (in the library). I know this is a little OCD but, like I said, that's just me.

I completely agree with you concerning interfaces in their own project. I've seen so many examples of it and it drives me crazy (to the point of frothing at the mouth ;).

I structure solutions with a 'base' project and then implementation projects. The 'base' project contains all of the entities that are used in the application and has a folder structure that reflects the application's architecture. It also contains the interfaces for the application. For example:

Data/
IRepository
IUserRepository
Commands/
ICommand
IUserCommand
Services/
IService
IUserService
IFileBundleService
IFileReaderService

Then, I name the implementation projects to follow the folder structure (e.g *.Services or *.Commands) or, where appropriate, with the technology that they're using (e.g. *.Data.SqlClient).

Of course, YMMV =)

@vincpa I understand the reason but thanks.

I never understand tightly coupling interfaces with concrete implementations in the same project, so I'd say bad practice, but that's just me. :)