Where do interfaces belong in a multitier application

tags:

architecture

views:

answers:

+3 Q:

Where do interfaces belong in a multitier application

So say you have a three tier application with the tiers UI, Services, and Repository for a simple application, let's say saving addresses.

If AddressService has an interface IAddressService, where does that interface belong? I know that "in the address service" may seem like an obvious answer, but if it's in the address service it would seem to defeat the point of having the interface such that any service library could be swapped in as long as it implemented IAddressService.

(specifically this is in a .net problem space, but it's probably more general so it's tagged architecture)

+1 A:

Put them in a separate assembly, like AddressService.Interfaces or AddressService.Contracts, that is shared by all three tiers.

oefe 2010-02-22 20:25:29

I tend to put them in the relevant assembly under a sub namespace / directory.

For example if I have a Customers Assembly then ICustomerRepository or ICustomerAddressRepository etc would go under

..Customers.Interfaces.ICustomerRepository

Aim Kai 2010-02-22 21:00:49

+3 A:

The address service assembly is the right place for it.

if it's in the address service it would seem to defeat the point of having the interface such that any service library could be swapped in as long as it implemented IAddressService

The point of the interface is to enable callers to swap in alternate implementations. Offering a concrete implementation (or multiple implementations, for that matter) doesn't interfere with that at all.

The only time I'd make an interface-only assembly is when I'm not providing any implementation.

Jeff Sternal 2010-02-22 21:21:57

Wouldn't that make (preemptive) creation of the interface superfluous for most single team projects, since you could delay creation of the interface until it was needed, or is the cost of implementation after the fact significantly higher than the find-replace that I'm seeing?

Russell Steen 2010-02-22 22:01:03

It depends what you mean by 'needing an interface'. (And it's not really a consequence of using a single assembly.) There are often good reasons to code to interfaces rather than concrete objects: see http://stackoverflow.com/questions/48605/why-do-most-java-system-architects-insist-on-first-coding-to-an-interface, http://stackoverflow.com/questions/1970806/coding-to-interfaces, and http://stackoverflow.com/questions/363295/does-the-code-to-interface-principle-apply-to-entity-classes, all of which provide solid information and cover a fairly good range of opinions about it.

Jeff Sternal 2010-02-22 22:46:06

Thank you, great followup

Russell Steen 2010-02-23 19:50:28

I use to put the service interfaces in an assembly and the implementation in another. I never needed it in .NET, but I do it anyway, I think it's a way to decouple the UI "or ahother API client) from service implementacion.

I needed this separation in a Java project, in which an applet had to invoke a web service; so, only the jar with the interfaces was sent to the browser. If the jar had also contained the implementation, it would have been a heavy applet.

bloparod 2010-03-21 16:04:41

ansaurus

tags:

views:

answers:

Where do interfaces belong in a multitier application

related questions