Re: Best Practice: Interface definitions - where?

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Tim Jarvis (tjarvis_at_NoSpamForMe.com)
Date: 04/18/04 

Date: Sun, 18 Apr 2004 06:24:20 -0700

Ole Olsen wrote:

> Hi
>
> Any input on what is best practice:
> 1 ) Put an Interface definition (e.g. IMyInterface) into a separate
> Assembly 2 ) Put the Interface definirion into the same assembly that
> holds the concreate and implementing class?
>
> MS seems to like the first approach with 2 assemblies over the latter
> with just one assembly?
>
> What do you guys say?
> /Ole

Hi Ole,

I guess that it is somewhat usage dependant but IMO having interfaces
defined in a separate assembly gives you the most benefits. here are a
couple of main reasons for you .

1./ Remoting, if you create your remoting application using interfaces,
your client apps and server apps can share the same interface assembly,
thereby ensuring that you don't need to have access to implementation
details in the client.

2./ one of the strengths of interfaces is the fact that you can create
polymorphic behaviour accross classes without a common ancestor class.
this really implies that you should separate the interface definition
from the implementation.

Here is an example for you, if I was to create an oracle specific
ADO.NET provider, I need to support a number of ADO.NET interfaces, at
the moment the System.Data.dll assembly not only declares the
interfaces, but also some implementing classes (OLEDB classes for
example) this means that when I ship my assembly that contains my
Oracle provider, the interface assembly that I have to include contains
drivers for OLDDb, ODBC and SQL Server, none of which will be used in
my application. In this case it's not such a big deal as these classes
are included in the framework and installed into the GAC anyway, so I
don't have to deploy it to my end user, but you can see the implication
if this was an assembly that had to be deployed.

Hope this has been helpful.

Rgds Tim.

Relevant Pages

  • Re: Add-ons
    ... Using micro core(common interfaces) and mutiple concrete implementation is ... One thing I'm not sure is how will the 3rd party ... | Our web solution consists only of strongly-named assemblies. ... For strong-reference, it will ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Add-ons
    ... Mantas Miliukas ... > statically reference your core interfaces assembly and develop their own ... > | Our web solution consists only of strongly-named assemblies. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Add-ons
    ... You're welcome Mantas, ... Microsoft Online Support ... |> statically reference your core interfaces assembly and develop their own ... |> | Our web solution consists only of strongly-named assemblies. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: A tool to automatically generate metadata-only assemblies?
    ... changes to the code to use interfaces. ... added all the static members that the soapsuds tool didn't export. ... The client assemblies containing only the definitions of the classes ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: Best Practice: Interface definitions - where?
    ... > 1./ Remoting, if you create your remoting application using interfaces, ... > your client apps and server apps can share the same interface assembly, ... > Oracle provider, the interface assembly that I have to include contains ...
    (microsoft.public.dotnet.languages.csharp)