views:

127

answers:

1

My question isn't so much about use of interfaces but more of a project organization nature.

Note: I am using VisualStudio in a multi-layered application.

Should my Interface files live in a separate project from their implementations? My initial thought is that it would be useful to separate out all my service interfaces into their own project (and a project for my initial implementations) so that down the road the implementation/concrete project may be removed and replaced with a new one if necessary.

To clarify with an example: Suppose I have a business layer Interface called IBusinessService which lives in the MyApp.Business.Services namespace. My implementation FooBusinessService would exist in the same namespace, but a different project in VisualStudio. If later on the implementation needed to be reworked, a developer could remove the reference to the FooService.proj and replace it with a reference to BarService.proj.

This seems like it would declutter the app solution by allowing you to reference a project with only interfaces without also acquiring concrete implementations (which may be obsolete or of no use to you), but am I missing something?

A: 

I'm with you. I prefer to put my interfaces in a separate project AND in a different namespace. The classic example is with data access classes. You want to be able to code an MSSQL version and a MySQL version, both implementing the same interface. As such, I prefer that the interface definition be in a separate assembly/project. Here's an example of how I lay out assemblies and namespaces:

  • Elder.DataAccess.Core - contains the interfaces and common utilities
  • Elder.DataAccess.MSSQL - specific MSSQL implementations of the interfaces
  • Elder.DataAccess.MySQL - specific MySQL implementations of the interfaces

This allows me to modify the implementations without touching the project that contains the interface definitions. This helps me with version control and change tracking, too. There might be other ways to skin this cat, so I'll be eager to see other folks' answers.

Scott Fletcher
Thanks Scott. This is the structure I am using now, I just wanted some confirmation that it made sense and that I wasn't missing something. Unless someone else points out a flaw - I'll go with this for my interfaces.
Ben Elder