"Andrew Stewart" <An***********@discussions.microsoft.comwrote in message
news:F0**********************************@microsof t.com...
>
I'm involved in upgrading an existing project that is made up of multi
functional units. For communication between each unit (RFI checking on
deletion and data retrieval) in the past a single communication module had
been compiled that referenced each functional unit. The communication
module
then was reference by each functional unit. The communication module
exposed
a very loose interface. E.g. if you wanted an address and you were in
another module, you would call the communication module and ask for an
address, it would look at the address module and handle UI and BO
interaction
as required.
I have a couple of issues with this approach.
1. Circular referencing A references B, B references A. Building the
solution takes 2 parses etc.
2. The loose interface defined in the communication module meant developer
struggled to know what to pass through. Arguments were being passed in as
datarow's in a datatable, and could only really be understood by looking
the
functional units handling of the communication modules call.
I have been looking at different options, but I keep coming back to a
Circular reference.
Is there a better pattern or approach? The circular reference works it
just
difficult to maintain and develop with. Also have an issue with when a
new
functional unit is created that the customer may not be purchasing,
because
the communication module requires a reference, it would be distributed
even
than it would never be used. Late binding with defined interfaces would
get
around this.
An comments or ideas?
You don't specify whether communication between the units is some form of
RPC, or whether you just mean cross-assembly calls. If the latter, then two
advices I can give to avoid overly tight coupling, and explicit circular
references, is to extract all interfaces used for cross-assembly calls into
separate assemblies (so that code that needs to call another assembly only
references the interface assembly for it, not the actual implementation),
and use an inversion of control / dependency injection container such as
Unity or Castle Windsor to bind your assemblies together at run-time.
Something along these lines:
// IFoo.dll
interface IFoo
{
void DoFoo();
}
// Foo.dll
// refs: IFoo.dll, IBar.dll
class Foo : IFoo
{
[Dependency] private IBar Bar;
void DoFoo() { Bar.DoBar(); }
}
// IBar.dll
interface IBar
{
void DoBar();
}
// Bar.dll
// refs: IFoo.dll, IBar.dll
class Bar : IBar
{
[Dependency] private IFoo Foo;
void DoBar() { Foo.DoFoo(); }
}
<!-- app.config -->
...
<type type="IFoo, IFoo" mapTo="Foo, Foo" />
<type type="IBar, IFoo" mapTo="Bar, Bar" />
