Ole said:
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.