Three-tier Model and Coupling: Raising Events and passing Business Objects

This is a sort of pattern question, but relating to how components are
coupled in a three-tier system.

I have a presentation layer, business layer and data access layer, the first
is the EXE, whilst the other two are implemented as DLLs. The EXE also
references a DLL that contains various user controls, one of which is based
on a grid control.

The coupling is currently like this:

Presentation.EXE -------- Controls.DLL
|
Business.DLL
|
Data.DLL

[I hope that shows up clearly enough]

When a row on a grid (in Controls.DLL) is clicked, an event is raised to
alert the presentation layer that a row has been selected, and to pass the
contents of that row; my RowClickedEventArgs object currently passes a
couple of strings.

I would like my RowClickedEventArgs to pass a Transaction (my invention)
object instead, so that if a blank row is clicked I can pass a null object
(Nothing). The problem is that the Transaction class is defined in the
Business Layer, because that is the class that is used to pass data between
the Presentation Layer and the Data Access Layer, and I don't think that the
Controls.DLL should be coupled to the Business Layer.

Can anyone offer a neat/correct solution to this? I imagine that this not an
uncommon scenario.

TIA.

Charles

Re: Three-tier Model and Coupling: Raising Events and passing Business Objects

"Charles Law" wrote in message
news:%23FWYQ7tJIHA.4688@TK2MSFTNGP06.phx.gbl...
> This is a sort of pattern question, but relating to how components are
> coupled in a three-tier system.
>
> I have a presentation layer, business layer and data access layer, the
> first is the EXE, whilst the other two are implemented as DLLs. The EXE
> also references a DLL that contains various user controls, one of which is
> based on a grid control.
>
> The coupling is currently like this:
>
> Presentation.EXE -------- Controls.DLL
> |
|
MVP

It looks like you need the MVP layer beteen the BL and the UI

MVP layer is coupled to the UI and the BL
|
|
> Business.DLL
> |
> Data.DLL
>
> [I hope that shows up clearly enough]
>
> When a row on a grid (in Controls.DLL) is clicked, an event is raised to
> alert the presentation layer that a row has been selected, and to pass the
> contents of that row; my RowClickedEventArgs object currently passes a
> couple of strings.
>
> I would like my RowClickedEventArgs to pass a Transaction (my invention)
> object instead, so that if a blank row is clicked I can pass a null object
> (Nothing). The problem is that the Transaction class is defined in the
> Business Layer, because that is the class that is used to pass data
> between the Presentation Layer and the Data Access Layer, and I don't
> think that the Controls.DLL should be coupled to the Business Layer.
>
> Can anyone offer a neat/correct solution to this? I imagine that this not
> an uncommon scenario.
>

You also may want to look at the Service Controller Layer as well.

MODEL-VIEW-PRESENTER

http://www.polymorphicpodcast.com/

click 'Shows'

click 'Design Patterns Bootcamp: Model View * Patterns*

view parts 1-5

You can use Google to get more information about this or find books.

Business objects should not be addressed at the UI. The UI should be unaware
of the business object, if at all possible.

Re: Three-tier Model and Coupling: Raising Events and passing Business Objects

Excellent information. I will read and digest.

Thanks.

Charles


"Mr. Arnold" wrote in message
news:O1otlPxJIHA.3916@TK2MSFTNGP02.phx.gbl...
>
> "Charles Law" wrote in message
> news:%23FWYQ7tJIHA.4688@TK2MSFTNGP06.phx.gbl...
>> This is a sort of pattern question, but relating to how components are
>> coupled in a three-tier system.
>>
>> I have a presentation layer, business layer and data access layer, the
>> first is the EXE, whilst the other two are implemented as DLLs. The EXE
>> also references a DLL that contains various user controls, one of which
>> is based on a grid control.
>>
>> The coupling is currently like this:
>>
>> Presentation.EXE -------- Controls.DLL
>> |
> |
> MVP
>
> It looks like you need the MVP layer beteen the BL and the UI
>
> MVP layer is coupled to the UI and the BL
> |
> |
>> Business.DLL
>> |
>> Data.DLL
>>
>> [I hope that shows up clearly enough]
>>
>> When a row on a grid (in Controls.DLL) is clicked, an event is raised to
>> alert the presentation layer that a row has been selected, and to pass
>> the contents of that row; my RowClickedEventArgs object currently passes
>> a couple of strings.
>>
>> I would like my RowClickedEventArgs to pass a Transaction (my invention)
>> object instead, so that if a blank row is clicked I can pass a null
>> object (Nothing). The problem is that the Transaction class is defined in
>> the Business Layer, because that is the class that is used to pass data
>> between the Presentation Layer and the Data Access Layer, and I don't
>> think that the Controls.DLL should be coupled to the Business Layer.
>>
>> Can anyone offer a neat/correct solution to this? I imagine that this not
>> an uncommon scenario.
>>
>
> You also may want to look at the Service Controller Layer as well.
>
> MODEL-VIEW-PRESENTER
>
> http://www.polymorphicpodcast.com/
>
> click 'Shows'
>
> click 'Design Patterns Bootcamp: Model View * Patterns*
>
> view parts 1-5
>
> You can use Google to get more information about this or find books.
>
> Business objects should not be addressed at the UI. The UI should be
> unaware of the business object, if at all possible.
>
>
>
>
>
>

Re: Three-tier Model and Coupling: Raising Events and passing Business Objects

Sounds like you may want to define an abstract Interface that your
transaction can implement. Create an Interface DLL that defines the members
of your custom transaction. Then both your business and presentation can
consume "ITransaction" dll. Your business layer can return the transaction
object (which will implement your custom ITransaction interface) without
your controls dll actually being dependent on business or data DLL's.

In a true three-*tier* (as oppossed to three-layer) architecture (which
nobody seems to grasp nowadays) the business/data DLL's should NOT exist in
the same machine as the presentation (many reasons for this). Using common
lightweight interfaces stubs between the tiers is essential.


"Charles Law" wrote in message
news:%23FWYQ7tJIHA.4688@TK2MSFTNGP06.phx.gbl...
> This is a sort of pattern question, but relating to how components are
> coupled in a three-tier system.
>
> I have a presentation layer, business layer and data access layer, the
> first is the EXE, whilst the other two are implemented as DLLs. The EXE
> also references a DLL that contains various user controls, one of which is
> based on a grid control.
>
> The coupling is currently like this:
>
> Presentation.EXE -------- Controls.DLL
> |
> Business.DLL
> |
> Data.DLL
>
> [I hope that shows up clearly enough]
>
> When a row on a grid (in Controls.DLL) is clicked, an event is raised to
> alert the presentation layer that a row has been selected, and to pass the
> contents of that row; my RowClickedEventArgs object currently passes a
> couple of strings.
>
> I would like my RowClickedEventArgs to pass a Transaction (my invention)
> object instead, so that if a blank row is clicked I can pass a null object
> (Nothing). The problem is that the Transaction class is defined in the
> Business Layer, because that is the class that is used to pass data
> between the Presentation Layer and the Data Access Layer, and I don't
> think that the Controls.DLL should be coupled to the Business Layer.
>
> Can anyone offer a neat/correct solution to this? I imagine that this not
> an uncommon scenario.
>
> TIA.
>
> Charles
>
>

Re: Three-tier Model and Coupling: Raising Events and passing Business Objects

Charles,

I lately have moved a forms from what you call the main layer to the what
you call your control layer.

(Just use the so often by Herfried and Armin showed application run module
in a sepperated project)

It made a lot of things much easier.

Cor

Re: Three-tier Model and Coupling: Raising Events and passing Business Objects

Hi, thanks for the reply.

You can tell how long I've been away from this as I didn't even think of
interfaces; duh!

I'll give that a shot.

Cheers

Charles


"CMM" wrote in message
news:4D5247E9-ED9A-47F4-A915-F8385A417C99@microsoft.com...
> Sounds like you may want to define an abstract Interface that your
> transaction can implement. Create an Interface DLL that defines the
> members of your custom transaction. Then both your business and
> presentation can consume "ITransaction" dll. Your business layer can
> return the transaction object (which will implement your custom
> ITransaction interface) without your controls dll actually being dependent
> on business or data DLL's.
>
> In a true three-*tier* (as oppossed to three-layer) architecture (which
> nobody seems to grasp nowadays) the business/data DLL's should NOT exist
> in the same machine as the presentation (many reasons for this). Using
> common lightweight interfaces stubs between the tiers is essential.
>
>
> "Charles Law" wrote in message
> news:%23FWYQ7tJIHA.4688@TK2MSFTNGP06.phx.gbl...
>> This is a sort of pattern question, but relating to how components are
>> coupled in a three-tier system.
>>
>> I have a presentation layer, business layer and data access layer, the
>> first is the EXE, whilst the other two are implemented as DLLs. The EXE
>> also references a DLL that contains various user controls, one of which
>> is based on a grid control.
>>
>> The coupling is currently like this:
>>
>> Presentation.EXE -------- Controls.DLL
>> |
>> Business.DLL
>> |
>> Data.DLL
>>
>> [I hope that shows up clearly enough]
>>
>> When a row on a grid (in Controls.DLL) is clicked, an event is raised to
>> alert the presentation layer that a row has been selected, and to pass
>> the contents of that row; my RowClickedEventArgs object currently passes
>> a couple of strings.
>>
>> I would like my RowClickedEventArgs to pass a Transaction (my invention)
>> object instead, so that if a blank row is clicked I can pass a null
>> object (Nothing). The problem is that the Transaction class is defined in
>> the Business Layer, because that is the class that is used to pass data
>> between the Presentation Layer and the Data Access Layer, and I don't
>> think that the Controls.DLL should be coupled to the Business Layer.
>>
>> Can anyone offer a neat/correct solution to this? I imagine that this not
>> an uncommon scenario.
>>
>> TIA.
>>
>> Charles
>>
>>
>

Re: Three-tier Model and Coupling: Raising Events and passing Business Objects

Hi Cor

I see what you mean, but I was trying to keep the Controls and Forms
separate. I can move the form out of the top level, but it seems to me that
it just moves the problem elsewhere. I could put the forms and controls in
the same module, but then that would create tighter coupling.

Regards

Charles


"Cor Ligthert[MVP]" wrote in message
news:3A4C9127-A2C8-420A-8657-60FDB0AC01A2@microsoft.com...
> Charles,
>
> I lately have moved a forms from what you call the main layer to the what
> you call your control layer.
>
> (Just use the so often by Herfried and Armin showed application run module
> in a sepperated project)
>
> It made a lot of things much easier.
>
> Cor

Re: Three-tier Model and Coupling: Raising Events and passing Business Objects

Charles,

It makes casting very easy something you cannot do now with your exe.

You don't want to do that, however not personal meant, laws show how we have
to behave, but that does not mean that here is never smoked hashish.

:-)

Cor

Re: Three-tier Model and Coupling: Raising Events and passing Business Objects

Also remember that this way your business or data layer can "return" a
transaction object to the controls DLL for it to keep around (for whatever
reason) without it directly referencing the business or data layer. Simply
define a settable IMyTransaction property in your event arguments. When the
business or data layer get the event, they instantiate an object that
defines your interface (which of course is shared in a lightweight abtract
interfaces DLL that all the layers share).

"Charles Law" wrote in message
news:OCe6Yj2JIHA.4880@TK2MSFTNGP03.phx.gbl...
> Hi, thanks for the reply.
>
> You can tell how long I've been away from this as I didn't even think of
> interfaces; duh!
>
> I'll give that a shot.
>
> Cheers
>
> Charles
>
>
> "CMM" wrote in message
> news:4D5247E9-ED9A-47F4-A915-F8385A417C99@microsoft.com...
>> Sounds like you may want to define an abstract Interface that your
>> transaction can implement. Create an Interface DLL that defines the
>> members of your custom transaction. Then both your business and
>> presentation can consume "ITransaction" dll. Your business layer can
>> return the transaction object (which will implement your custom
>> ITransaction interface) without your controls dll actually being
>> dependent on business or data DLL's.
>>
>> In a true three-*tier* (as oppossed to three-layer) architecture (which
>> nobody seems to grasp nowadays) the business/data DLL's should NOT exist
>> in the same machine as the presentation (many reasons for this). Using
>> common lightweight interfaces stubs between the tiers is essential.
>>
>>
>> "Charles Law" wrote in message
>> news:%23FWYQ7tJIHA.4688@TK2MSFTNGP06.phx.gbl...
>>> This is a sort of pattern question, but relating to how components are
>>> coupled in a three-tier system.
>>>
>>> I have a presentation layer, business layer and data access layer, the
>>> first is the EXE, whilst the other two are implemented as DLLs. The EXE
>>> also references a DLL that contains various user controls, one of which
>>> is based on a grid control.
>>>
>>> The coupling is currently like this:
>>>
>>> Presentation.EXE -------- Controls.DLL
>>> |
>>> Business.DLL
>>> |
>>> Data.DLL
>>>
>>> [I hope that shows up clearly enough]
>>>
>>> When a row on a grid (in Controls.DLL) is clicked, an event is raised to
>>> alert the presentation layer that a row has been selected, and to pass
>>> the contents of that row; my RowClickedEventArgs object currently passes
>>> a couple of strings.
>>>
>>> I would like my RowClickedEventArgs to pass a Transaction (my invention)
>>> object instead, so that if a blank row is clicked I can pass a null
>>> object (Nothing). The problem is that the Transaction class is defined
>>> in the Business Layer, because that is the class that is used to pass
>>> data between the Presentation Layer and the Data Access Layer, and I
>>> don't think that the Controls.DLL should be coupled to the Business
>>> Layer.
>>>
>>> Can anyone offer a neat/correct solution to this? I imagine that this
>>> not an uncommon scenario.
>>>
>>> TIA.
>>>
>>> Charles
>>>
>>>
>>
>
>