Decoupling

[Sharon]

Hi.
I'm working on an application with a Data Access Layer, API and UI.
There are some entity classes defined in the DAL which the UI uses through
the API.
This means that there is some coupling between the DAL and the UI.
Is it possible or advisable to separate the DAL completely from the UI?
How can i achieve this?
Thanks,
Sharon.

[Michael Nemtsev]

Hello Sharon,

This doesn't completly mean that your UI/DAL is coupled. They are coupled
if they can't be divided and strictly depends on each other - for example
u use some internal DAL structures.
But if your entity traversing between layers as the published well-know entity
it's not coupling.
SI'm working on an application with a Data Access Layer, API and UI.
SThere are some entity classes defined in the DAL which the UI uses
Sthrough
Sthe API.
SThis means that there is some coupling between the DAL and the UI.
SIs it possible or advisable to separate the DAL completely from the
SUI?
SHow can i achieve this?
SThanks,
SSharon.
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Chris Fulstow]

I'd say that it's better practice to remove any dependecies between
your UI and DAL components. You could add some code to your API
(business layer) that in turn calls your DAL layer, then return the
data back to the UI from the API in whatever format is required.

Sharon wrote:

Hi.
I'm working on an application with a Data Access Layer, API and UI.
There are some entity classes defined in the DAL which the UI uses through
the API.
This means that there is some coupling between the DAL and the UI.
Is it possible or advisable to separate the DAL completely from the UI?
How can i achieve this?
Thanks,
Sharon.

[Dave Sexton]

Hi Sharon,

The three-layered architecture that you are using, when coded properly, allows
you to swap out one GUI with another, or change the location of your database,
or even its design, or add/modify/remove existing business rules in the API,
all independently of one another.

Your goal should be to optimize the coupling between dependant objects in
adjacent layers and ensure that you use flexible enough design patterns to
meet the needs of your application, which may help to make change control
easier as well.

If you feel that the current architecture isn't flexible enough, and can state
specific reasons why, then I'd recommend looking into other patterns to use in
conjunction with the layered approach that you have in place already.

An example of one such pattern is the ASP.NET 2.0 provider pattern (which
works quite well in WinForms apps too). This pattern provides a flexible,
pluggable architecture that you can use in your own object models to extend or
modify the ability of your application at a later time. If you feel that you
might need to modify API logic, or switch data storage contexts in the future,
or quite often now, then the provider pattern might be of use to you. The
abstract factory pattern in addition to the provider pattern provides an
extremely flexible framework for your object models. It's also highly
configurable through the web.config or [app].config files, with FCL support
for the base functionality of the provider infrastructure and simple
configuration handling.

Here's a list of some basic design patterns that you might find useful:

ASP.NET Provider Toolkit on MSDN:
http://msdn2.microsoft.com/en-us/asp.net/aa336558.aspx

Gang of Four (GOF) Patterns:
http://www.dofactory.com/Patterns/Patterns.aspx

There are many other references out there - just do some searching :)

--
Dave Sexton

"Sharon" <no*****@null.voidwrote in message
news:e0****************@TK2MSFTNGP04.phx.gbl...

Hi.
I'm working on an application with a Data Access Layer, API and UI.
There are some entity classes defined in the DAL which the UI uses through
the API.
This means that there is some coupling between the DAL and the UI.
Is it possible or advisable to separate the DAL completely from the UI?
How can i achieve this?
Thanks,
Sharon.

[Sharon]

Hi Michael.
The entity classes are defined in the DAL.
This means that for the UI to compile, the UI project needs reference to the
DAL project.
What do you mean by "traversing between layers" and "published well-know
entity"?
Thanks.

"Michael Nemtsev" <ne*****@msn.comwrote in message
news:17***************************@msnews.microsof t.com...

Hello Sharon,

This doesn't completly mean that your UI/DAL is coupled. They are coupled
if they can't be divided and strictly depends on each other - for example
u use some internal DAL structures.
But if your entity traversing between layers as the published well-know
entity it's not coupling.
SI'm working on an application with a Data Access Layer, API and UI.
SThere are some entity classes defined in the DAL which the UI uses
Sthrough
Sthe API.
SThis means that there is some coupling between the DAL and the UI.
SIs it possible or advisable to separate the DAL completely from the
SUI?
SHow can i achieve this?
SThanks,
SSharon.
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do
not cease to be insipid." (c) Friedrich Nietzsche

[Michael Nemtsev]

Hello Sharon,

Entity shouldn't be tied up with specific layer, it's just entity that represent
a part of your data
Create separate namespaces that will keep your entities and your UI and DAL
should correspont to interfaces of your entities (if only u select them not
using more general appoach with DataTables).

When u need to get specific data u just ask your DAL (more better ask BAL
about info and it ask DAL for his turn) and he returns you your data

SHi Michael.
SThe entity classes are defined in the DAL.
SThis means that for the UI to compile, the UI project needs reference
Sto the
SDAL project.
SWhat do you mean by "traversing between layers" and "published
Swell-know
Sentity"?
SThanks.
S"Michael Nemtsev" <ne*****@msn.comwrote in message
Snews:17***************************@msnews.microso ft.com...
S>

>Hello Sharon,

This doesn't completly mean that your UI/DAL is coupled. They are
coupled
if they can't be divided and strictly depends on each other - for
example
u use some internal DAL structures.
But if your entity traversing between layers as the published
well-know
entity it's not coupling.
SI'm working on an application with a Data Access Layer, API and
UI.
SThere are some entity classes defined in the DAL which the UI uses
Sthrough
Sthe API.
SThis means that there is some coupling between the DAL and the UI.
SIs it possible or advisable to separate the DAL completely from
the
SUI?
SHow can i achieve this?
SThanks,
SSharon.
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour
"At times one remains faithful to a cause only because its opponents
do not cease to be insipid." (c) Friedrich Nietzsche

---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Sharon]

Got it.
This way the application is also remoting ready.
Thanks.

"Michael Nemtsev" <ne*****@msn.comwrote in message
news:17***************************@msnews.microsof t.com...

Hello Sharon,

Entity shouldn't be tied up with specific layer, it's just entity that
represent a part of your data
Create separate namespaces that will keep your entities and your UI and
DAL should correspont to interfaces of your entities (if only u select
them not using more general appoach with DataTables).

When u need to get specific data u just ask your DAL (more better ask BAL
about info and it ask DAL for his turn) and he returns you your data

SHi Michael.
SThe entity classes are defined in the DAL.
SThis means that for the UI to compile, the UI project needs reference
Sto the
SDAL project.
SWhat do you mean by "traversing between layers" and "published
Swell-know
Sentity"?
SThanks.
S"Michael Nemtsev" <ne*****@msn.comwrote in message
Snews:17***************************@msnews.microso ft.com...
S>

>>Hello Sharon,

This doesn't completly mean that your UI/DAL is coupled. They are
coupled
if they can't be divided and strictly depends on each other - for
example
u use some internal DAL structures.
But if your entity traversing between layers as the published
well-know
entity it's not coupling.
SI'm working on an application with a Data Access Layer, API and
UI.
SThere are some entity classes defined in the DAL which the UI uses
Sthrough
Sthe API.
SThis means that there is some coupling between the DAL and the UI.
SIs it possible or advisable to separate the DAL completely from
the
SUI?
SHow can i achieve this?
SThanks,
SSharon.
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour
"At times one remains faithful to a cause only because its opponents
do not cease to be insipid." (c) Friedrich Nietzsche

---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do
not cease to be insipid." (c) Friedrich Nietzsche

[Sharon]

Thanks Dave.
I'm familiar with the factory pattern.
I'll learn the provider pattern and see how i can use it.
Sharon.

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2******************@TK2MSFTNGP05.phx.gbl...

Hi Sharon,

The three-layered architecture that you are using, when coded properly,
allows you to swap out one GUI with another, or change the location of
your database, or even its design, or add/modify/remove existing business
rules in the API, all independently of one another.

Your goal should be to optimize the coupling between dependant objects in
adjacent layers and ensure that you use flexible enough design patterns to
meet the needs of your application, which may help to make change control
easier as well.

If you feel that the current architecture isn't flexible enough, and can
state specific reasons why, then I'd recommend looking into other patterns
to use in conjunction with the layered approach that you have in place
already.

An example of one such pattern is the ASP.NET 2.0 provider pattern (which
works quite well in WinForms apps too). This pattern provides a flexible,
pluggable architecture that you can use in your own object models to
extend or modify the ability of your application at a later time. If you
feel that you might need to modify API logic, or switch data storage
contexts in the future, or quite often now, then the provider pattern
might be of use to you. The abstract factory pattern in addition to the
provider pattern provides an extremely flexible framework for your object
models. It's also highly configurable through the web.config or
[app].config files, with FCL support for the base functionality of the
provider infrastructure and simple configuration handling.

Here's a list of some basic design patterns that you might find useful:

ASP.NET Provider Toolkit on MSDN:
http://msdn2.microsoft.com/en-us/asp.net/aa336558.aspx

Gang of Four (GOF) Patterns:
http://www.dofactory.com/Patterns/Patterns.aspx

There are many other references out there - just do some searching :)

--
Dave Sexton

"Sharon" <no*****@null.voidwrote in message
news:e0****************@TK2MSFTNGP04.phx.gbl...

>Hi.
I'm working on an application with a Data Access Layer, API and UI.
There are some entity classes defined in the DAL which the UI uses
through the API.
This means that there is some coupling between the DAL and the UI.
Is it possible or advisable to separate the DAL completely from the UI?
How can i achieve this?
Thanks,
Sharon.