What do People do to avoid Tight Coupling?

Take a solution with a project hierarchy along the lines of an n-tier
system, so that we have a data layer, business layer and presentation layer.
The presentation layer is coupled to the business layer, and the business
layer is coupled to the data layer. So far so good.

Suppose the data layer raises an event, and it passes Me (the sender) as an
object, and e (MyEventArgs, a descendent of EventArgs) to the layer above
(the business layer). Suppose also that the business layer needs to pass
this event on to the presentation layer. It sends Me as an object, but what
does it send e as? It can't send it as MyEventArgs because the presentation
layer knows nothing of such things. We could couple the presentation layer
to the data layer, so that it knows what a MyEventArgs is, but surely that
is a no-no.

We could also remove the definition of MyEventArgs to another project to
which everything is coupled, but now this common project is in danger of
being an eclectic mix of stuff that is really specific to individual
projects.

We could define a business layer version of MyEventArgs - which is actually
identical to the one in the data layer - and copy each element to the new
object before passing it on, but that is a lot of typing, and now we have
duplication.

I am interested to hear what other people do in this situation.

Charles

Charles,

Rather then talking in the abstract what specifically does the presentation
layer need to react to in conjunction with the data layer?

Dan

"Charles Law" <blank@nowhere.com> wrote in message
news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...[color=blue]
> Take a solution with a project hierarchy along the lines of an n-tier
> system, so that we have a data layer, business layer and presentation[/color]
layer.[color=blue]
> The presentation layer is coupled to the business layer, and the business
> layer is coupled to the data layer. So far so good.
>
> Suppose the data layer raises an event, and it passes Me (the sender) as[/color]
an[color=blue]
> object, and e (MyEventArgs, a descendent of EventArgs) to the layer above
> (the business layer). Suppose also that the business layer needs to pass
> this event on to the presentation layer. It sends Me as an object, but[/color]
what[color=blue]
> does it send e as? It can't send it as MyEventArgs because the[/color]
presentation[color=blue]
> layer knows nothing of such things. We could couple the presentation layer
> to the data layer, so that it knows what a MyEventArgs is, but surely that
> is a no-no.
>
> We could also remove the definition of MyEventArgs to another project to
> which everything is coupled, but now this common project is in danger of
> being an eclectic mix of stuff that is really specific to individual
> projects.
>
> We could define a business layer version of MyEventArgs - which is[/color]
actually[color=blue]
> identical to the one in the data layer - and copy each element to the new
> object before passing it on, but that is a lot of typing, and now we have
> duplication.
>
> I am interested to hear what other people do in this situation.
>
> Charles
>
>[/color]

> Suppose the data layer raises an event, and it passes Me (the sender) as
an[color=blue]
> object, and e (MyEventArgs, a descendent of EventArgs) to the layer above
> (the business layer).[/color]

Perhaps you should stop there. Rather than passing an object (or more
specifically itself) back to the business layer, why not pass either a
different object or just data to the business layer for it to consume?

Charles,[color=blue]
> The presentation layer is coupled to the business layer, and the business
> layer is coupled to the data layer. So far so good.[/color]
Actually I normally couple the presentation layer to the domain layer
(business layer) and couple the data layer to the domain layer!

See Martin Fowler's book "Patterns of Enterprise Application Architecture"
from Addison Wesley
http://www.martinfowler.com/books.html#eaa. The sections on Domain Model,
Data Mapper, and Separated Interface discuss how to have the data layer
reference the domain layer, instead of having the domain layer reference the
data layer. Having the data layer reference the domain layer, allows
replacing the data layer very easily! Also I find it provides better
separation (less coupling)...
[color=blue]
> Suppose the data layer raises an event, and it passes Me (the sender) as[/color]
an[color=blue]
> object, and e (MyEventArgs, a descendent of EventArgs) to the layer above[/color]
In one of my projects that data layer has custom event handlers
(MyEventArgs, a descendent of EventArgs), while the domain layer simply uses
EventHandler & passes EventArgs.Empty. As I found that the domain layer
needed to convey less information to the domain layer, then the data layer
did to the domain layer.
[color=blue]
> We could define a business layer version of MyEventArgs - which is[/color]
actually[color=blue]
> identical to the one in the data layer - and copy each element to the new
> object before passing it on, but that is a lot of typing, and now we have
> duplication.[/color]
I suspect most of the time the info that the domain layer needs in its
events is going to be different then the info needed in the data layer's
events, so each would have its own event handlers...

Hope this helps
Jay

"Charles Law" <blank@nowhere.com> wrote in message
news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...[color=blue]
> Take a solution with a project hierarchy along the lines of an n-tier
> system, so that we have a data layer, business layer and presentation[/color]
layer.[color=blue]
> The presentation layer is coupled to the business layer, and the business
> layer is coupled to the data layer. So far so good.
>
> Suppose the data layer raises an event, and it passes Me (the sender) as[/color]
an[color=blue]
> object, and e (MyEventArgs, a descendent of EventArgs) to the layer above
> (the business layer). Suppose also that the business layer needs to pass
> this event on to the presentation layer. It sends Me as an object, but[/color]
what[color=blue]
> does it send e as? It can't send it as MyEventArgs because the[/color]
presentation[color=blue]
> layer knows nothing of such things. We could couple the presentation layer
> to the data layer, so that it knows what a MyEventArgs is, but surely that
> is a no-no.
>
> We could also remove the definition of MyEventArgs to another project to
> which everything is coupled, but now this common project is in danger of
> being an eclectic mix of stuff that is really specific to individual
> projects.
>
> We could define a business layer version of MyEventArgs - which is[/color]
actually[color=blue]
> identical to the one in the data layer - and copy each element to the new
> object before passing it on, but that is a lot of typing, and now we have
> duplication.
>
> I am interested to hear what other people do in this situation.
>
> Charles
>
>[/color]

Hi Scott

I used the (sender As Object, e As MyEventArgs) style to follow the pattern
proposed by Microsoft. MyEventArgs has properties that give access to the
data that it is to be consumed.

The situation I am describing is when that data needs to be passed on to the
layer above. The straight forward way seemed to be just to bubble the event,
but then the layer above needs to know what a MyEventArgs class looks like.

Charles

"Scott M." <s-mar@nospam.nospam> wrote in message
news:ObHO$rKSEHA.732@TK2MSFTNGP09.phx.gbl...[color=blue][color=green]
> > Suppose the data layer raises an event, and it passes Me (the sender) as[/color]
> an[color=green]
> > object, and e (MyEventArgs, a descendent of EventArgs) to the layer[/color][/color]
above[color=blue][color=green]
> > (the business layer).[/color]
>
> Perhaps you should stop there. Rather than passing an object (or more
> specifically itself) back to the business layer, why not pass either a
> different object or just data to the business layer for it to consume?
>
>[/color]

Hi Dan

I used the 3-tier example because it is a particularly familiar one. My
scenario has a presentation layer on top of a command layer, on top of a
communications layer, but with other bits on the side. It's a bit hard to
describe really.

The presentation layer has view windows containing indicator controls. These
controls are held in a library project. The presentation layer is
responsible for instantiating these controls in a view window.

The command layer gets data back from the comms layer and raises events
based on the information. These events are handled by the indicators, which,
whilst being instantiated at the presentation layer are contained in the
library, so that is where the events are handled. What this means is that
the library is coupled to both the presentation layer and the command layer,
and the presentation layer is coupled to the command layer. This doesn't
quite create a circular reference, but it does cause the .NET IDE/compiler
immense problems when building.

So, my reason for asking the question has other implications in that if I
can reduce the coupling I will actually be solving my build problems.

Charles

"solex" <solex@nowhere.com> wrote in message
news:eq3sAnKSEHA.1312@TK2MSFTNGP12.phx.gbl...[color=blue]
> Charles,
>
> Rather then talking in the abstract what specifically does the[/color]
presentation[color=blue]
> layer need to react to in conjunction with the data layer?
>
> Dan
>
> "Charles Law" <blank@nowhere.com> wrote in message
> news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...[color=green]
> > Take a solution with a project hierarchy along the lines of an n-tier
> > system, so that we have a data layer, business layer and presentation[/color]
> layer.[color=green]
> > The presentation layer is coupled to the business layer, and the[/color][/color]
business[color=blue][color=green]
> > layer is coupled to the data layer. So far so good.
> >
> > Suppose the data layer raises an event, and it passes Me (the sender) as[/color]
> an[color=green]
> > object, and e (MyEventArgs, a descendent of EventArgs) to the layer[/color][/color]
above[color=blue][color=green]
> > (the business layer). Suppose also that the business layer needs to pass
> > this event on to the presentation layer. It sends Me as an object, but[/color]
> what[color=green]
> > does it send e as? It can't send it as MyEventArgs because the[/color]
> presentation[color=green]
> > layer knows nothing of such things. We could couple the presentation[/color][/color]
layer[color=blue][color=green]
> > to the data layer, so that it knows what a MyEventArgs is, but surely[/color][/color]
that[color=blue][color=green]
> > is a no-no.
> >
> > We could also remove the definition of MyEventArgs to another project to
> > which everything is coupled, but now this common project is in danger of
> > being an eclectic mix of stuff that is really specific to individual
> > projects.
> >
> > We could define a business layer version of MyEventArgs - which is[/color]
> actually[color=green]
> > identical to the one in the data layer - and copy each element to the[/color][/color]
new[color=blue][color=green]
> > object before passing it on, but that is a lot of typing, and now we[/color][/color]
have[color=blue][color=green]
> > duplication.
> >
> > I am interested to hear what other people do in this situation.
> >
> > Charles
> >
> >[/color]
>
>[/color]

Hi Jay
[color=blue]
> I suspect most of the time the info that the domain layer needs in its
> events is going to be different then the info needed in the data layer's
> events, so each would have its own event handlers...[/color]

I agree that this the case most of the time, it's just that in my case it
isn't. If I used different EventArgs classes I would just be changing the
object for the sake of it. No information is added or omitted as the event
passes up the layers.

As I described in my response to Dan, I have a set of custom controls that
raise and sink events. These are instantiated by the presentation layer, but
the command layer is where the corresponding events are sunk (sinked?) and
raised. I have ended up with tighter coupling than the compiler/IDE is
comfortable with, and I get random, erroneous build errors all the time. I
have seen others post about this problem, and it comes and goes for me. At
the moment it has come, and I can't build my solution because I get large
numbers of spurious messages about handlers and events having different
signatures, when they haven't. That's why I am trying to loosen the coupling
so that I can just build the thing.

Charles

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
news:eVqENGLSEHA.3140@tk2msftngp13.phx.gbl...[color=blue]
> Charles,[color=green]
> > The presentation layer is coupled to the business layer, and the[/color][/color]
business[color=blue][color=green]
> > layer is coupled to the data layer. So far so good.[/color]
> Actually I normally couple the presentation layer to the domain layer
> (business layer) and couple the data layer to the domain layer!
>
> See Martin Fowler's book "Patterns of Enterprise Application Architecture"
> from Addison Wesley
> http://www.martinfowler.com/books.html#eaa. The sections on Domain Model,
> Data Mapper, and Separated Interface discuss how to have the data layer
> reference the domain layer, instead of having the domain layer reference[/color]
the[color=blue]
> data layer. Having the data layer reference the domain layer, allows
> replacing the data layer very easily! Also I find it provides better
> separation (less coupling)...
>[color=green]
> > Suppose the data layer raises an event, and it passes Me (the sender) as[/color]
> an[color=green]
> > object, and e (MyEventArgs, a descendent of EventArgs) to the layer[/color][/color]
above[color=blue]
> In one of my projects that data layer has custom event handlers
> (MyEventArgs, a descendent of EventArgs), while the domain layer simply[/color]
uses[color=blue]
> EventHandler & passes EventArgs.Empty. As I found that the domain layer
> needed to convey less information to the domain layer, then the data layer
> did to the domain layer.
>[color=green]
> > We could define a business layer version of MyEventArgs - which is[/color]
> actually[color=green]
> > identical to the one in the data layer - and copy each element to the[/color][/color]
new[color=blue][color=green]
> > object before passing it on, but that is a lot of typing, and now we[/color][/color]
have[color=blue][color=green]
> > duplication.[/color]
> I suspect most of the time the info that the domain layer needs in its
> events is going to be different then the info needed in the data layer's
> events, so each would have its own event handlers...
>
> Hope this helps
> Jay
>
>
>
>
> "Charles Law" <blank@nowhere.com> wrote in message
> news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...[color=green]
> > Take a solution with a project hierarchy along the lines of an n-tier
> > system, so that we have a data layer, business layer and presentation[/color]
> layer.[color=green]
> > The presentation layer is coupled to the business layer, and the[/color][/color]
business[color=blue][color=green]
> > layer is coupled to the data layer. So far so good.
> >
> > Suppose the data layer raises an event, and it passes Me (the sender) as[/color]
> an[color=green]
> > object, and e (MyEventArgs, a descendent of EventArgs) to the layer[/color][/color]
above[color=blue][color=green]
> > (the business layer). Suppose also that the business layer needs to pass
> > this event on to the presentation layer. It sends Me as an object, but[/color]
> what[color=green]
> > does it send e as? It can't send it as MyEventArgs because the[/color]
> presentation[color=green]
> > layer knows nothing of such things. We could couple the presentation[/color][/color]
layer[color=blue][color=green]
> > to the data layer, so that it knows what a MyEventArgs is, but surely[/color][/color]
that[color=blue][color=green]
> > is a no-no.
> >
> > We could also remove the definition of MyEventArgs to another project to
> > which everything is coupled, but now this common project is in danger of
> > being an eclectic mix of stuff that is really specific to individual
> > projects.
> >
> > We could define a business layer version of MyEventArgs - which is[/color]
> actually[color=green]
> > identical to the one in the data layer - and copy each element to the[/color][/color]
new[color=blue][color=green]
> > object before passing it on, but that is a lot of typing, and now we[/color][/color]
have[color=blue][color=green]
> > duplication.
> >
> > I am interested to hear what other people do in this situation.
> >
> > Charles
> >
> >[/color]
>
>[/color]

Charles,

I do a simlar thing but without events and do not have a problem. It sounds
to me like you need to start defining some interfaces and remove the events.
Doing this should remove some of you coupling problems and perhaps increase
your performance.

Indicator control supports INotify interface

Your presentation layer instantiates
(1) the indicator control
(2) the command layer.
(3) initialzes the command layer with the already instantiated indicator
control(s) using the INotify interface

As the command layer as you say "gets data back from the comms layer"
instead of raising events it could loop through a set of registered objects
supporting the INotify interface and call an appropriate method.

In this pattern, the indicator control knows nothing about your presentation
layer, command layer or communication layer. The coupling looks something
like this (where -> means "knows" or "is coupled to")

Presentation -> Indicator
Presentation -> Command
Presentation -> INotify

Indicator -> INotify

Command -> INotify
Command -> Comms

Dan

"Charles Law" <blank@nowhere.com> wrote in message
news:%23sYfCTLSEHA.2216@TK2MSFTNGP12.phx.gbl...[color=blue]
> Hi Dan
>
> I used the 3-tier example because it is a particularly familiar one. My
> scenario has a presentation layer on top of a command layer, on top of a
> communications layer, but with other bits on the side. It's a bit hard to
> describe really.
>
> The presentation layer has view windows containing indicator controls.[/color]
These[color=blue]
> controls are held in a library project. The presentation layer is
> responsible for instantiating these controls in a view window.
>
> The command layer gets data back from the comms layer and raises events
> based on the information. These events are handled by the indicators,[/color]
which,[color=blue]
> whilst being instantiated at the presentation layer are contained in the
> library, so that is where the events are handled. What this means is that
> the library is coupled to both the presentation layer and the command[/color]
layer,[color=blue]
> and the presentation layer is coupled to the command layer. This doesn't
> quite create a circular reference, but it does cause the .NET IDE/compiler
> immense problems when building.
>
> So, my reason for asking the question has other implications in that if I
> can reduce the coupling I will actually be solving my build problems.
>
> Charles
>
>
> "solex" <solex@nowhere.com> wrote in message
> news:eq3sAnKSEHA.1312@TK2MSFTNGP12.phx.gbl...[color=green]
> > Charles,
> >
> > Rather then talking in the abstract what specifically does the[/color]
> presentation[color=green]
> > layer need to react to in conjunction with the data layer?
> >
> > Dan
> >
> > "Charles Law" <blank@nowhere.com> wrote in message
> > news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...[color=darkred]
> > > Take a solution with a project hierarchy along the lines of an n-tier
> > > system, so that we have a data layer, business layer and presentation[/color]
> > layer.[color=darkred]
> > > The presentation layer is coupled to the business layer, and the[/color][/color]
> business[color=green][color=darkred]
> > > layer is coupled to the data layer. So far so good.
> > >
> > > Suppose the data layer raises an event, and it passes Me (the sender)[/color][/color][/color]
as[color=blue][color=green]
> > an[color=darkred]
> > > object, and e (MyEventArgs, a descendent of EventArgs) to the layer[/color][/color]
> above[color=green][color=darkred]
> > > (the business layer). Suppose also that the business layer needs to[/color][/color][/color]
pass[color=blue][color=green][color=darkred]
> > > this event on to the presentation layer. It sends Me as an object, but[/color]
> > what[color=darkred]
> > > does it send e as? It can't send it as MyEventArgs because the[/color]
> > presentation[color=darkred]
> > > layer knows nothing of such things. We could couple the presentation[/color][/color]
> layer[color=green][color=darkred]
> > > to the data layer, so that it knows what a MyEventArgs is, but surely[/color][/color]
> that[color=green][color=darkred]
> > > is a no-no.
> > >
> > > We could also remove the definition of MyEventArgs to another project[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > which everything is coupled, but now this common project is in danger[/color][/color][/color]
of[color=blue][color=green][color=darkred]
> > > being an eclectic mix of stuff that is really specific to individual
> > > projects.
> > >
> > > We could define a business layer version of MyEventArgs - which is[/color]
> > actually[color=darkred]
> > > identical to the one in the data layer - and copy each element to the[/color][/color]
> new[color=green][color=darkred]
> > > object before passing it on, but that is a lot of typing, and now we[/color][/color]
> have[color=green][color=darkred]
> > > duplication.
> > >
> > > I am interested to hear what other people do in this situation.
> > >
> > > Charles
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

Hi Dan

Thanks for the time you have obviously spent understanding what I am trying
to do. I have used interfaces, but what has stopped me going that extra bit
further is the fact that I won't be able instantiate an interface. So, I
have settled with coupling to the library that contains the class itself.

I like the look of this INotify interface though. The name is suggestive of
the sort of thing I should be doing, so I am going to look into it further
and then let it sink in.

Thanks again.

Charles

"solex" <solex@nowhere.com> wrote in message
news:uJ4BfaNSEHA.1208@TK2MSFTNGP09.phx.gbl...[color=blue]
> Charles,
>
> I do a simlar thing but without events and do not have a problem. It[/color]
sounds[color=blue]
> to me like you need to start defining some interfaces and remove the[/color]
events.[color=blue]
> Doing this should remove some of you coupling problems and perhaps[/color]
increase[color=blue]
> your performance.
>
> Indicator control supports INotify interface
>
> Your presentation layer instantiates
> (1) the indicator control
> (2) the command layer.
> (3) initialzes the command layer with the already instantiated[/color]
indicator[color=blue]
> control(s) using the INotify interface
>
> As the command layer as you say "gets data back from the comms layer"
> instead of raising events it could loop through a set of registered[/color]
objects[color=blue]
> supporting the INotify interface and call an appropriate method.
>
> In this pattern, the indicator control knows nothing about your[/color]
presentation[color=blue]
> layer, command layer or communication layer. The coupling looks something
> like this (where -> means "knows" or "is coupled to")
>
> Presentation -> Indicator
> Presentation -> Command
> Presentation -> INotify
>
> Indicator -> INotify
>
> Command -> INotify
> Command -> Comms
>
> Dan
>
> "Charles Law" <blank@nowhere.com> wrote in message
> news:%23sYfCTLSEHA.2216@TK2MSFTNGP12.phx.gbl...[color=green]
> > Hi Dan
> >
> > I used the 3-tier example because it is a particularly familiar one. My
> > scenario has a presentation layer on top of a command layer, on top of a
> > communications layer, but with other bits on the side. It's a bit hard[/color][/color]
to[color=blue][color=green]
> > describe really.
> >
> > The presentation layer has view windows containing indicator controls.[/color]
> These[color=green]
> > controls are held in a library project. The presentation layer is
> > responsible for instantiating these controls in a view window.
> >
> > The command layer gets data back from the comms layer and raises events
> > based on the information. These events are handled by the indicators,[/color]
> which,[color=green]
> > whilst being instantiated at the presentation layer are contained in the
> > library, so that is where the events are handled. What this means is[/color][/color]
that[color=blue][color=green]
> > the library is coupled to both the presentation layer and the command[/color]
> layer,[color=green]
> > and the presentation layer is coupled to the command layer. This doesn't
> > quite create a circular reference, but it does cause the .NET[/color][/color]
IDE/compiler[color=blue][color=green]
> > immense problems when building.
> >
> > So, my reason for asking the question has other implications in that if[/color][/color]
I[color=blue][color=green]
> > can reduce the coupling I will actually be solving my build problems.
> >
> > Charles
> >
> >
> > "solex" <solex@nowhere.com> wrote in message
> > news:eq3sAnKSEHA.1312@TK2MSFTNGP12.phx.gbl...[color=darkred]
> > > Charles,
> > >
> > > Rather then talking in the abstract what specifically does the[/color]
> > presentation[color=darkred]
> > > layer need to react to in conjunction with the data layer?
> > >
> > > Dan
> > >
> > > "Charles Law" <blank@nowhere.com> wrote in message
> > > news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...
> > > > Take a solution with a project hierarchy along the lines of an[/color][/color][/color]
n-tier[color=blue][color=green][color=darkred]
> > > > system, so that we have a data layer, business layer and[/color][/color][/color]
presentation[color=blue][color=green][color=darkred]
> > > layer.
> > > > The presentation layer is coupled to the business layer, and the[/color]
> > business[color=darkred]
> > > > layer is coupled to the data layer. So far so good.
> > > >
> > > > Suppose the data layer raises an event, and it passes Me (the[/color][/color][/color]
sender)[color=blue]
> as[color=green][color=darkred]
> > > an
> > > > object, and e (MyEventArgs, a descendent of EventArgs) to the layer[/color]
> > above[color=darkred]
> > > > (the business layer). Suppose also that the business layer needs to[/color][/color]
> pass[color=green][color=darkred]
> > > > this event on to the presentation layer. It sends Me as an object,[/color][/color][/color]
but[color=blue][color=green][color=darkred]
> > > what
> > > > does it send e as? It can't send it as MyEventArgs because the
> > > presentation
> > > > layer knows nothing of such things. We could couple the presentation[/color]
> > layer[color=darkred]
> > > > to the data layer, so that it knows what a MyEventArgs is, but[/color][/color][/color]
surely[color=blue][color=green]
> > that[color=darkred]
> > > > is a no-no.
> > > >
> > > > We could also remove the definition of MyEventArgs to another[/color][/color][/color]
project[color=blue]
> to[color=green][color=darkred]
> > > > which everything is coupled, but now this common project is in[/color][/color][/color]
danger[color=blue]
> of[color=green][color=darkred]
> > > > being an eclectic mix of stuff that is really specific to individual
> > > > projects.
> > > >
> > > > We could define a business layer version of MyEventArgs - which is
> > > actually
> > > > identical to the one in the data layer - and copy each element to[/color][/color][/color]
the[color=blue][color=green]
> > new[color=darkred]
> > > > object before passing it on, but that is a lot of typing, and now we[/color]
> > have[color=darkred]
> > > > duplication.
> > > >
> > > > I am interested to hear what other people do in this situation.
> > > >
> > > > Charles
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

Charles,
It sounds like you really need to learn the Separated Interface Pattern
(Martin Fowler's book).

http://www.martinfowler.com/eaaCatal...Interface.html

Define an Interface that Class1 uses that Class2 implements. Put this
interface in the same assembly as Class1 (or a third assembly). The Class1
assembly needs to reference the assembly where the interface is defined if
its not in the same assembly. The Class2 assembly needs to reference the
Class1 assembly & the assembly where the interface is defined. Class2 can
reference Class1 directly, while Class1 can only reference Class2 via the
interface that it implements.

Something like:
' Assembly 1
Public Interface IClass2
Public Property Value1() As Integer
Public Sub Method1()
End Interface

Public Class Class1

Public Sub Test(ByVal object2 As IClass2)
If object2.Value1 = 100 Then
object2.Method1()
End If
End Sub

End Class

' Assembly 2
' References Assembly 1

Public Class Class2
Implements IClass2

Public Property Value1() As Integer Implements IClass2.Value1
...

Public Sub Method1() Implements IClass2.Value1
...

End Class

Note instead of an Interface, you could use an Abstract Base Class
(MustInherit).

The Interface IClass2 can contain events in addition to Properties,
Functions & Subs.

Also to elimate the coupling between Presentation & Data, I would use a
Proxy object for the EventArgs instead of actually copying the data.

Something like:

' From Data layer
Public Class DataEventArgs
Inherits EventArgs

Private Readonly m_amount As Integer

Public Sub New(amount As Integer)
m_amount = amount
End Sub

Public Readonly Property Amount As Integer
Get
Return m_amount
End Get
End Property

End Class

' From Domain Layer

Public Class DomainEventArgs
Inherits EventArgs

Private Readonly m_dataEventArgs As DataEventArgs

Public Sub New(dataEventArgs As DataEventArgs)
m_dataEventArgs = dataEventArgs
End Sub

Public Readonly Property Amount As Integer
Get
Return m_DataEventArgs.Amount
End Get
End Property

End Class

Although the Domain layer duplicates all the properties, the data itself is
not duplicate or exposed, as the DomainEventArgs acts as a Proxy for the
DataEventArgs, delegating all the calls to the DataEventArgs...

Hope this helps
Jay

"Charles Law" <blank@nowhere.com> wrote in message
news:uDWqYJMSEHA.2704@TK2MSFTNGP10.phx.gbl...[color=blue]
> Hi Jay
>[color=green]
> > I suspect most of the time the info that the domain layer needs in its
> > events is going to be different then the info needed in the data layer's
> > events, so each would have its own event handlers...[/color]
>
> I agree that this the case most of the time, it's just that in my case it
> isn't. If I used different EventArgs classes I would just be changing the
> object for the sake of it. No information is added or omitted as the event
> passes up the layers.
>
> As I described in my response to Dan, I have a set of custom controls that
> raise and sink events. These are instantiated by the presentation layer,[/color]
but[color=blue]
> the command layer is where the corresponding events are sunk (sinked?) and
> raised. I have ended up with tighter coupling than the compiler/IDE is
> comfortable with, and I get random, erroneous build errors all the time. I
> have seen others post about this problem, and it comes and goes for me. At
> the moment it has come, and I can't build my solution because I get large
> numbers of spurious messages about handlers and events having different
> signatures, when they haven't. That's why I am trying to loosen the[/color]
coupling[color=blue]
> so that I can just build the thing.
>
> Charles
>
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
> news:eVqENGLSEHA.3140@tk2msftngp13.phx.gbl...[color=green]
> > Charles,[color=darkred]
> > > The presentation layer is coupled to the business layer, and the[/color][/color]
> business[color=green][color=darkred]
> > > layer is coupled to the data layer. So far so good.[/color]
> > Actually I normally couple the presentation layer to the domain layer
> > (business layer) and couple the data layer to the domain layer!
> >
> > See Martin Fowler's book "Patterns of Enterprise Application[/color][/color]
Architecture"[color=blue][color=green]
> > from Addison Wesley
> > http://www.martinfowler.com/books.html#eaa. The sections on Domain[/color][/color]
Model,[color=blue][color=green]
> > Data Mapper, and Separated Interface discuss how to have the data layer
> > reference the domain layer, instead of having the domain layer reference[/color]
> the[color=green]
> > data layer. Having the data layer reference the domain layer, allows
> > replacing the data layer very easily! Also I find it provides better
> > separation (less coupling)...
> >[color=darkred]
> > > Suppose the data layer raises an event, and it passes Me (the sender)[/color][/color][/color]
as[color=blue][color=green]
> > an[color=darkred]
> > > object, and e (MyEventArgs, a descendent of EventArgs) to the layer[/color][/color]
> above[color=green]
> > In one of my projects that data layer has custom event handlers
> > (MyEventArgs, a descendent of EventArgs), while the domain layer simply[/color]
> uses[color=green]
> > EventHandler & passes EventArgs.Empty. As I found that the domain layer
> > needed to convey less information to the domain layer, then the data[/color][/color]
layer[color=blue][color=green]
> > did to the domain layer.
> >[color=darkred]
> > > We could define a business layer version of MyEventArgs - which is[/color]
> > actually[color=darkred]
> > > identical to the one in the data layer - and copy each element to the[/color][/color]
> new[color=green][color=darkred]
> > > object before passing it on, but that is a lot of typing, and now we[/color][/color]
> have[color=green][color=darkred]
> > > duplication.[/color]
> > I suspect most of the time the info that the domain layer needs in its
> > events is going to be different then the info needed in the data layer's
> > events, so each would have its own event handlers...
> >
> > Hope this helps
> > Jay
> >
> >
> >
> >
> > "Charles Law" <blank@nowhere.com> wrote in message
> > news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...[color=darkred]
> > > Take a solution with a project hierarchy along the lines of an n-tier
> > > system, so that we have a data layer, business layer and presentation[/color]
> > layer.[color=darkred]
> > > The presentation layer is coupled to the business layer, and the[/color][/color]
> business[color=green][color=darkred]
> > > layer is coupled to the data layer. So far so good.
> > >
> > > Suppose the data layer raises an event, and it passes Me (the sender)[/color][/color][/color]
as[color=blue][color=green]
> > an[color=darkred]
> > > object, and e (MyEventArgs, a descendent of EventArgs) to the layer[/color][/color]
> above[color=green][color=darkred]
> > > (the business layer). Suppose also that the business layer needs to[/color][/color][/color]
pass[color=blue][color=green][color=darkred]
> > > this event on to the presentation layer. It sends Me as an object, but[/color]
> > what[color=darkred]
> > > does it send e as? It can't send it as MyEventArgs because the[/color]
> > presentation[color=darkred]
> > > layer knows nothing of such things. We could couple the presentation[/color][/color]
> layer[color=green][color=darkred]
> > > to the data layer, so that it knows what a MyEventArgs is, but surely[/color][/color]
> that[color=green][color=darkred]
> > > is a no-no.
> > >
> > > We could also remove the definition of MyEventArgs to another project[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > which everything is coupled, but now this common project is in danger[/color][/color][/color]
of[color=blue][color=green][color=darkred]
> > > being an eclectic mix of stuff that is really specific to individual
> > > projects.
> > >
> > > We could define a business layer version of MyEventArgs - which is[/color]
> > actually[color=darkred]
> > > identical to the one in the data layer - and copy each element to the[/color][/color]
> new[color=green][color=darkred]
> > > object before passing it on, but that is a lot of typing, and now we[/color][/color]
> have[color=green][color=darkred]
> > > duplication.
> > >
> > > I am interested to hear what other people do in this situation.
> > >
> > > Charles
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

Hi Jay

I don't have the Fowler book, but I can feel a purchase or two coming on. I
have the GoF Design Patterns book, which does not mention the Separated
Interface Pattern as such; perhaps under a different name (?).

I have used interfaces in much the way you describe, so I am reassured in
that respect.

With regard to the use of a proxy, it does save copying the data, but with
around 50 events being bubbled, each with their own EventArgs class, that
still means another 50 proxy classes.

Just to clarify, you say 'assembly', I say 'project'. Are we talking about
the same thing?

Charles

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
news:u1EuDoQSEHA.620@TK2MSFTNGP10.phx.gbl...[color=blue]
> Charles,
> It sounds like you really need to learn the Separated Interface Pattern
> (Martin Fowler's book).
>
> http://www.martinfowler.com/eaaCatal...Interface.html
>
> Define an Interface that Class1 uses that Class2 implements. Put this
> interface in the same assembly as Class1 (or a third assembly). The Class1
> assembly needs to reference the assembly where the interface is defined if
> its not in the same assembly. The Class2 assembly needs to reference the
> Class1 assembly & the assembly where the interface is defined. Class2 can
> reference Class1 directly, while Class1 can only reference Class2 via the
> interface that it implements.
>
> Something like:
> ' Assembly 1
> Public Interface IClass2
> Public Property Value1() As Integer
> Public Sub Method1()
> End Interface
>
> Public Class Class1
>
> Public Sub Test(ByVal object2 As IClass2)
> If object2.Value1 = 100 Then
> object2.Method1()
> End If
> End Sub
>
> End Class
>
> ' Assembly 2
> ' References Assembly 1
>
> Public Class Class2
> Implements IClass2
>
> Public Property Value1() As Integer Implements IClass2.Value1
> ...
>
> Public Sub Method1() Implements IClass2.Value1
> ...
>
> End Class
>
> Note instead of an Interface, you could use an Abstract Base Class
> (MustInherit).
>
> The Interface IClass2 can contain events in addition to Properties,
> Functions & Subs.
>
> Also to elimate the coupling between Presentation & Data, I would use a
> Proxy object for the EventArgs instead of actually copying the data.
>
> Something like:
>
> ' From Data layer
> Public Class DataEventArgs
> Inherits EventArgs
>
> Private Readonly m_amount As Integer
>
> Public Sub New(amount As Integer)
> m_amount = amount
> End Sub
>
> Public Readonly Property Amount As Integer
> Get
> Return m_amount
> End Get
> End Property
>
> End Class
>
> ' From Domain Layer
>
> Public Class DomainEventArgs
> Inherits EventArgs
>
> Private Readonly m_dataEventArgs As DataEventArgs
>
> Public Sub New(dataEventArgs As DataEventArgs)
> m_dataEventArgs = dataEventArgs
> End Sub
>
> Public Readonly Property Amount As Integer
> Get
> Return m_DataEventArgs.Amount
> End Get
> End Property
>
> End Class
>
> Although the Domain layer duplicates all the properties, the data itself[/color]
is[color=blue]
> not duplicate or exposed, as the DomainEventArgs acts as a Proxy for the
> DataEventArgs, delegating all the calls to the DataEventArgs...
>
> Hope this helps
> Jay
>
> "Charles Law" <blank@nowhere.com> wrote in message
> news:uDWqYJMSEHA.2704@TK2MSFTNGP10.phx.gbl...[color=green]
> > Hi Jay
> >[color=darkred]
> > > I suspect most of the time the info that the domain layer needs in its
> > > events is going to be different then the info needed in the data[/color][/color][/color]
layer's[color=blue][color=green][color=darkred]
> > > events, so each would have its own event handlers...[/color]
> >
> > I agree that this the case most of the time, it's just that in my case[/color][/color]
it[color=blue][color=green]
> > isn't. If I used different EventArgs classes I would just be changing[/color][/color]
the[color=blue][color=green]
> > object for the sake of it. No information is added or omitted as the[/color][/color]
event[color=blue][color=green]
> > passes up the layers.
> >
> > As I described in my response to Dan, I have a set of custom controls[/color][/color]
that[color=blue][color=green]
> > raise and sink events. These are instantiated by the presentation layer,[/color]
> but[color=green]
> > the command layer is where the corresponding events are sunk (sinked?)[/color][/color]
and[color=blue][color=green]
> > raised. I have ended up with tighter coupling than the compiler/IDE is
> > comfortable with, and I get random, erroneous build errors all the time.[/color][/color]
I[color=blue][color=green]
> > have seen others post about this problem, and it comes and goes for me.[/color][/color]
At[color=blue][color=green]
> > the moment it has come, and I can't build my solution because I get[/color][/color]
large[color=blue][color=green]
> > numbers of spurious messages about handlers and events having different
> > signatures, when they haven't. That's why I am trying to loosen the[/color]
> coupling[color=green]
> > so that I can just build the thing.
> >
> > Charles
> >
> >
> > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color][/color]
message[color=blue][color=green]
> > news:eVqENGLSEHA.3140@tk2msftngp13.phx.gbl...[color=darkred]
> > > Charles,
> > > > The presentation layer is coupled to the business layer, and the[/color]
> > business[color=darkred]
> > > > layer is coupled to the data layer. So far so good.
> > > Actually I normally couple the presentation layer to the domain layer
> > > (business layer) and couple the data layer to the domain layer!
> > >
> > > See Martin Fowler's book "Patterns of Enterprise Application[/color][/color]
> Architecture"[color=green][color=darkred]
> > > from Addison Wesley
> > > http://www.martinfowler.com/books.html#eaa. The sections on Domain[/color][/color]
> Model,[color=green][color=darkred]
> > > Data Mapper, and Separated Interface discuss how to have the data[/color][/color][/color]
layer[color=blue][color=green][color=darkred]
> > > reference the domain layer, instead of having the domain layer[/color][/color][/color]
reference[color=blue][color=green]
> > the[color=darkred]
> > > data layer. Having the data layer reference the domain layer, allows
> > > replacing the data layer very easily! Also I find it provides better
> > > separation (less coupling)...
> > >
> > > > Suppose the data layer raises an event, and it passes Me (the[/color][/color][/color]
sender)[color=blue]
> as[color=green][color=darkred]
> > > an
> > > > object, and e (MyEventArgs, a descendent of EventArgs) to the layer[/color]
> > above[color=darkred]
> > > In one of my projects that data layer has custom event handlers
> > > (MyEventArgs, a descendent of EventArgs), while the domain layer[/color][/color][/color]
simply[color=blue][color=green]
> > uses[color=darkred]
> > > EventHandler & passes EventArgs.Empty. As I found that the domain[/color][/color][/color]
layer[color=blue][color=green][color=darkred]
> > > needed to convey less information to the domain layer, then the data[/color][/color]
> layer[color=green][color=darkred]
> > > did to the domain layer.
> > >
> > > > We could define a business layer version of MyEventArgs - which is
> > > actually
> > > > identical to the one in the data layer - and copy each element to[/color][/color][/color]
the[color=blue][color=green]
> > new[color=darkred]
> > > > object before passing it on, but that is a lot of typing, and now we[/color]
> > have[color=darkred]
> > > > duplication.
> > > I suspect most of the time the info that the domain layer needs in its
> > > events is going to be different then the info needed in the data[/color][/color][/color]
layer's[color=blue][color=green][color=darkred]
> > > events, so each would have its own event handlers...
> > >
> > > Hope this helps
> > > Jay
> > >
> > >
> > >
> > >
> > > "Charles Law" <blank@nowhere.com> wrote in message
> > > news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...
> > > > Take a solution with a project hierarchy along the lines of an[/color][/color][/color]
n-tier[color=blue][color=green][color=darkred]
> > > > system, so that we have a data layer, business layer and[/color][/color][/color]
presentation[color=blue][color=green][color=darkred]
> > > layer.
> > > > The presentation layer is coupled to the business layer, and the[/color]
> > business[color=darkred]
> > > > layer is coupled to the data layer. So far so good.
> > > >
> > > > Suppose the data layer raises an event, and it passes Me (the[/color][/color][/color]
sender)[color=blue]
> as[color=green][color=darkred]
> > > an
> > > > object, and e (MyEventArgs, a descendent of EventArgs) to the layer[/color]
> > above[color=darkred]
> > > > (the business layer). Suppose also that the business layer needs to[/color][/color]
> pass[color=green][color=darkred]
> > > > this event on to the presentation layer. It sends Me as an object,[/color][/color][/color]
but[color=blue][color=green][color=darkred]
> > > what
> > > > does it send e as? It can't send it as MyEventArgs because the
> > > presentation
> > > > layer knows nothing of such things. We could couple the presentation[/color]
> > layer[color=darkred]
> > > > to the data layer, so that it knows what a MyEventArgs is, but[/color][/color][/color]
surely[color=blue][color=green]
> > that[color=darkred]
> > > > is a no-no.
> > > >
> > > > We could also remove the definition of MyEventArgs to another[/color][/color][/color]
project[color=blue]
> to[color=green][color=darkred]
> > > > which everything is coupled, but now this common project is in[/color][/color][/color]
danger[color=blue]
> of[color=green][color=darkred]
> > > > being an eclectic mix of stuff that is really specific to individual
> > > > projects.
> > > >
> > > > We could define a business layer version of MyEventArgs - which is
> > > actually
> > > > identical to the one in the data layer - and copy each element to[/color][/color][/color]
the[color=blue][color=green]
> > new[color=darkred]
> > > > object before passing it on, but that is a lot of typing, and now we[/color]
> > have[color=darkred]
> > > > duplication.
> > > >
> > > > I am interested to hear what other people do in this situation.
> > > >
> > > > Charles
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

Charles,[color=blue]
> I don't have the Fowler book, but I can feel a purchase or two coming on.[/color]
I[color=blue]
> have the GoF Design Patterns book, which does not mention the Separated
> Interface Pattern as such; perhaps under a different name (?).[/color]
Fowler's book takes off where the GoF book stops.
[color=blue]
> I have used interfaces in much the way you describe, so I am reassured in
> that respect.[/color]
I may have miss read one of your other posts, I got the impression you did
not understand interfaces...
[color=blue]
> With regard to the use of a proxy, it does save copying the data, but with
> around 50 events being bubbled, each with their own EventArgs class, that
> still means another 50 proxy classes.[/color]
It really comes down to: How much coupling are you willing to live with! ;-)

The proxy allows you to avoid coupling, have fair performance, and expose
all or most of the same properties in both events. At the expense of
creating the proxy classes...
[color=blue]
> Just to clarify, you say 'assembly', I say 'project'. Are we talking about
> the same thing?[/color]
Yes

Hope this helps
Jay

"Charles Law" <blank@nowhere.com> wrote in message
news:uCm$ufVSEHA.2780@TK2MSFTNGP09.phx.gbl...[color=blue]
> Hi Jay
>
> I don't have the Fowler book, but I can feel a purchase or two coming on.[/color]
I[color=blue]
> have the GoF Design Patterns book, which does not mention the Separated
> Interface Pattern as such; perhaps under a different name (?).
>
> I have used interfaces in much the way you describe, so I am reassured in
> that respect.
>
> With regard to the use of a proxy, it does save copying the data, but with
> around 50 events being bubbled, each with their own EventArgs class, that
> still means another 50 proxy classes.
>
> Just to clarify, you say 'assembly', I say 'project'. Are we talking about
> the same thing?
>
> Charles
>
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
> news:u1EuDoQSEHA.620@TK2MSFTNGP10.phx.gbl...[color=green]
> > Charles,
> > It sounds like you really need to learn the Separated Interface Pattern
> > (Martin Fowler's book).
> >
> > http://www.martinfowler.com/eaaCatal...Interface.html
> >
> > Define an Interface that Class1 uses that Class2 implements. Put this
> > interface in the same assembly as Class1 (or a third assembly). The[/color][/color]
Class1[color=blue][color=green]
> > assembly needs to reference the assembly where the interface is defined[/color][/color]
if[color=blue][color=green]
> > its not in the same assembly. The Class2 assembly needs to reference the
> > Class1 assembly & the assembly where the interface is defined. Class2[/color][/color]
can[color=blue][color=green]
> > reference Class1 directly, while Class1 can only reference Class2 via[/color][/color]
the[color=blue][color=green]
> > interface that it implements.
> >
> > Something like:
> > ' Assembly 1
> > Public Interface IClass2
> > Public Property Value1() As Integer
> > Public Sub Method1()
> > End Interface
> >
> > Public Class Class1
> >
> > Public Sub Test(ByVal object2 As IClass2)
> > If object2.Value1 = 100 Then
> > object2.Method1()
> > End If
> > End Sub
> >
> > End Class
> >
> > ' Assembly 2
> > ' References Assembly 1
> >
> > Public Class Class2
> > Implements IClass2
> >
> > Public Property Value1() As Integer Implements IClass2.Value1
> > ...
> >
> > Public Sub Method1() Implements IClass2.Value1
> > ...
> >
> > End Class
> >
> > Note instead of an Interface, you could use an Abstract Base Class
> > (MustInherit).
> >
> > The Interface IClass2 can contain events in addition to Properties,
> > Functions & Subs.
> >
> > Also to elimate the coupling between Presentation & Data, I would use a
> > Proxy object for the EventArgs instead of actually copying the data.
> >
> > Something like:
> >
> > ' From Data layer
> > Public Class DataEventArgs
> > Inherits EventArgs
> >
> > Private Readonly m_amount As Integer
> >
> > Public Sub New(amount As Integer)
> > m_amount = amount
> > End Sub
> >
> > Public Readonly Property Amount As Integer
> > Get
> > Return m_amount
> > End Get
> > End Property
> >
> > End Class
> >
> > ' From Domain Layer
> >
> > Public Class DomainEventArgs
> > Inherits EventArgs
> >
> > Private Readonly m_dataEventArgs As DataEventArgs
> >
> > Public Sub New(dataEventArgs As DataEventArgs)
> > m_dataEventArgs = dataEventArgs
> > End Sub
> >
> > Public Readonly Property Amount As Integer
> > Get
> > Return m_DataEventArgs.Amount
> > End Get
> > End Property
> >
> > End Class
> >
> > Although the Domain layer duplicates all the properties, the data itself[/color]
> is[color=green]
> > not duplicate or exposed, as the DomainEventArgs acts as a Proxy for the
> > DataEventArgs, delegating all the calls to the DataEventArgs...
> >
> > Hope this helps
> > Jay
> >
> > "Charles Law" <blank@nowhere.com> wrote in message
> > news:uDWqYJMSEHA.2704@TK2MSFTNGP10.phx.gbl...[color=darkred]
> > > Hi Jay
> > >
> > > > I suspect most of the time the info that the domain layer needs in[/color][/color][/color]
its[color=blue][color=green][color=darkred]
> > > > events is going to be different then the info needed in the data[/color][/color]
> layer's[color=green][color=darkred]
> > > > events, so each would have its own event handlers...
> > >
> > > I agree that this the case most of the time, it's just that in my case[/color][/color]
> it[color=green][color=darkred]
> > > isn't. If I used different EventArgs classes I would just be changing[/color][/color]
> the[color=green][color=darkred]
> > > object for the sake of it. No information is added or omitted as the[/color][/color]
> event[color=green][color=darkred]
> > > passes up the layers.
> > >
> > > As I described in my response to Dan, I have a set of custom controls[/color][/color]
> that[color=green][color=darkred]
> > > raise and sink events. These are instantiated by the presentation[/color][/color][/color]
layer,[color=blue][color=green]
> > but[color=darkred]
> > > the command layer is where the corresponding events are sunk (sinked?)[/color][/color]
> and[color=green][color=darkred]
> > > raised. I have ended up with tighter coupling than the compiler/IDE is
> > > comfortable with, and I get random, erroneous build errors all the[/color][/color][/color]
time.[color=blue]
> I[color=green][color=darkred]
> > > have seen others post about this problem, and it comes and goes for[/color][/color][/color]
me.[color=blue]
> At[color=green][color=darkred]
> > > the moment it has come, and I can't build my solution because I get[/color][/color]
> large[color=green][color=darkred]
> > > numbers of spurious messages about handlers and events having[/color][/color][/color]
different[color=blue][color=green][color=darkred]
> > > signatures, when they haven't. That's why I am trying to loosen the[/color]
> > coupling[color=darkred]
> > > so that I can just build the thing.
> > >
> > > Charles
> > >
> > >
> > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color][/color]
> message[color=green][color=darkred]
> > > news:eVqENGLSEHA.3140@tk2msftngp13.phx.gbl...
> > > > Charles,
> > > > > The presentation layer is coupled to the business layer, and the
> > > business
> > > > > layer is coupled to the data layer. So far so good.
> > > > Actually I normally couple the presentation layer to the domain[/color][/color][/color]
layer[color=blue][color=green][color=darkred]
> > > > (business layer) and couple the data layer to the domain layer!
> > > >
> > > > See Martin Fowler's book "Patterns of Enterprise Application[/color]
> > Architecture"[color=darkred]
> > > > from Addison Wesley
> > > > http://www.martinfowler.com/books.html#eaa. The sections on Domain[/color]
> > Model,[color=darkred]
> > > > Data Mapper, and Separated Interface discuss how to have the data[/color][/color]
> layer[color=green][color=darkred]
> > > > reference the domain layer, instead of having the domain layer[/color][/color]
> reference[color=green][color=darkred]
> > > the
> > > > data layer. Having the data layer reference the domain layer, allows
> > > > replacing the data layer very easily! Also I find it provides better
> > > > separation (less coupling)...
> > > >
> > > > > Suppose the data layer raises an event, and it passes Me (the[/color][/color]
> sender)[color=green]
> > as[color=darkred]
> > > > an
> > > > > object, and e (MyEventArgs, a descendent of EventArgs) to the[/color][/color][/color]
layer[color=blue][color=green][color=darkred]
> > > above
> > > > In one of my projects that data layer has custom event handlers
> > > > (MyEventArgs, a descendent of EventArgs), while the domain layer[/color][/color]
> simply[color=green][color=darkred]
> > > uses
> > > > EventHandler & passes EventArgs.Empty. As I found that the domain[/color][/color]
> layer[color=green][color=darkred]
> > > > needed to convey less information to the domain layer, then the data[/color]
> > layer[color=darkred]
> > > > did to the domain layer.
> > > >
> > > > > We could define a business layer version of MyEventArgs - which is
> > > > actually
> > > > > identical to the one in the data layer - and copy each element to[/color][/color]
> the[color=green][color=darkred]
> > > new
> > > > > object before passing it on, but that is a lot of typing, and now[/color][/color][/color]
we[color=blue][color=green][color=darkred]
> > > have
> > > > > duplication.
> > > > I suspect most of the time the info that the domain layer needs in[/color][/color][/color]
its[color=blue][color=green][color=darkred]
> > > > events is going to be different then the info needed in the data[/color][/color]
> layer's[color=green][color=darkred]
> > > > events, so each would have its own event handlers...
> > > >
> > > > Hope this helps
> > > > Jay
> > > >
> > > >
> > > >
> > > >
> > > > "Charles Law" <blank@nowhere.com> wrote in message
> > > > news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...
> > > > > Take a solution with a project hierarchy along the lines of an[/color][/color]
> n-tier[color=green][color=darkred]
> > > > > system, so that we have a data layer, business layer and[/color][/color]
> presentation[color=green][color=darkred]
> > > > layer.
> > > > > The presentation layer is coupled to the business layer, and the
> > > business
> > > > > layer is coupled to the data layer. So far so good.
> > > > >
> > > > > Suppose the data layer raises an event, and it passes Me (the[/color][/color]
> sender)[color=green]
> > as[color=darkred]
> > > > an
> > > > > object, and e (MyEventArgs, a descendent of EventArgs) to the[/color][/color][/color]
layer[color=blue][color=green][color=darkred]
> > > above
> > > > > (the business layer). Suppose also that the business layer needs[/color][/color][/color]
to[color=blue][color=green]
> > pass[color=darkred]
> > > > > this event on to the presentation layer. It sends Me as an object,[/color][/color]
> but[color=green][color=darkred]
> > > > what
> > > > > does it send e as? It can't send it as MyEventArgs because the
> > > > presentation
> > > > > layer knows nothing of such things. We could couple the[/color][/color][/color]
presentation[color=blue][color=green][color=darkred]
> > > layer
> > > > > to the data layer, so that it knows what a MyEventArgs is, but[/color][/color]
> surely[color=green][color=darkred]
> > > that
> > > > > is a no-no.
> > > > >
> > > > > We could also remove the definition of MyEventArgs to another[/color][/color]
> project[color=green]
> > to[color=darkred]
> > > > > which everything is coupled, but now this common project is in[/color][/color]
> danger[color=green]
> > of[color=darkred]
> > > > > being an eclectic mix of stuff that is really specific to[/color][/color][/color]
individual[color=blue][color=green][color=darkred]
> > > > > projects.
> > > > >
> > > > > We could define a business layer version of MyEventArgs - which is
> > > > actually
> > > > > identical to the one in the data layer - and copy each element to[/color][/color]
> the[color=green][color=darkred]
> > > new
> > > > > object before passing it on, but that is a lot of typing, and now[/color][/color][/color]
we[color=blue][color=green][color=darkred]
> > > have
> > > > > duplication.
> > > > >
> > > > > I am interested to hear what other people do in this situation.
> > > > >
> > > > > Charles
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

Hi Jay
[color=blue]
> I may have miss read one of your other posts, I got the impression you did
> not understand interfaces...[/color]

Not me guv. You must have me mixed up with someone else; use 'em all the
time, I do ;-)

Anyway, I take on board what you say. Thanks.

Charles

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
news:e7T7UhWSEHA.3728@TK2MSFTNGP11.phx.gbl...[color=blue]
> Charles,[color=green]
> > I don't have the Fowler book, but I can feel a purchase or two coming[/color][/color]
on.[color=blue]
> I[color=green]
> > have the GoF Design Patterns book, which does not mention the Separated
> > Interface Pattern as such; perhaps under a different name (?).[/color]
> Fowler's book takes off where the GoF book stops.
>[color=green]
> > I have used interfaces in much the way you describe, so I am reassured[/color][/color]
in[color=blue][color=green]
> > that respect.[/color]
> I may have miss read one of your other posts, I got the impression you did
> not understand interfaces...
>[color=green]
> > With regard to the use of a proxy, it does save copying the data, but[/color][/color]
with[color=blue][color=green]
> > around 50 events being bubbled, each with their own EventArgs class,[/color][/color]
that[color=blue][color=green]
> > still means another 50 proxy classes.[/color]
> It really comes down to: How much coupling are you willing to live with![/color]
;-)[color=blue]
>
> The proxy allows you to avoid coupling, have fair performance, and expose
> all or most of the same properties in both events. At the expense of
> creating the proxy classes...
>[color=green]
> > Just to clarify, you say 'assembly', I say 'project'. Are we talking[/color][/color]
about[color=blue][color=green]
> > the same thing?[/color]
> Yes
>
> Hope this helps
> Jay
>
>
> "Charles Law" <blank@nowhere.com> wrote in message
> news:uCm$ufVSEHA.2780@TK2MSFTNGP09.phx.gbl...[color=green]
> > Hi Jay
> >
> > I don't have the Fowler book, but I can feel a purchase or two coming[/color][/color]
on.[color=blue]
> I[color=green]
> > have the GoF Design Patterns book, which does not mention the Separated
> > Interface Pattern as such; perhaps under a different name (?).
> >
> > I have used interfaces in much the way you describe, so I am reassured[/color][/color]
in[color=blue][color=green]
> > that respect.
> >
> > With regard to the use of a proxy, it does save copying the data, but[/color][/color]
with[color=blue][color=green]
> > around 50 events being bubbled, each with their own EventArgs class,[/color][/color]
that[color=blue][color=green]
> > still means another 50 proxy classes.
> >
> > Just to clarify, you say 'assembly', I say 'project'. Are we talking[/color][/color]
about[color=blue][color=green]
> > the same thing?
> >
> > Charles
> >
> >
> > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color][/color]
message[color=blue][color=green]
> > news:u1EuDoQSEHA.620@TK2MSFTNGP10.phx.gbl...[color=darkred]
> > > Charles,
> > > It sounds like you really need to learn the Separated Interface[/color][/color][/color]
Pattern[color=blue][color=green][color=darkred]
> > > (Martin Fowler's book).
> > >
> > > http://www.martinfowler.com/eaaCatal...Interface.html
> > >
> > > Define an Interface that Class1 uses that Class2 implements. Put this
> > > interface in the same assembly as Class1 (or a third assembly). The[/color][/color]
> Class1[color=green][color=darkred]
> > > assembly needs to reference the assembly where the interface is[/color][/color][/color]
defined[color=blue]
> if[color=green][color=darkred]
> > > its not in the same assembly. The Class2 assembly needs to reference[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > Class1 assembly & the assembly where the interface is defined. Class2[/color][/color]
> can[color=green][color=darkred]
> > > reference Class1 directly, while Class1 can only reference Class2 via[/color][/color]
> the[color=green][color=darkred]
> > > interface that it implements.
> > >
> > > Something like:
> > > ' Assembly 1
> > > Public Interface IClass2
> > > Public Property Value1() As Integer
> > > Public Sub Method1()
> > > End Interface
> > >
> > > Public Class Class1
> > >
> > > Public Sub Test(ByVal object2 As IClass2)
> > > If object2.Value1 = 100 Then
> > > object2.Method1()
> > > End If
> > > End Sub
> > >
> > > End Class
> > >
> > > ' Assembly 2
> > > ' References Assembly 1
> > >
> > > Public Class Class2
> > > Implements IClass2
> > >
> > > Public Property Value1() As Integer Implements IClass2.Value1
> > > ...
> > >
> > > Public Sub Method1() Implements IClass2.Value1
> > > ...
> > >
> > > End Class
> > >
> > > Note instead of an Interface, you could use an Abstract Base Class
> > > (MustInherit).
> > >
> > > The Interface IClass2 can contain events in addition to Properties,
> > > Functions & Subs.
> > >
> > > Also to elimate the coupling between Presentation & Data, I would use[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> > > Proxy object for the EventArgs instead of actually copying the data.
> > >
> > > Something like:
> > >
> > > ' From Data layer
> > > Public Class DataEventArgs
> > > Inherits EventArgs
> > >
> > > Private Readonly m_amount As Integer
> > >
> > > Public Sub New(amount As Integer)
> > > m_amount = amount
> > > End Sub
> > >
> > > Public Readonly Property Amount As Integer
> > > Get
> > > Return m_amount
> > > End Get
> > > End Property
> > >
> > > End Class
> > >
> > > ' From Domain Layer
> > >
> > > Public Class DomainEventArgs
> > > Inherits EventArgs
> > >
> > > Private Readonly m_dataEventArgs As DataEventArgs
> > >
> > > Public Sub New(dataEventArgs As DataEventArgs)
> > > m_dataEventArgs = dataEventArgs
> > > End Sub
> > >
> > > Public Readonly Property Amount As Integer
> > > Get
> > > Return m_DataEventArgs.Amount
> > > End Get
> > > End Property
> > >
> > > End Class
> > >
> > > Although the Domain layer duplicates all the properties, the data[/color][/color][/color]
itself[color=blue][color=green]
> > is[color=darkred]
> > > not duplicate or exposed, as the DomainEventArgs acts as a Proxy for[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > DataEventArgs, delegating all the calls to the DataEventArgs...
> > >
> > > Hope this helps
> > > Jay
> > >
> > > "Charles Law" <blank@nowhere.com> wrote in message
> > > news:uDWqYJMSEHA.2704@TK2MSFTNGP10.phx.gbl...
> > > > Hi Jay
> > > >
> > > > > I suspect most of the time the info that the domain layer needs in[/color][/color]
> its[color=green][color=darkred]
> > > > > events is going to be different then the info needed in the data[/color]
> > layer's[color=darkred]
> > > > > events, so each would have its own event handlers...
> > > >
> > > > I agree that this the case most of the time, it's just that in my[/color][/color][/color]
case[color=blue][color=green]
> > it[color=darkred]
> > > > isn't. If I used different EventArgs classes I would just be[/color][/color][/color]
changing[color=blue][color=green]
> > the[color=darkred]
> > > > object for the sake of it. No information is added or omitted as the[/color]
> > event[color=darkred]
> > > > passes up the layers.
> > > >
> > > > As I described in my response to Dan, I have a set of custom[/color][/color][/color]
controls[color=blue][color=green]
> > that[color=darkred]
> > > > raise and sink events. These are instantiated by the presentation[/color][/color]
> layer,[color=green][color=darkred]
> > > but
> > > > the command layer is where the corresponding events are sunk[/color][/color][/color]
(sinked?)[color=blue][color=green]
> > and[color=darkred]
> > > > raised. I have ended up with tighter coupling than the compiler/IDE[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> > > > comfortable with, and I get random, erroneous build errors all the[/color][/color]
> time.[color=green]
> > I[color=darkred]
> > > > have seen others post about this problem, and it comes and goes for[/color][/color]
> me.[color=green]
> > At[color=darkred]
> > > > the moment it has come, and I can't build my solution because I get[/color]
> > large[color=darkred]
> > > > numbers of spurious messages about handlers and events having[/color][/color]
> different[color=green][color=darkred]
> > > > signatures, when they haven't. That's why I am trying to loosen the
> > > coupling
> > > > so that I can just build the thing.
> > > >
> > > > Charles
> > > >
> > > >
> > > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color]
> > message[color=darkred]
> > > > news:eVqENGLSEHA.3140@tk2msftngp13.phx.gbl...
> > > > > Charles,
> > > > > > The presentation layer is coupled to the business layer, and the
> > > > business
> > > > > > layer is coupled to the data layer. So far so good.
> > > > > Actually I normally couple the presentation layer to the domain[/color][/color]
> layer[color=green][color=darkred]
> > > > > (business layer) and couple the data layer to the domain layer!
> > > > >
> > > > > See Martin Fowler's book "Patterns of Enterprise Application
> > > Architecture"
> > > > > from Addison Wesley
> > > > > http://www.martinfowler.com/books.html#eaa. The sections on Domain
> > > Model,
> > > > > Data Mapper, and Separated Interface discuss how to have the data[/color]
> > layer[color=darkred]
> > > > > reference the domain layer, instead of having the domain layer[/color]
> > reference[color=darkred]
> > > > the
> > > > > data layer. Having the data layer reference the domain layer,[/color][/color][/color]
allows[color=blue][color=green][color=darkred]
> > > > > replacing the data layer very easily! Also I find it provides[/color][/color][/color]
better[color=blue][color=green][color=darkred]
> > > > > separation (less coupling)...
> > > > >
> > > > > > Suppose the data layer raises an event, and it passes Me (the[/color]
> > sender)[color=darkred]
> > > as
> > > > > an
> > > > > > object, and e (MyEventArgs, a descendent of EventArgs) to the[/color][/color]
> layer[color=green][color=darkred]
> > > > above
> > > > > In one of my projects that data layer has custom event handlers
> > > > > (MyEventArgs, a descendent of EventArgs), while the domain layer[/color]
> > simply[color=darkred]
> > > > uses
> > > > > EventHandler & passes EventArgs.Empty. As I found that the domain[/color]
> > layer[color=darkred]
> > > > > needed to convey less information to the domain layer, then the[/color][/color][/color]
data[color=blue][color=green][color=darkred]
> > > layer
> > > > > did to the domain layer.
> > > > >
> > > > > > We could define a business layer version of MyEventArgs - which[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> > > > > actually
> > > > > > identical to the one in the data layer - and copy each element[/color][/color][/color]
to[color=blue][color=green]
> > the[color=darkred]
> > > > new
> > > > > > object before passing it on, but that is a lot of typing, and[/color][/color][/color]
now[color=blue]
> we[color=green][color=darkred]
> > > > have
> > > > > > duplication.
> > > > > I suspect most of the time the info that the domain layer needs in[/color][/color]
> its[color=green][color=darkred]
> > > > > events is going to be different then the info needed in the data[/color]
> > layer's[color=darkred]
> > > > > events, so each would have its own event handlers...
> > > > >
> > > > > Hope this helps
> > > > > Jay
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Charles Law" <blank@nowhere.com> wrote in message
> > > > > news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...
> > > > > > Take a solution with a project hierarchy along the lines of an[/color]
> > n-tier[color=darkred]
> > > > > > system, so that we have a data layer, business layer and[/color]
> > presentation[color=darkred]
> > > > > layer.
> > > > > > The presentation layer is coupled to the business layer, and the
> > > > business
> > > > > > layer is coupled to the data layer. So far so good.
> > > > > >
> > > > > > Suppose the data layer raises an event, and it passes Me (the[/color]
> > sender)[color=darkred]
> > > as
> > > > > an
> > > > > > object, and e (MyEventArgs, a descendent of EventArgs) to the[/color][/color]
> layer[color=green][color=darkred]
> > > > above
> > > > > > (the business layer). Suppose also that the business layer needs[/color][/color]
> to[color=green][color=darkred]
> > > pass
> > > > > > this event on to the presentation layer. It sends Me as an[/color][/color][/color]
object,[color=blue][color=green]
> > but[color=darkred]
> > > > > what
> > > > > > does it send e as? It can't send it as MyEventArgs because the
> > > > > presentation
> > > > > > layer knows nothing of such things. We could couple the[/color][/color]
> presentation[color=green][color=darkred]
> > > > layer
> > > > > > to the data layer, so that it knows what a MyEventArgs is, but[/color]
> > surely[color=darkred]
> > > > that
> > > > > > is a no-no.
> > > > > >
> > > > > > We could also remove the definition of MyEventArgs to another[/color]
> > project[color=darkred]
> > > to
> > > > > > which everything is coupled, but now this common project is in[/color]
> > danger[color=darkred]
> > > of
> > > > > > being an eclectic mix of stuff that is really specific to[/color][/color]
> individual[color=green][color=darkred]
> > > > > > projects.
> > > > > >
> > > > > > We could define a business layer version of MyEventArgs - which[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> > > > > actually
> > > > > > identical to the one in the data layer - and copy each element[/color][/color][/color]
to[color=blue][color=green]
> > the[color=darkred]
> > > > new
> > > > > > object before passing it on, but that is a lot of typing, and[/color][/color][/color]
now[color=blue]
> we[color=green][color=darkred]
> > > > have
> > > > > > duplication.
> > > > > >
> > > > > > I am interested to hear what other people do in this situation.
> > > > > >
> > > > > > Charles
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

Charles,
Earlier in this thread you replied to solex with:[color=blue]
> Thanks for the time you have obviously spent understanding what I am[/color]
trying[color=blue]
> to do. I have used interfaces, but what has stopped me going that extra[/color]
bit[color=blue]
> further is the fact that I won't be able instantiate an interface. So, I
> have settled with coupling to the library that contains the class itself.[/color]

The "won't be able instantiate an interface" is the cause of my confusion
(where I got the impression...).

When I use the Separated Interface Pattern, I normally use the Plugin
Pattern also.
http://www.martinfowler.com/eaaCatal...Interface.html
http://www.martinfowler.com/eaaCatalog/plugin.html

I store the names of the classes that implements a specific interface in the
app.config file. I then use System.Activator.CreateInstance to create
instances of these classes. Sometimes I simply pass the interface as a
parameter as I show in my earlier post.

For example in the Domain Model & Data Mapper scenario I mentioned earlier,
I have a custom configuration section in my app.config that identifies the
data mapper class for a given domain class. In my framework assembly I have
a shared method that takes a domain object Type and looks up the DataMapper
type name in the app.config, uses Activator.CreateInstance to return an
instance of the class that implements IDataMapper.

I can post code samples this evening if you like.

Hope this helps
Jay

"Charles Law" <blank@nowhere.com> wrote in message
news:OPRh$1WSEHA.3140@tk2msftngp13.phx.gbl...[color=blue]
> Hi Jay
>[color=green]
> > I may have miss read one of your other posts, I got the impression you[/color][/color]
did[color=blue][color=green]
> > not understand interfaces...[/color]
>
> Not me guv. You must have me mixed up with someone else; use 'em all the
> time, I do ;-)
>
> Anyway, I take on board what you say. Thanks.
>
> Charles
>
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
> news:e7T7UhWSEHA.3728@TK2MSFTNGP11.phx.gbl...[color=green]
> > Charles,[color=darkred]
> > > I don't have the Fowler book, but I can feel a purchase or two coming[/color][/color]
> on.[color=green]
> > I[color=darkred]
> > > have the GoF Design Patterns book, which does not mention the[/color][/color][/color]
Separated[color=blue][color=green][color=darkred]
> > > Interface Pattern as such; perhaps under a different name (?).[/color]
> > Fowler's book takes off where the GoF book stops.
> >[color=darkred]
> > > I have used interfaces in much the way you describe, so I am reassured[/color][/color]
> in[color=green][color=darkred]
> > > that respect.[/color]
> > I may have miss read one of your other posts, I got the impression you[/color][/color]
did[color=blue][color=green]
> > not understand interfaces...
> >[color=darkred]
> > > With regard to the use of a proxy, it does save copying the data, but[/color][/color]
> with[color=green][color=darkred]
> > > around 50 events being bubbled, each with their own EventArgs class,[/color][/color]
> that[color=green][color=darkred]
> > > still means another 50 proxy classes.[/color]
> > It really comes down to: How much coupling are you willing to live with![/color]
> ;-)[color=green]
> >
> > The proxy allows you to avoid coupling, have fair performance, and[/color][/color]
expose[color=blue][color=green]
> > all or most of the same properties in both events. At the expense of
> > creating the proxy classes...
> >[color=darkred]
> > > Just to clarify, you say 'assembly', I say 'project'. Are we talking[/color][/color]
> about[color=green][color=darkred]
> > > the same thing?[/color]
> > Yes
> >
> > Hope this helps
> > Jay
> >
> >
> > "Charles Law" <blank@nowhere.com> wrote in message
> > news:uCm$ufVSEHA.2780@TK2MSFTNGP09.phx.gbl...[color=darkred]
> > > Hi Jay
> > >
> > > I don't have the Fowler book, but I can feel a purchase or two coming[/color][/color]
> on.[color=green]
> > I[color=darkred]
> > > have the GoF Design Patterns book, which does not mention the[/color][/color][/color]
Separated[color=blue][color=green][color=darkred]
> > > Interface Pattern as such; perhaps under a different name (?).
> > >
> > > I have used interfaces in much the way you describe, so I am reassured[/color][/color]
> in[color=green][color=darkred]
> > > that respect.
> > >
> > > With regard to the use of a proxy, it does save copying the data, but[/color][/color]
> with[color=green][color=darkred]
> > > around 50 events being bubbled, each with their own EventArgs class,[/color][/color]
> that[color=green][color=darkred]
> > > still means another 50 proxy classes.
> > >
> > > Just to clarify, you say 'assembly', I say 'project'. Are we talking[/color][/color]
> about[color=green][color=darkred]
> > > the same thing?
> > >
> > > Charles
> > >
> > >
> > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color][/color]
> message[color=green][color=darkred]
> > > news:u1EuDoQSEHA.620@TK2MSFTNGP10.phx.gbl...
> > > > Charles,
> > > > It sounds like you really need to learn the Separated Interface[/color][/color]
> Pattern[color=green][color=darkred]
> > > > (Martin Fowler's book).
> > > >
> > > > http://www.martinfowler.com/eaaCatal...Interface.html
> > > >
> > > > Define an Interface that Class1 uses that Class2 implements. Put[/color][/color][/color]
this[color=blue][color=green][color=darkred]
> > > > interface in the same assembly as Class1 (or a third assembly). The[/color]
> > Class1[color=darkred]
> > > > assembly needs to reference the assembly where the interface is[/color][/color]
> defined[color=green]
> > if[color=darkred]
> > > > its not in the same assembly. The Class2 assembly needs to reference[/color][/color]
> the[color=green][color=darkred]
> > > > Class1 assembly & the assembly where the interface is defined.[/color][/color][/color]
Class2[color=blue][color=green]
> > can[color=darkred]
> > > > reference Class1 directly, while Class1 can only reference Class2[/color][/color][/color]
via[color=blue][color=green]
> > the[color=darkred]
> > > > interface that it implements.
> > > >
> > > > Something like:
> > > > ' Assembly 1
> > > > Public Interface IClass2
> > > > Public Property Value1() As Integer
> > > > Public Sub Method1()
> > > > End Interface
> > > >
> > > > Public Class Class1
> > > >
> > > > Public Sub Test(ByVal object2 As IClass2)
> > > > If object2.Value1 = 100 Then
> > > > object2.Method1()
> > > > End If
> > > > End Sub
> > > >
> > > > End Class
> > > >
> > > > ' Assembly 2
> > > > ' References Assembly 1
> > > >
> > > > Public Class Class2
> > > > Implements IClass2
> > > >
> > > > Public Property Value1() As Integer Implements[/color][/color][/color]
IClass2.Value1[color=blue][color=green][color=darkred]
> > > > ...
> > > >
> > > > Public Sub Method1() Implements IClass2.Value1
> > > > ...
> > > >
> > > > End Class
> > > >
> > > > Note instead of an Interface, you could use an Abstract Base Class
> > > > (MustInherit).
> > > >
> > > > The Interface IClass2 can contain events in addition to Properties,
> > > > Functions & Subs.
> > > >
> > > > Also to elimate the coupling between Presentation & Data, I would[/color][/color][/color]
use[color=blue]
> a[color=green][color=darkred]
> > > > Proxy object for the EventArgs instead of actually copying the data.
> > > >
> > > > Something like:
> > > >
> > > > ' From Data layer
> > > > Public Class DataEventArgs
> > > > Inherits EventArgs
> > > >
> > > > Private Readonly m_amount As Integer
> > > >
> > > > Public Sub New(amount As Integer)
> > > > m_amount = amount
> > > > End Sub
> > > >
> > > > Public Readonly Property Amount As Integer
> > > > Get
> > > > Return m_amount
> > > > End Get
> > > > End Property
> > > >
> > > > End Class
> > > >
> > > > ' From Domain Layer
> > > >
> > > > Public Class DomainEventArgs
> > > > Inherits EventArgs
> > > >
> > > > Private Readonly m_dataEventArgs As DataEventArgs
> > > >
> > > > Public Sub New(dataEventArgs As DataEventArgs)
> > > > m_dataEventArgs = dataEventArgs
> > > > End Sub
> > > >
> > > > Public Readonly Property Amount As Integer
> > > > Get
> > > > Return m_DataEventArgs.Amount
> > > > End Get
> > > > End Property
> > > >
> > > > End Class
> > > >
> > > > Although the Domain layer duplicates all the properties, the data[/color][/color]
> itself[color=green][color=darkred]
> > > is
> > > > not duplicate or exposed, as the DomainEventArgs acts as a Proxy for[/color][/color]
> the[color=green][color=darkred]
> > > > DataEventArgs, delegating all the calls to the DataEventArgs...
> > > >
> > > > Hope this helps
> > > > Jay
> > > >
> > > > "Charles Law" <blank@nowhere.com> wrote in message
> > > > news:uDWqYJMSEHA.2704@TK2MSFTNGP10.phx.gbl...
> > > > > Hi Jay
> > > > >
> > > > > > I suspect most of the time the info that the domain layer needs[/color][/color][/color]
in[color=blue][color=green]
> > its[color=darkred]
> > > > > > events is going to be different then the info needed in the data
> > > layer's
> > > > > > events, so each would have its own event handlers...
> > > > >
> > > > > I agree that this the case most of the time, it's just that in my[/color][/color]
> case[color=green][color=darkred]
> > > it
> > > > > isn't. If I used different EventArgs classes I would just be[/color][/color]
> changing[color=green][color=darkred]
> > > the
> > > > > object for the sake of it. No information is added or omitted as[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > event
> > > > > passes up the layers.
> > > > >
> > > > > As I described in my response to Dan, I have a set of custom[/color][/color]
> controls[color=green][color=darkred]
> > > that
> > > > > raise and sink events. These are instantiated by the presentation[/color]
> > layer,[color=darkred]
> > > > but
> > > > > the command layer is where the corresponding events are sunk[/color][/color]
> (sinked?)[color=green][color=darkred]
> > > and
> > > > > raised. I have ended up with tighter coupling than the[/color][/color][/color]
compiler/IDE[color=blue]
> is[color=green][color=darkred]
> > > > > comfortable with, and I get random, erroneous build errors all the[/color]
> > time.[color=darkred]
> > > I
> > > > > have seen others post about this problem, and it comes and goes[/color][/color][/color]
for[color=blue][color=green]
> > me.[color=darkred]
> > > At
> > > > > the moment it has come, and I can't build my solution because I[/color][/color][/color]
get[color=blue][color=green][color=darkred]
> > > large
> > > > > numbers of spurious messages about handlers and events having[/color]
> > different[color=darkred]
> > > > > signatures, when they haven't. That's why I am trying to loosen[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > coupling
> > > > > so that I can just build the thing.
> > > > >
> > > > > Charles
> > > > >
> > > > >
> > > > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in
> > > message
> > > > > news:eVqENGLSEHA.3140@tk2msftngp13.phx.gbl...
> > > > > > Charles,
> > > > > > > The presentation layer is coupled to the business layer, and[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > > business
> > > > > > > layer is coupled to the data layer. So far so good.
> > > > > > Actually I normally couple the presentation layer to the domain[/color]
> > layer[color=darkred]
> > > > > > (business layer) and couple the data layer to the domain layer!
> > > > > >
> > > > > > See Martin Fowler's book "Patterns of Enterprise Application
> > > > Architecture"
> > > > > > from Addison Wesley
> > > > > > http://www.martinfowler.com/books.html#eaa. The sections on[/color][/color][/color]
Domain[color=blue][color=green][color=darkred]
> > > > Model,
> > > > > > Data Mapper, and Separated Interface discuss how to have the[/color][/color][/color]
data[color=blue][color=green][color=darkred]
> > > layer
> > > > > > reference the domain layer, instead of having the domain layer
> > > reference
> > > > > the
> > > > > > data layer. Having the data layer reference the domain layer,[/color][/color]
> allows[color=green][color=darkred]
> > > > > > replacing the data layer very easily! Also I find it provides[/color][/color]
> better[color=green][color=darkred]
> > > > > > separation (less coupling)...
> > > > > >
> > > > > > > Suppose the data layer raises an event, and it passes Me (the
> > > sender)
> > > > as
> > > > > > an
> > > > > > > object, and e (MyEventArgs, a descendent of EventArgs) to the[/color]
> > layer[color=darkred]
> > > > > above
> > > > > > In one of my projects that data layer has custom event handlers
> > > > > > (MyEventArgs, a descendent of EventArgs), while the domain layer
> > > simply
> > > > > uses
> > > > > > EventHandler & passes EventArgs.Empty. As I found that the[/color][/color][/color]
domain[color=blue][color=green][color=darkred]
> > > layer
> > > > > > needed to convey less information to the domain layer, then the[/color][/color]
> data[color=green][color=darkred]
> > > > layer
> > > > > > did to the domain layer.
> > > > > >
> > > > > > > We could define a business layer version of MyEventArgs -[/color][/color][/color]
which[color=blue]
> is[color=green][color=darkred]
> > > > > > actually
> > > > > > > identical to the one in the data layer - and copy each element[/color][/color]
> to[color=green][color=darkred]
> > > the
> > > > > new
> > > > > > > object before passing it on, but that is a lot of typing, and[/color][/color]
> now[color=green]
> > we[color=darkred]
> > > > > have
> > > > > > > duplication.
> > > > > > I suspect most of the time the info that the domain layer needs[/color][/color][/color]
in[color=blue][color=green]
> > its[color=darkred]
> > > > > > events is going to be different then the info needed in the data
> > > layer's
> > > > > > events, so each would have its own event handlers...
> > > > > >
> > > > > > Hope this helps
> > > > > > Jay
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Charles Law" <blank@nowhere.com> wrote in message
> > > > > > news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...
> > > > > > > Take a solution with a project hierarchy along the lines of an
> > > n-tier
> > > > > > > system, so that we have a data layer, business layer and
> > > presentation
> > > > > > layer.
> > > > > > > The presentation layer is coupled to the business layer, and[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > > business
> > > > > > > layer is coupled to the data layer. So far so good.
> > > > > > >
> > > > > > > Suppose the data layer raises an event, and it passes Me (the
> > > sender)
> > > > as
> > > > > > an
> > > > > > > object, and e (MyEventArgs, a descendent of EventArgs) to the[/color]
> > layer[color=darkred]
> > > > > above
> > > > > > > (the business layer). Suppose also that the business layer[/color][/color][/color]
needs[color=blue][color=green]
> > to[color=darkred]
> > > > pass
> > > > > > > this event on to the presentation layer. It sends Me as an[/color][/color]
> object,[color=green][color=darkred]
> > > but
> > > > > > what
> > > > > > > does it send e as? It can't send it as MyEventArgs because the
> > > > > > presentation
> > > > > > > layer knows nothing of such things. We could couple the[/color]
> > presentation[color=darkred]
> > > > > layer
> > > > > > > to the data layer, so that it knows what a MyEventArgs is, but
> > > surely
> > > > > that
> > > > > > > is a no-no.
> > > > > > >
> > > > > > > We could also remove the definition of MyEventArgs to another
> > > project
> > > > to
> > > > > > > which everything is coupled, but now this common project is in
> > > danger
> > > > of
> > > > > > > being an eclectic mix of stuff that is really specific to[/color]
> > individual[color=darkred]
> > > > > > > projects.
> > > > > > >
> > > > > > > We could define a business layer version of MyEventArgs -[/color][/color][/color]
which[color=blue]
> is[color=green][color=darkred]
> > > > > > actually
> > > > > > > identical to the one in the data layer - and copy each element[/color][/color]
> to[color=green][color=darkred]
> > > the
> > > > > new
> > > > > > > object before passing it on, but that is a lot of typing, and[/color][/color]
> now[color=green]
> > we[color=darkred]
> > > > > have
> > > > > > > duplication.
> > > > > > >
> > > > > > > I am interested to hear what other people do in this[/color][/color][/color]
situation.[color=blue][color=green][color=darkred]
> > > > > > >
> > > > > > > Charles
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

Aah. All I meant was that I wouldn't be able to write

Dim c1 As New IClass1

To instantiate I would need to have a reference to the 'assembly' (good,
eh?) containing Class1.

Yes, I would be interested to see an example of the Domain Model / Data
Mapper scenario, if it's not too much trouble.

Charles

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
news:%23r6qADXSEHA.4028@TK2MSFTNGP09.phx.gbl...[color=blue]
> Charles,
> Earlier in this thread you replied to solex with:[color=green]
> > Thanks for the time you have obviously spent understanding what I am[/color]
> trying[color=green]
> > to do. I have used interfaces, but what has stopped me going that extra[/color]
> bit[color=green]
> > further is the fact that I won't be able instantiate an interface. So, I
> > have settled with coupling to the library that contains the class[/color][/color]
itself.[color=blue]
>
> The "won't be able instantiate an interface" is the cause of my confusion
> (where I got the impression...).
>
> When I use the Separated Interface Pattern, I normally use the Plugin
> Pattern also.
> http://www.martinfowler.com/eaaCatal...Interface.html
> http://www.martinfowler.com/eaaCatalog/plugin.html
>
> I store the names of the classes that implements a specific interface in[/color]
the[color=blue]
> app.config file. I then use System.Activator.CreateInstance to create
> instances of these classes. Sometimes I simply pass the interface as a
> parameter as I show in my earlier post.
>
> For example in the Domain Model & Data Mapper scenario I mentioned[/color]
earlier,[color=blue]
> I have a custom configuration section in my app.config that identifies the
> data mapper class for a given domain class. In my framework assembly I[/color]
have[color=blue]
> a shared method that takes a domain object Type and looks up the[/color]
DataMapper[color=blue]
> type name in the app.config, uses Activator.CreateInstance to return an
> instance of the class that implements IDataMapper.
>
> I can post code samples this evening if you like.
>
> Hope this helps
> Jay
>
> "Charles Law" <blank@nowhere.com> wrote in message
> news:OPRh$1WSEHA.3140@tk2msftngp13.phx.gbl...[color=green]
> > Hi Jay
> >[color=darkred]
> > > I may have miss read one of your other posts, I got the impression you[/color][/color]
> did[color=green][color=darkred]
> > > not understand interfaces...[/color]
> >
> > Not me guv. You must have me mixed up with someone else; use 'em all the
> > time, I do ;-)
> >
> > Anyway, I take on board what you say. Thanks.
> >
> > Charles
> >
> >
> > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color][/color]
message[color=blue][color=green]
> > news:e7T7UhWSEHA.3728@TK2MSFTNGP11.phx.gbl...[color=darkred]
> > > Charles,
> > > > I don't have the Fowler book, but I can feel a purchase or two[/color][/color][/color]
coming[color=blue][color=green]
> > on.[color=darkred]
> > > I
> > > > have the GoF Design Patterns book, which does not mention the[/color][/color]
> Separated[color=green][color=darkred]
> > > > Interface Pattern as such; perhaps under a different name (?).
> > > Fowler's book takes off where the GoF book stops.
> > >
> > > > I have used interfaces in much the way you describe, so I am[/color][/color][/color]
reassured[color=blue][color=green]
> > in[color=darkred]
> > > > that respect.
> > > I may have miss read one of your other posts, I got the impression you[/color][/color]
> did[color=green][color=darkred]
> > > not understand interfaces...
> > >
> > > > With regard to the use of a proxy, it does save copying the data,[/color][/color][/color]
but[color=blue][color=green]
> > with[color=darkred]
> > > > around 50 events being bubbled, each with their own EventArgs class,[/color]
> > that[color=darkred]
> > > > still means another 50 proxy classes.
> > > It really comes down to: How much coupling are you willing to live[/color][/color][/color]
with![color=blue][color=green]
> > ;-)[color=darkred]
> > >
> > > The proxy allows you to avoid coupling, have fair performance, and[/color][/color]
> expose[color=green][color=darkred]
> > > all or most of the same properties in both events. At the expense of
> > > creating the proxy classes...
> > >
> > > > Just to clarify, you say 'assembly', I say 'project'. Are we talking[/color]
> > about[color=darkred]
> > > > the same thing?
> > > Yes
> > >
> > > Hope this helps
> > > Jay
> > >
> > >
> > > "Charles Law" <blank@nowhere.com> wrote in message
> > > news:uCm$ufVSEHA.2780@TK2MSFTNGP09.phx.gbl...
> > > > Hi Jay
> > > >
> > > > I don't have the Fowler book, but I can feel a purchase or two[/color][/color][/color]
coming[color=blue][color=green]
> > on.[color=darkred]
> > > I
> > > > have the GoF Design Patterns book, which does not mention the[/color][/color]
> Separated[color=green][color=darkred]
> > > > Interface Pattern as such; perhaps under a different name (?).
> > > >
> > > > I have used interfaces in much the way you describe, so I am[/color][/color][/color]
reassured[color=blue][color=green]
> > in[color=darkred]
> > > > that respect.
> > > >
> > > > With regard to the use of a proxy, it does save copying the data,[/color][/color][/color]
but[color=blue][color=green]
> > with[color=darkred]
> > > > around 50 events being bubbled, each with their own EventArgs class,[/color]
> > that[color=darkred]
> > > > still means another 50 proxy classes.
> > > >
> > > > Just to clarify, you say 'assembly', I say 'project'. Are we talking[/color]
> > about[color=darkred]
> > > > the same thing?
> > > >
> > > > Charles
> > > >
> > > >
> > > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in[/color]
> > message[color=darkred]
> > > > news:u1EuDoQSEHA.620@TK2MSFTNGP10.phx.gbl...
> > > > > Charles,
> > > > > It sounds like you really need to learn the Separated Interface[/color]
> > Pattern[color=darkred]
> > > > > (Martin Fowler's book).
> > > > >
> > > > > http://www.martinfowler.com/eaaCatal...Interface.html
> > > > >
> > > > > Define an Interface that Class1 uses that Class2 implements. Put[/color][/color]
> this[color=green][color=darkred]
> > > > > interface in the same assembly as Class1 (or a third assembly).[/color][/color][/color]
The[color=blue][color=green][color=darkred]
> > > Class1
> > > > > assembly needs to reference the assembly where the interface is[/color]
> > defined[color=darkred]
> > > if
> > > > > its not in the same assembly. The Class2 assembly needs to[/color][/color][/color]
reference[color=blue][color=green]
> > the[color=darkred]
> > > > > Class1 assembly & the assembly where the interface is defined.[/color][/color]
> Class2[color=green][color=darkred]
> > > can
> > > > > reference Class1 directly, while Class1 can only reference Class2[/color][/color]
> via[color=green][color=darkred]
> > > the
> > > > > interface that it implements.
> > > > >
> > > > > Something like:
> > > > > ' Assembly 1
> > > > > Public Interface IClass2
> > > > > Public Property Value1() As Integer
> > > > > Public Sub Method1()
> > > > > End Interface
> > > > >
> > > > > Public Class Class1
> > > > >
> > > > > Public Sub Test(ByVal object2 As IClass2)
> > > > > If object2.Value1 = 100 Then
> > > > > object2.Method1()
> > > > > End If
> > > > > End Sub
> > > > >
> > > > > End Class
> > > > >
> > > > > ' Assembly 2
> > > > > ' References Assembly 1
> > > > >
> > > > > Public Class Class2
> > > > > Implements IClass2
> > > > >
> > > > > Public Property Value1() As Integer Implements[/color][/color]
> IClass2.Value1[color=green][color=darkred]
> > > > > ...
> > > > >
> > > > > Public Sub Method1() Implements IClass2.Value1
> > > > > ...
> > > > >
> > > > > End Class
> > > > >
> > > > > Note instead of an Interface, you could use an Abstract Base Class
> > > > > (MustInherit).
> > > > >
> > > > > The Interface IClass2 can contain events in addition to[/color][/color][/color]
Properties,[color=blue][color=green][color=darkred]
> > > > > Functions & Subs.
> > > > >
> > > > > Also to elimate the coupling between Presentation & Data, I would[/color][/color]
> use[color=green]
> > a[color=darkred]
> > > > > Proxy object for the EventArgs instead of actually copying the[/color][/color][/color]
data.[color=blue][color=green][color=darkred]
> > > > >
> > > > > Something like:
> > > > >
> > > > > ' From Data layer
> > > > > Public Class DataEventArgs
> > > > > Inherits EventArgs
> > > > >
> > > > > Private Readonly m_amount As Integer
> > > > >
> > > > > Public Sub New(amount As Integer)
> > > > > m_amount = amount
> > > > > End Sub
> > > > >
> > > > > Public Readonly Property Amount As Integer
> > > > > Get
> > > > > Return m_amount
> > > > > End Get
> > > > > End Property
> > > > >
> > > > > End Class
> > > > >
> > > > > ' From Domain Layer
> > > > >
> > > > > Public Class DomainEventArgs
> > > > > Inherits EventArgs
> > > > >
> > > > > Private Readonly m_dataEventArgs As DataEventArgs
> > > > >
> > > > > Public Sub New(dataEventArgs As DataEventArgs)
> > > > > m_dataEventArgs = dataEventArgs
> > > > > End Sub
> > > > >
> > > > > Public Readonly Property Amount As Integer
> > > > > Get
> > > > > Return m_DataEventArgs.Amount
> > > > > End Get
> > > > > End Property
> > > > >
> > > > > End Class
> > > > >
> > > > > Although the Domain layer duplicates all the properties, the data[/color]
> > itself[color=darkred]
> > > > is
> > > > > not duplicate or exposed, as the DomainEventArgs acts as a Proxy[/color][/color][/color]
for[color=blue][color=green]
> > the[color=darkred]
> > > > > DataEventArgs, delegating all the calls to the DataEventArgs...
> > > > >
> > > > > Hope this helps
> > > > > Jay
> > > > >
> > > > > "Charles Law" <blank@nowhere.com> wrote in message
> > > > > news:uDWqYJMSEHA.2704@TK2MSFTNGP10.phx.gbl...
> > > > > > Hi Jay
> > > > > >
> > > > > > > I suspect most of the time the info that the domain layer[/color][/color][/color]
needs[color=blue]
> in[color=green][color=darkred]
> > > its
> > > > > > > events is going to be different then the info needed in the[/color][/color][/color]
data[color=blue][color=green][color=darkred]
> > > > layer's
> > > > > > > events, so each would have its own event handlers...
> > > > > >
> > > > > > I agree that this the case most of the time, it's just that in[/color][/color][/color]
my[color=blue][color=green]
> > case[color=darkred]
> > > > it
> > > > > > isn't. If I used different EventArgs classes I would just be[/color]
> > changing[color=darkred]
> > > > the
> > > > > > object for the sake of it. No information is added or omitted as[/color][/color]
> the[color=green][color=darkred]
> > > > event
> > > > > > passes up the layers.
> > > > > >
> > > > > > As I described in my response to Dan, I have a set of custom[/color]
> > controls[color=darkred]
> > > > that
> > > > > > raise and sink events. These are instantiated by the[/color][/color][/color]
presentation[color=blue][color=green][color=darkred]
> > > layer,
> > > > > but
> > > > > > the command layer is where the corresponding events are sunk[/color]
> > (sinked?)[color=darkred]
> > > > and
> > > > > > raised. I have ended up with tighter coupling than the[/color][/color]
> compiler/IDE[color=green]
> > is[color=darkred]
> > > > > > comfortable with, and I get random, erroneous build errors all[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > time.
> > > > I
> > > > > > have seen others post about this problem, and it comes and goes[/color][/color]
> for[color=green][color=darkred]
> > > me.
> > > > At
> > > > > > the moment it has come, and I can't build my solution because I[/color][/color]
> get[color=green][color=darkred]
> > > > large
> > > > > > numbers of spurious messages about handlers and events having
> > > different
> > > > > > signatures, when they haven't. That's why I am trying to loosen[/color][/color]
> the[color=green][color=darkred]
> > > > > coupling
> > > > > > so that I can just build the thing.
> > > > > >
> > > > > > Charles
> > > > > >
> > > > > >
> > > > > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote[/color][/color][/color]
in[color=blue][color=green][color=darkred]
> > > > message
> > > > > > news:eVqENGLSEHA.3140@tk2msftngp13.phx.gbl...
> > > > > > > Charles,
> > > > > > > > The presentation layer is coupled to the business layer, and[/color][/color]
> the[color=green][color=darkred]
> > > > > > business
> > > > > > > > layer is coupled to the data layer. So far so good.
> > > > > > > Actually I normally couple the presentation layer to the[/color][/color][/color]
domain[color=blue][color=green][color=darkred]
> > > layer
> > > > > > > (business layer) and couple the data layer to the domain[/color][/color][/color]
layer![color=blue][color=green][color=darkred]
> > > > > > >
> > > > > > > See Martin Fowler's book "Patterns of Enterprise Application
> > > > > Architecture"
> > > > > > > from Addison Wesley
> > > > > > > http://www.martinfowler.com/books.html#eaa. The sections on[/color][/color]
> Domain[color=green][color=darkred]
> > > > > Model,
> > > > > > > Data Mapper, and Separated Interface discuss how to have the[/color][/color]
> data[color=green][color=darkred]
> > > > layer
> > > > > > > reference the domain layer, instead of having the domain layer
> > > > reference
> > > > > > the
> > > > > > > data layer. Having the data layer reference the domain layer,[/color]
> > allows[color=darkred]
> > > > > > > replacing the data layer very easily! Also I find it provides[/color]
> > better[color=darkred]
> > > > > > > separation (less coupling)...
> > > > > > >
> > > > > > > > Suppose the data layer raises an event, and it passes Me[/color][/color][/color]
(the[color=blue][color=green][color=darkred]
> > > > sender)
> > > > > as
> > > > > > > an
> > > > > > > > object, and e (MyEventArgs, a descendent of EventArgs) to[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > layer
> > > > > > above
> > > > > > > In one of my projects that data layer has custom event[/color][/color][/color]
handlers[color=blue][color=green][color=darkred]
> > > > > > > (MyEventArgs, a descendent of EventArgs), while the domain[/color][/color][/color]
layer[color=blue][color=green][color=darkred]
> > > > simply
> > > > > > uses
> > > > > > > EventHandler & passes EventArgs.Empty. As I found that the[/color][/color]
> domain[color=green][color=darkred]
> > > > layer
> > > > > > > needed to convey less information to the domain layer, then[/color][/color][/color]
the[color=blue][color=green]
> > data[color=darkred]
> > > > > layer
> > > > > > > did to the domain layer.
> > > > > > >
> > > > > > > > We could define a business layer version of MyEventArgs -[/color][/color]
> which[color=green]
> > is[color=darkred]
> > > > > > > actually
> > > > > > > > identical to the one in the data layer - and copy each[/color][/color][/color]
element[color=blue][color=green]
> > to[color=darkred]
> > > > the
> > > > > > new
> > > > > > > > object before passing it on, but that is a lot of typing,[/color][/color][/color]
and[color=blue][color=green]
> > now[color=darkred]
> > > we
> > > > > > have
> > > > > > > > duplication.
> > > > > > > I suspect most of the time the info that the domain layer[/color][/color][/color]
needs[color=blue]
> in[color=green][color=darkred]
> > > its
> > > > > > > events is going to be different then the info needed in the[/color][/color][/color]
data[color=blue][color=green][color=darkred]
> > > > layer's
> > > > > > > events, so each would have its own event handlers...
> > > > > > >
> > > > > > > Hope this helps
> > > > > > > Jay
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > "Charles Law" <blank@nowhere.com> wrote in message
> > > > > > > news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...
> > > > > > > > Take a solution with a project hierarchy along the lines of[/color][/color][/color]
an[color=blue][color=green][color=darkred]
> > > > n-tier
> > > > > > > > system, so that we have a data layer, business layer and
> > > > presentation
> > > > > > > layer.
> > > > > > > > The presentation layer is coupled to the business layer, and[/color][/color]
> the[color=green][color=darkred]
> > > > > > business
> > > > > > > > layer is coupled to the data layer. So far so good.
> > > > > > > >
> > > > > > > > Suppose the data layer raises an event, and it passes Me[/color][/color][/color]
(the[color=blue][color=green][color=darkred]
> > > > sender)
> > > > > as
> > > > > > > an
> > > > > > > > object, and e (MyEventArgs, a descendent of EventArgs) to[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > layer
> > > > > > above
> > > > > > > > (the business layer). Suppose also that the business layer[/color][/color]
> needs[color=green][color=darkred]
> > > to
> > > > > pass
> > > > > > > > this event on to the presentation layer. It sends Me as an[/color]
> > object,[color=darkred]
> > > > but
> > > > > > > what
> > > > > > > > does it send e as? It can't send it as MyEventArgs because[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > > > > presentation
> > > > > > > > layer knows nothing of such things. We could couple the
> > > presentation
> > > > > > layer
> > > > > > > > to the data layer, so that it knows what a MyEventArgs is,[/color][/color][/color]
but[color=blue][color=green][color=darkred]
> > > > surely
> > > > > > that
> > > > > > > > is a no-no.
> > > > > > > >
> > > > > > > > We could also remove the definition of MyEventArgs to[/color][/color][/color]
another[color=blue][color=green][color=darkred]
> > > > project
> > > > > to
> > > > > > > > which everything is coupled, but now this common project is[/color][/color][/color]
in[color=blue][color=green][color=darkred]
> > > > danger
> > > > > of
> > > > > > > > being an eclectic mix of stuff that is really specific to
> > > individual
> > > > > > > > projects.
> > > > > > > >
> > > > > > > > We could define a business layer version of MyEventArgs -[/color][/color]
> which[color=green]
> > is[color=darkred]
> > > > > > > actually
> > > > > > > > identical to the one in the data layer - and copy each[/color][/color][/color]
element[color=blue][color=green]
> > to[color=darkred]
> > > > the
> > > > > > new
> > > > > > > > object before passing it on, but that is a lot of typing,[/color][/color][/color]
and[color=blue][color=green]
> > now[color=darkred]
> > > we
> > > > > > have
> > > > > > > > duplication.
> > > > > > > >
> > > > > > > > I am interested to hear what other people do in this[/color][/color]
> situation.[color=green][color=darkred]
> > > > > > > >
> > > > > > > > Charles
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

Charles,

Not sure if this was a mistype on your last post but you cannot instantiate
an interface.

I have found the following book (in addition to Fowlers) to be useful in
explaing how to decouple objects using interfaces:
http://www.amazon.com/exec/obidos/tg...roduct-details

Also check out the comp.object news group.

Regards,
Dan

"Charles Law" <blank@nowhere.com> wrote in message
news:O73oI5OSEHA.3420@TK2MSFTNGP11.phx.gbl...[color=blue]
> Hi Dan
>
> Thanks for the time you have obviously spent understanding what I am[/color]
trying[color=blue]
> to do. I have used interfaces, but what has stopped me going that extra[/color]
bit[color=blue]
> further is the fact that I won't be able instantiate an interface. So, I
> have settled with coupling to the library that contains the class itself.
>
> I like the look of this INotify interface though. The name is suggestive[/color]
of[color=blue]
> the sort of thing I should be doing, so I am going to look into it further
> and then let it sink in.
>
> Thanks again.
>
> Charles
>
>
> "solex" <solex@nowhere.com> wrote in message
> news:uJ4BfaNSEHA.1208@TK2MSFTNGP09.phx.gbl...[color=green]
> > Charles,
> >
> > I do a simlar thing but without events and do not have a problem. It[/color]
> sounds[color=green]
> > to me like you need to start defining some interfaces and remove the[/color]
> events.[color=green]
> > Doing this should remove some of you coupling problems and perhaps[/color]
> increase[color=green]
> > your performance.
> >
> > Indicator control supports INotify interface
> >
> > Your presentation layer instantiates
> > (1) the indicator control
> > (2) the command layer.
> > (3) initialzes the command layer with the already instantiated[/color]
> indicator[color=green]
> > control(s) using the INotify interface
> >
> > As the command layer as you say "gets data back from the comms layer"
> > instead of raising events it could loop through a set of registered[/color]
> objects[color=green]
> > supporting the INotify interface and call an appropriate method.
> >
> > In this pattern, the indicator control knows nothing about your[/color]
> presentation[color=green]
> > layer, command layer or communication layer. The coupling looks[/color][/color]
something[color=blue][color=green]
> > like this (where -> means "knows" or "is coupled to")
> >
> > Presentation -> Indicator
> > Presentation -> Command
> > Presentation -> INotify
> >
> > Indicator -> INotify
> >
> > Command -> INotify
> > Command -> Comms
> >
> > Dan
> >
> > "Charles Law" <blank@nowhere.com> wrote in message
> > news:%23sYfCTLSEHA.2216@TK2MSFTNGP12.phx.gbl...[color=darkred]
> > > Hi Dan
> > >
> > > I used the 3-tier example because it is a particularly familiar one.[/color][/color][/color]
My[color=blue][color=green][color=darkred]
> > > scenario has a presentation layer on top of a command layer, on top of[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> > > communications layer, but with other bits on the side. It's a bit hard[/color][/color]
> to[color=green][color=darkred]
> > > describe really.
> > >
> > > The presentation layer has view windows containing indicator controls.[/color]
> > These[color=darkred]
> > > controls are held in a library project. The presentation layer is
> > > responsible for instantiating these controls in a view window.
> > >
> > > The command layer gets data back from the comms layer and raises[/color][/color][/color]
events[color=blue][color=green][color=darkred]
> > > based on the information. These events are handled by the indicators,[/color]
> > which,[color=darkred]
> > > whilst being instantiated at the presentation layer are contained in[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > library, so that is where the events are handled. What this means is[/color][/color]
> that[color=green][color=darkred]
> > > the library is coupled to both the presentation layer and the command[/color]
> > layer,[color=darkred]
> > > and the presentation layer is coupled to the command layer. This[/color][/color][/color]
doesn't[color=blue][color=green][color=darkred]
> > > quite create a circular reference, but it does cause the .NET[/color][/color]
> IDE/compiler[color=green][color=darkred]
> > > immense problems when building.
> > >
> > > So, my reason for asking the question has other implications in that[/color][/color][/color]
if[color=blue]
> I[color=green][color=darkred]
> > > can reduce the coupling I will actually be solving my build problems.
> > >
> > > Charles
> > >
> > >
> > > "solex" <solex@nowhere.com> wrote in message
> > > news:eq3sAnKSEHA.1312@TK2MSFTNGP12.phx.gbl...
> > > > Charles,
> > > >
> > > > Rather then talking in the abstract what specifically does the
> > > presentation
> > > > layer need to react to in conjunction with the data layer?
> > > >
> > > > Dan
> > > >
> > > > "Charles Law" <blank@nowhere.com> wrote in message
> > > > news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...
> > > > > Take a solution with a project hierarchy along the lines of an[/color][/color]
> n-tier[color=green][color=darkred]
> > > > > system, so that we have a data layer, business layer and[/color][/color]
> presentation[color=green][color=darkred]
> > > > layer.
> > > > > The presentation layer is coupled to the business layer, and the
> > > business
> > > > > layer is coupled to the data layer. So far so good.
> > > > >
> > > > > Suppose the data layer raises an event, and it passes Me (the[/color][/color]
> sender)[color=green]
> > as[color=darkred]
> > > > an
> > > > > object, and e (MyEventArgs, a descendent of EventArgs) to the[/color][/color][/color]
layer[color=blue][color=green][color=darkred]
> > > above
> > > > > (the business layer). Suppose also that the business layer needs[/color][/color][/color]
to[color=blue][color=green]
> > pass[color=darkred]
> > > > > this event on to the presentation layer. It sends Me as an object,[/color][/color]
> but[color=green][color=darkred]
> > > > what
> > > > > does it send e as? It can't send it as MyEventArgs because the
> > > > presentation
> > > > > layer knows nothing of such things. We could couple the[/color][/color][/color]
presentation[color=blue][color=green][color=darkred]
> > > layer
> > > > > to the data layer, so that it knows what a MyEventArgs is, but[/color][/color]
> surely[color=green][color=darkred]
> > > that
> > > > > is a no-no.
> > > > >
> > > > > We could also remove the definition of MyEventArgs to another[/color][/color]
> project[color=green]
> > to[color=darkred]
> > > > > which everything is coupled, but now this common project is in[/color][/color]
> danger[color=green]
> > of[color=darkred]
> > > > > being an eclectic mix of stuff that is really specific to[/color][/color][/color]
individual[color=blue][color=green][color=darkred]
> > > > > projects.
> > > > >
> > > > > We could define a business layer version of MyEventArgs - which is
> > > > actually
> > > > > identical to the one in the data layer - and copy each element to[/color][/color]
> the[color=green][color=darkred]
> > > new
> > > > > object before passing it on, but that is a lot of typing, and now[/color][/color][/color]
we[color=blue][color=green][color=darkred]
> > > have
> > > > > duplication.
> > > > >
> > > > > I am interested to hear what other people do in this situation.
> > > > >
> > > > > Charles
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

Hi Dan

Thanks for the reference. I'm not sure which bit I mis-typed:
[color=blue][color=green]
> > to do. I have used interfaces, but what has stopped me going that extra
> > bit further is the fact that I won't be able [to] instantiate an[/color][/color]
interface. So, I[color=blue][color=green]
> > have settled with coupling to the library that contains the class[/color][/color]
itself.

apart from missing out the word 'to'.

Charles

"solex" <solex@nowhere.com> wrote in message
news:u0NIMOXSEHA.1368@TK2MSFTNGP11.phx.gbl...[color=blue]
> Charles,
>
> Not sure if this was a mistype on your last post but you cannot[/color]
instantiate[color=blue]
> an interface.
>
> I have found the following book (in addition to Fowlers) to be useful in
> explaing how to decouple objects using interfaces:
>[/color]
http://www.amazon.com/exec/obidos/tg...roduct-details[color=blue]
>
> Also check out the comp.object news group.
>
> Regards,
> Dan
>
>
>
>
> "Charles Law" <blank@nowhere.com> wrote in message
> news:O73oI5OSEHA.3420@TK2MSFTNGP11.phx.gbl...[color=green]
> > Hi Dan
> >
> > Thanks for the time you have obviously spent understanding what I am[/color]
> trying[color=green]
> > to do. I have used interfaces, but what has stopped me going that extra[/color]
> bit[color=green]
> > further is the fact that I won't be able instantiate an interface. So, I
> > have settled with coupling to the library that contains the class[/color][/color]
itself.[color=blue][color=green]
> >
> > I like the look of this INotify interface though. The name is suggestive[/color]
> of[color=green]
> > the sort of thing I should be doing, so I am going to look into it[/color][/color]
further[color=blue][color=green]
> > and then let it sink in.
> >
> > Thanks again.
> >
> > Charles
> >
> >
> > "solex" <solex@nowhere.com> wrote in message
> > news:uJ4BfaNSEHA.1208@TK2MSFTNGP09.phx.gbl...[color=darkred]
> > > Charles,
> > >
> > > I do a simlar thing but without events and do not have a problem. It[/color]
> > sounds[color=darkred]
> > > to me like you need to start defining some interfaces and remove the[/color]
> > events.[color=darkred]
> > > Doing this should remove some of you coupling problems and perhaps[/color]
> > increase[color=darkred]
> > > your performance.
> > >
> > > Indicator control supports INotify interface
> > >
> > > Your presentation layer instantiates
> > > (1) the indicator control
> > > (2) the command layer.
> > > (3) initialzes the command layer with the already instantiated[/color]
> > indicator[color=darkred]
> > > control(s) using the INotify interface
> > >
> > > As the command layer as you say "gets data back from the comms layer"
> > > instead of raising events it could loop through a set of registered[/color]
> > objects[color=darkred]
> > > supporting the INotify interface and call an appropriate method.
> > >
> > > In this pattern, the indicator control knows nothing about your[/color]
> > presentation[color=darkred]
> > > layer, command layer or communication layer. The coupling looks[/color][/color]
> something[color=green][color=darkred]
> > > like this (where -> means "knows" or "is coupled to")
> > >
> > > Presentation -> Indicator
> > > Presentation -> Command
> > > Presentation -> INotify
> > >
> > > Indicator -> INotify
> > >
> > > Command -> INotify
> > > Command -> Comms
> > >
> > > Dan
> > >
> > > "Charles Law" <blank@nowhere.com> wrote in message
> > > news:%23sYfCTLSEHA.2216@TK2MSFTNGP12.phx.gbl...
> > > > Hi Dan
> > > >
> > > > I used the 3-tier example because it is a particularly familiar one.[/color][/color]
> My[color=green][color=darkred]
> > > > scenario has a presentation layer on top of a command layer, on top[/color][/color][/color]
of[color=blue]
> a[color=green][color=darkred]
> > > > communications layer, but with other bits on the side. It's a bit[/color][/color][/color]
hard[color=blue][color=green]
> > to[color=darkred]
> > > > describe really.
> > > >
> > > > The presentation layer has view windows containing indicator[/color][/color][/color]
controls.[color=blue][color=green][color=darkred]
> > > These
> > > > controls are held in a library project. The presentation layer is
> > > > responsible for instantiating these controls in a view window.
> > > >
> > > > The command layer gets data back from the comms layer and raises[/color][/color]
> events[color=green][color=darkred]
> > > > based on the information. These events are handled by the[/color][/color][/color]
indicators,[color=blue][color=green][color=darkred]
> > > which,
> > > > whilst being instantiated at the presentation layer are contained in[/color][/color]
> the[color=green][color=darkred]
> > > > library, so that is where the events are handled. What this means is[/color]
> > that[color=darkred]
> > > > the library is coupled to both the presentation layer and the[/color][/color][/color]
command[color=blue][color=green][color=darkred]
> > > layer,
> > > > and the presentation layer is coupled to the command layer. This[/color][/color]
> doesn't[color=green][color=darkred]
> > > > quite create a circular reference, but it does cause the .NET[/color]
> > IDE/compiler[color=darkred]
> > > > immense problems when building.
> > > >
> > > > So, my reason for asking the question has other implications in that[/color][/color]
> if[color=green]
> > I[color=darkred]
> > > > can reduce the coupling I will actually be solving my build[/color][/color][/color]
problems.[color=blue][color=green][color=darkred]
> > > >
> > > > Charles
> > > >
> > > >
> > > > "solex" <solex@nowhere.com> wrote in message
> > > > news:eq3sAnKSEHA.1312@TK2MSFTNGP12.phx.gbl...
> > > > > Charles,
> > > > >
> > > > > Rather then talking in the abstract what specifically does the
> > > > presentation
> > > > > layer need to react to in conjunction with the data layer?
> > > > >
> > > > > Dan
> > > > >
> > > > > "Charles Law" <blank@nowhere.com> wrote in message
> > > > > news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...
> > > > > > Take a solution with a project hierarchy along the lines of an[/color]
> > n-tier[color=darkred]
> > > > > > system, so that we have a data layer, business layer and[/color]
> > presentation[color=darkred]
> > > > > layer.
> > > > > > The presentation layer is coupled to the business layer, and the
> > > > business
> > > > > > layer is coupled to the data layer. So far so good.
> > > > > >
> > > > > > Suppose the data layer raises an event, and it passes Me (the[/color]
> > sender)[color=darkred]
> > > as
> > > > > an
> > > > > > object, and e (MyEventArgs, a descendent of EventArgs) to the[/color][/color]
> layer[color=green][color=darkred]
> > > > above
> > > > > > (the business layer). Suppose also that the business layer needs[/color][/color]
> to[color=green][color=darkred]
> > > pass
> > > > > > this event on to the presentation layer. It sends Me as an[/color][/color][/color]
object,[color=blue][color=green]
> > but[color=darkred]
> > > > > what
> > > > > > does it send e as? It can't send it as MyEventArgs because the
> > > > > presentation
> > > > > > layer knows nothing of such things. We could couple the[/color][/color]
> presentation[color=green][color=darkred]
> > > > layer
> > > > > > to the data layer, so that it knows what a MyEventArgs is, but[/color]
> > surely[color=darkred]
> > > > that
> > > > > > is a no-no.
> > > > > >
> > > > > > We could also remove the definition of MyEventArgs to another[/color]
> > project[color=darkred]
> > > to
> > > > > > which everything is coupled, but now this common project is in[/color]
> > danger[color=darkred]
> > > of
> > > > > > being an eclectic mix of stuff that is really specific to[/color][/color]
> individual[color=green][color=darkred]
> > > > > > projects.
> > > > > >
> > > > > > We could define a business layer version of MyEventArgs - which[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> > > > > actually
> > > > > > identical to the one in the data layer - and copy each element[/color][/color][/color]
to[color=blue][color=green]
> > the[color=darkred]
> > > > new
> > > > > > object before passing it on, but that is a lot of typing, and[/color][/color][/color]
now[color=blue]
> we[color=green][color=darkred]
> > > > have
> > > > > > duplication.
> > > > > >
> > > > > > I am interested to hear what other people do in this situation.
> > > > > >
> > > > > > Charles
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

Charles,[color=blue]
> Dim c1 As New IClass1[/color]
You would need to instantiate a class that implements the interface, you can
use Activator.CreateInstance to avoid directly coupling to the assembly
where class is. You would still need to couple to the assembly where the
interface is.
[color=blue]
> Yes, I would be interested to see an example of the Domain Model / Data
> Mapper scenario, if it's not too much trouble.[/color]

This is a partial implementation of the Domain Model pattern along with the
DataMapper pattern & Finder "pattern" from Fowlers book. It should be enough
to get you started.

' within MyApp.Framework.dll

Public Interface IDataMapper
Sub Insert(ByVal obj As IDomainObject)
...
End Interface

Public NotInheritable Class UnitOfWork

Public Shared Function GetDataMapper(ByVal domainType As Type) As
IDataMapper
Dim dataMappers As Hashtable =
DirectCast(System.Configuration.ConfigurationSetti ngs.GetConfig("dataMappers
"), Hashtable)
Dim typeName As String =
DirectCast(dataMappers(domainType.Name), String)
Dim mapperType As Type = Type.GetType(typeName)
Dim mapper As IDataMapper =
DirectCast(Activator.CreateInstance(mapperType), IDataMapper)
Return mapper
End Function

...

End Class

Public Class DataMapperSectionHandler
Inherits System.Configuration.DictionarySectionHandler

Protected Overrides Readonly Property KeyAttributeName() As String
Get
Return "name"
End Get
End Property

Protected Overrides Readonly Property ValueAttributeName() As String
Get
Return "dataMapper"
End Get
End Property

End Class

' within MyApp.Data.dll
' References MyApp.Framework.dll
' References MyApp.Domain.dll

Public Class PublisherMapper
Implements IDataMapper
Implements IPublisherFinder

Public Sub Insert(ByVal obj As IDomainObject) Implements
IDataMapper.Insert
End Sub

...

Public Function FindById(ByVal id As Integer) As Publisher
Implements IPublisherFinder.FindById
' do lookup of id
Return New Publisher(id, name, address, ...)
End Class

' within MyApp.Domain.dll
' References MyApp.Framework.dll

Public Interface IPublisherFinder
Function FindById(ByVal id As Integer) As Publisher
Function FindByName(ByVal name As String) As Publisher
End Interface

Public Class Publisher

Public Shared Readonly Property Mapper() As IDataMapper
Get
Dim mapper As IDataMapper
mapper = UnitOfWork.GetDataMapper(GetType(Publisher)
Return mapper
End Get
End Property

Public Shared Readonly Property Finder() As IPublisherFinder
Get
Dim mapper As IDataMapper
mapper = UnitOfWork.GetDataMapper(GetType(Publisher)
Return DirectCast(mapper, IPublisherFinder)
End Get
End Property

End Class

' within app.config or web.config depending on main.exe

<configuration>
<configSections>
<section name="dataMappers"
type="Myapp.Framework.DataMappersSectionHanlder, MyApp.Framework" />
</configSections>
<dataMappers>
<add name="Publisher" dataMapper="MyApp.Data.PublisherMapper,
MyApp.Data" />
...
</dataMappers>
</configuration>

Hopefully I included enough for you to get the full jest of it! ;-)

Hope this helps
Jay

"Charles Law" <blank@nowhere.com> wrote in message
news:%2341E9JXSEHA.3552@TK2MSFTNGP09.phx.gbl...[color=blue]
> Aah. All I meant was that I wouldn't be able to write
>
> Dim c1 As New IClass1
>
> To instantiate I would need to have a reference to the 'assembly' (good,
> eh?) containing Class1.
>
> Yes, I would be interested to see an example of the Domain Model / Data
> Mapper scenario, if it's not too much trouble.
>
> Charles
>[/color]
<<snip>>

Thanks Jay. That looks great. I will inwardly digest it.

Charles

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
news:OyT65gjSEHA.2480@TK2MSFTNGP10.phx.gbl...[color=blue]
> Charles,[color=green]
> > Dim c1 As New IClass1[/color]
> You would need to instantiate a class that implements the interface, you[/color]
can[color=blue]
> use Activator.CreateInstance to avoid directly coupling to the assembly
> where class is. You would still need to couple to the assembly where the
> interface is.
>[color=green]
> > Yes, I would be interested to see an example of the Domain Model / Data
> > Mapper scenario, if it's not too much trouble.[/color]
>
> This is a partial implementation of the Domain Model pattern along with[/color]
the[color=blue]
> DataMapper pattern & Finder "pattern" from Fowlers book. It should be[/color]
enough[color=blue]
> to get you started.
>
> ' within MyApp.Framework.dll
>
> Public Interface IDataMapper
> Sub Insert(ByVal obj As IDomainObject)
> ...
> End Interface
>
> Public NotInheritable Class UnitOfWork
>
> Public Shared Function GetDataMapper(ByVal domainType As Type) As
> IDataMapper
> Dim dataMappers As Hashtable =
>[/color]
DirectCast(System.Configuration.ConfigurationSetti ngs.GetConfig("dataMappers[color=blue]
> "), Hashtable)
> Dim typeName As String =
> DirectCast(dataMappers(domainType.Name), String)
> Dim mapperType As Type = Type.GetType(typeName)
> Dim mapper As IDataMapper =
> DirectCast(Activator.CreateInstance(mapperType), IDataMapper)
> Return mapper
> End Function
>
> ...
>
> End Class
>
> Public Class DataMapperSectionHandler
> Inherits System.Configuration.DictionarySectionHandler
>
> Protected Overrides Readonly Property KeyAttributeName() As String
> Get
> Return "name"
> End Get
> End Property
>
> Protected Overrides Readonly Property ValueAttributeName() As[/color]
String[color=blue]
> Get
> Return "dataMapper"
> End Get
> End Property
>
> End Class
>
> ' within MyApp.Data.dll
> ' References MyApp.Framework.dll
> ' References MyApp.Domain.dll
>
> Public Class PublisherMapper
> Implements IDataMapper
> Implements IPublisherFinder
>
> Public Sub Insert(ByVal obj As IDomainObject) Implements
> IDataMapper.Insert
> End Sub
>
> ...
>
> Public Function FindById(ByVal id As Integer) As Publisher
> Implements IPublisherFinder.FindById
> ' do lookup of id
> Return New Publisher(id, name, address, ...)
> End Class
>
> ' within MyApp.Domain.dll
> ' References MyApp.Framework.dll
>
> Public Interface IPublisherFinder
> Function FindById(ByVal id As Integer) As Publisher
> Function FindByName(ByVal name As String) As Publisher
> End Interface
>
> Public Class Publisher
>
> Public Shared Readonly Property Mapper() As IDataMapper
> Get
> Dim mapper As IDataMapper
> mapper = UnitOfWork.GetDataMapper(GetType(Publisher)
> Return mapper
> End Get
> End Property
>
> Public Shared Readonly Property Finder() As IPublisherFinder
> Get
> Dim mapper As IDataMapper
> mapper = UnitOfWork.GetDataMapper(GetType(Publisher)
> Return DirectCast(mapper, IPublisherFinder)
> End Get
> End Property
>
> End Class
>
> ' within app.config or web.config depending on main.exe
>
> <configuration>
> <configSections>
> <section name="dataMappers"
> type="Myapp.Framework.DataMappersSectionHanlder, MyApp.Framework" />
> </configSections>
> <dataMappers>
> <add name="Publisher" dataMapper="MyApp.Data.PublisherMapper,
> MyApp.Data" />
> ...
> </dataMappers>
> </configuration>
>
> Hopefully I included enough for you to get the full jest of it! ;-)
>
> Hope this helps
> Jay
>
> "Charles Law" <blank@nowhere.com> wrote in message
> news:%2341E9JXSEHA.3552@TK2MSFTNGP09.phx.gbl...[color=green]
> > Aah. All I meant was that I wouldn't be able to write
> >
> > Dim c1 As New IClass1
> >
> > To instantiate I would need to have a reference to the 'assembly' (good,
> > eh?) containing Class1.
> >
> > Yes, I would be interested to see an example of the Domain Model / Data
> > Mapper scenario, if it's not too much trouble.
> >
> > Charles
> >[/color]
> <<snip>>
>
>[/color]

Charles,
Oh! Making Finder a shared property of the Publisher class allows:

Dim aPublisher As Publisher = Publisher.Finder.FindById(100)

When I first starting reading/thinking about the Finder pattern, I wanted to
make each of the IFinder methods as shared on the Domain object, but was
thinking that would be too much work ;-)

Of course you can adopt names to fit your style...

Hope this helps
Jay

"Charles Law" <blank@nowhere.com> wrote in message
news:evVBgojSEHA.3728@TK2MSFTNGP11.phx.gbl...[color=blue]
> Thanks Jay. That looks great. I will inwardly digest it.
>
> Charles
>
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
> news:OyT65gjSEHA.2480@TK2MSFTNGP10.phx.gbl...[color=green]
> > Charles,[color=darkred]
> > > Dim c1 As New IClass1[/color]
> > You would need to instantiate a class that implements the interface, you[/color]
> can[color=green]
> > use Activator.CreateInstance to avoid directly coupling to the assembly
> > where class is. You would still need to couple to the assembly where the
> > interface is.
> >[color=darkred]
> > > Yes, I would be interested to see an example of the Domain Model /[/color][/color][/color]
Data[color=blue][color=green][color=darkred]
> > > Mapper scenario, if it's not too much trouble.[/color]
> >
> > This is a partial implementation of the Domain Model pattern along with[/color]
> the[color=green]
> > DataMapper pattern & Finder "pattern" from Fowlers book. It should be[/color]
> enough[color=green]
> > to get you started.
> >
> > ' within MyApp.Framework.dll
> >
> > Public Interface IDataMapper
> > Sub Insert(ByVal obj As IDomainObject)
> > ...
> > End Interface
> >
> > Public NotInheritable Class UnitOfWork
> >
> > Public Shared Function GetDataMapper(ByVal domainType As Type)[/color][/color]
As[color=blue][color=green]
> > IDataMapper
> > Dim dataMappers As Hashtable =
> >[/color]
>[/color]
DirectCast(System.Configuration.ConfigurationSetti ngs.GetConfig("dataMappers[color=blue][color=green]
> > "), Hashtable)
> > Dim typeName As String =
> > DirectCast(dataMappers(domainType.Name), String)
> > Dim mapperType As Type = Type.GetType(typeName)
> > Dim mapper As IDataMapper =
> > DirectCast(Activator.CreateInstance(mapperType), IDataMapper)
> > Return mapper
> > End Function
> >
> > ...
> >
> > End Class
> >
> > Public Class DataMapperSectionHandler
> > Inherits System.Configuration.DictionarySectionHandler
> >
> > Protected Overrides Readonly Property KeyAttributeName() As[/color][/color]
String[color=blue][color=green]
> > Get
> > Return "name"
> > End Get
> > End Property
> >
> > Protected Overrides Readonly Property ValueAttributeName() As[/color]
> String[color=green]
> > Get
> > Return "dataMapper"
> > End Get
> > End Property
> >
> > End Class
> >
> > ' within MyApp.Data.dll
> > ' References MyApp.Framework.dll
> > ' References MyApp.Domain.dll
> >
> > Public Class PublisherMapper
> > Implements IDataMapper
> > Implements IPublisherFinder
> >
> > Public Sub Insert(ByVal obj As IDomainObject) Implements
> > IDataMapper.Insert
> > End Sub
> >
> > ...
> >
> > Public Function FindById(ByVal id As Integer) As Publisher
> > Implements IPublisherFinder.FindById
> > ' do lookup of id
> > Return New Publisher(id, name, address, ...)
> > End Class
> >
> > ' within MyApp.Domain.dll
> > ' References MyApp.Framework.dll
> >
> > Public Interface IPublisherFinder
> > Function FindById(ByVal id As Integer) As Publisher
> > Function FindByName(ByVal name As String) As Publisher
> > End Interface
> >
> > Public Class Publisher
> >
> > Public Shared Readonly Property Mapper() As IDataMapper
> > Get
> > Dim mapper As IDataMapper
> > mapper = UnitOfWork.GetDataMapper(GetType(Publisher)
> > Return mapper
> > End Get
> > End Property
> >
> > Public Shared Readonly Property Finder() As IPublisherFinder
> > Get
> > Dim mapper As IDataMapper
> > mapper = UnitOfWork.GetDataMapper(GetType(Publisher)
> > Return DirectCast(mapper, IPublisherFinder)
> > End Get
> > End Property
> >
> > End Class
> >
> > ' within app.config or web.config depending on main.exe
> >
> > <configuration>
> > <configSections>
> > <section name="dataMappers"
> > type="Myapp.Framework.DataMappersSectionHanlder, MyApp.Framework" />
> > </configSections>
> > <dataMappers>
> > <add name="Publisher"[/color][/color]
dataMapper="MyApp.Data.PublisherMapper,[color=blue][color=green]
> > MyApp.Data" />
> > ...
> > </dataMappers>
> > </configuration>
> >
> > Hopefully I included enough for you to get the full jest of it! ;-)
> >
> > Hope this helps
> > Jay
> >
> > "Charles Law" <blank@nowhere.com> wrote in message
> > news:%2341E9JXSEHA.3552@TK2MSFTNGP09.phx.gbl...[color=darkred]
> > > Aah. All I meant was that I wouldn't be able to write
> > >
> > > Dim c1 As New IClass1
> > >
> > > To instantiate I would need to have a reference to the 'assembly'[/color][/color][/color]
(good,[color=blue][color=green][color=darkred]
> > > eh?) containing Class1.
> > >
> > > Yes, I would be interested to see an example of the Domain Model /[/color][/color][/color]
Data[color=blue][color=green][color=darkred]
> > > Mapper scenario, if it's not too much trouble.
> > >
> > > Charles
> > >[/color]
> > <<snip>>
> >
> >[/color]
>
>[/color]

What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

re: What do People do to avoid Tight Coupling?

Similar Visual Basic .NET bytes

/bytes/development

/bytes/it

/bytes/about