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

  • Thread starter Thread starter Charles Law
  • Start date Start date
C

Charles Law

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
 
Charles Law said:
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
|
Click to expand...
|
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.
Click to expand...

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.
 
Excellent information. I will read and digest.

Thanks.

Charles


Mr. Arnold said:
Charles Law said:
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
|
Click to expand...
|
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.
Click to expand...

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.
Click to expand...
 
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,

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
 
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 said:
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 said:
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
Click to expand...
Click to expand...
 
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
 
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
 
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 said:
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 said:
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 said:
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
Click to expand...
Click to expand...
Click to expand...
 
Back
Top