Simple 3 tier stuff

[Andrew]

Sorry about this but I'm new to ADO.NET (finally coming from simple ADO,
bless it) and I'm trying to create a simple three tier program.
Ie, User interface Layer / Business object layer / Database layer

I've got a simple program that is activilly populating and writing my
satasets. They are currently only mapping the database tables.So 1 dataset,
5 datatables and several relationships.

In this program I can't seem to hide the database information very well from
the user interface. What I'm looking for is an example that hides all the
connection and data objects in the middle tier, so that the user interface
simply has to deal with collections and such like.

Any examples please would be greatly appricated. All the examples I have
found so far have been writing to datagrids and missing the point
completely.

[Peter Morris [Droopy eyes software]]

Hi

To hide the db stuff you should put it on another machine, have your client
machine talk to this other machine via webservices or some other technique
(remoting maybe).
--
Pete
-------
Read/Write .NET articles
http://www.howtodothings.com/showart...ubcategory=132

[One Handed Man \( OHM - Terry Burns \)]

Why should the connection be in the middle tier. The business logic should
be in the middle tier and the connections the lower tier.

Have you mapped your functionality and data flows yet, or did you just start
coding ?, I would sit down and think hard about what objects you need before
you put anymore fingers on keys.

There are several books on this subject, it would pay you to have a read.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

"Andrew" <an*****@nospam.dbasplus.com> wrote in message
news:e1**************@TK2MSFTNGP09.phx.gbl...

Sorry about this but I'm new to ADO.NET (finally coming from simple ADO,
bless it) and I'm trying to create a simple three tier program.
Ie, User interface Layer / Business object layer / Database layer

I've got a simple program that is activilly populating and writing my
satasets. They are currently only mapping the database tables.So 1 dataset, 5 datatables and several relationships.

In this program I can't seem to hide the database information very well from the user interface. What I'm looking for is an example that hides all the
connection and data objects in the middle tier, so that the user interface
simply has to deal with collections and such like.

Any examples please would be greatly appricated. All the examples I have
found so far have been writing to datagrids and missing the point
completely.

[William Ryan eMVP]

This should help
http://msdn.microsoft.com/library/de...ml/daab-rm.asp

--

W.G. Ryan, eMVP

Have an opinion on the effectiveness of Microsoft Embedded newsgroups?
Let Microsoft know!
https://www.windowsembeddedeval.com/...ity/newsgroups
"Andrew" <an*****@nospam.dbasplus.com> wrote in message
news:e1**************@TK2MSFTNGP09.phx.gbl...

Sorry about this but I'm new to ADO.NET (finally coming from simple ADO,
bless it) and I'm trying to create a simple three tier program.
Ie, User interface Layer / Business object layer / Database layer

I've got a simple program that is activilly populating and writing my
satasets. They are currently only mapping the database tables.So 1 dataset, 5 datatables and several relationships.

In this program I can't seem to hide the database information very well from the user interface. What I'm looking for is an example that hides all the
connection and data objects in the middle tier, so that the user interface
simply has to deal with collections and such like.

Any examples please would be greatly appricated. All the examples I have
found so far have been writing to datagrids and missing the point
completely.

[William Ryan eMVP]

OHM:

With all due respect, I don't think that's really a safe statement to make
across the board. Check out Microsoft's Data access Application Block for
instance. (I'm not saying it's perfeect but it does the job quite well in
this n-Tier scenario). Many of the methods just take a COnnection String as
a parameter. What's wrong with that? Even from a logical perspective - if
you have n-Tier it makes sense, if you have a 3-tier solution it still can
make sense. Your business objects for instance should call the backend
logic - the front tier would just deal with UI issues. Not sure I see a
downside to fully encapsulating everything data access wise in the middle
tier or tier(s)

--

W.G. Ryan, eMVP

Have an opinion on the effectiveness of Microsoft Embedded newsgroups?
Let Microsoft know!
https://www.windowsembeddedeval.com/...ity/newsgroups
"One Handed Man ( OHM - Terry Burns )" <news.microsoft.com> wrote in message
news:Oi**************@TK2MSFTNGP11.phx.gbl...

Why should the connection be in the middle tier. The business logic should
be in the middle tier and the connections the lower tier.

Have you mapped your functionality and data flows yet, or did you just start coding ?, I would sit down and think hard about what objects you need before you put anymore fingers on keys.

There are several books on this subject, it would pay you to have a read.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

"Andrew" <an*****@nospam.dbasplus.com> wrote in message
news:e1**************@TK2MSFTNGP09.phx.gbl...

Sorry about this but I'm new to ADO.NET (finally coming from simple ADO,
bless it) and I'm trying to create a simple three tier program.
Ie, User interface Layer / Business object layer / Database layer

I've got a simple program that is activilly populating and writing my
satasets. They are currently only mapping the database tables.So 1

dataset,

5 datatables and several relationships.

In this program I can't seem to hide the database information very well

from

the user interface. What I'm looking for is an example that hides all the connection and data objects in the middle tier, so that the user interface simply has to deal with collections and such like.

Any examples please would be greatly appricated. All the examples I have
found so far have been writing to datagrids and missing the point
completely.

[One Handed Man \( OHM - Terry Burns \)]

Well, the reality of it is that the objects themselves dont really allways
lend themselves to 3 tier design because of their own nature of dependency,
however, you can be clever about it if you really try and in many cases
almost or fully encapsulate the layers.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

"William Ryan eMVP" <do********@comcast.nospam.net> wrote in message
news:O6**************@tk2msftngp13.phx.gbl...

OHM:

With all due respect, I don't think that's really a safe statement to make
across the board. Check out Microsoft's Data access Application Block for
instance. (I'm not saying it's perfeect but it does the job quite well in
this n-Tier scenario). Many of the methods just take a COnnection String as a parameter. What's wrong with that? Even from a logical perspective - if you have n-Tier it makes sense, if you have a 3-tier solution it still can
make sense. Your business objects for instance should call the backend
logic - the front tier would just deal with UI issues. Not sure I see a
downside to fully encapsulating everything data access wise in the middle
tier or tier(s)

--

W.G. Ryan, eMVP

Have an opinion on the effectiveness of Microsoft Embedded newsgroups?
Let Microsoft know!
https://www.windowsembeddedeval.com/...ity/newsgroups
"One Handed Man ( OHM - Terry Burns )" <news.microsoft.com> wrote in message news:Oi**************@TK2MSFTNGP11.phx.gbl...

Why should the connection be in the middle tier. The business logic should

be in the middle tier and the connections the lower tier.

Have you mapped your functionality and data flows yet, or did you just

start

coding ?, I would sit down and think hard about what objects you need

before

you put anymore fingers on keys.

There are several books on this subject, it would pay you to have a read.
--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

"Andrew" <an*****@nospam.dbasplus.com> wrote in message
news:e1**************@TK2MSFTNGP09.phx.gbl...

Sorry about this but I'm new to ADO.NET (finally coming from simple ADO, bless it) and I'm trying to create a simple three tier program.
Ie, User interface Layer / Business object layer / Database layer

I've got a simple program that is activilly populating and writing my
satasets. They are currently only mapping the database tables.So 1

dataset,

5 datatables and several relationships.

In this program I can't seem to hide the database information very well

from

the user interface. What I'm looking for is an example that hides all

the connection and data objects in the middle tier, so that the user interface simply has to deal with collections and such like.

Any examples please would be greatly appricated. All the examples I

have found so far have been writing to datagrids and missing the point
completely.

[Andrew]

Thanks for the replies.

The examples are a bit of a mountain to go through, but good. Although I do
keep asking myself about how best to implement my program in a simple
manner.

For now I am simply doing a subset of an original program, so mapping my
dataflows etc are not necessary as it is already defined.
I have several hierarchal classes that in VB6 and ADO were mapped into
parent/child collection classes, to handle all the data mapping and database
access.
In .NET I am trying to do similar, but I do not have the luxary of
exclusively targeting SQL server as some users insist on using an Access
database (a long story), so Stored Procedures are out. And I don't want to
tie the dataset to Form controls.

What is the best way to map a hierarchal database in .NET given that I would
like it pretty tierd.

Cheers.

"Andrew" <an*****@nospam.dbasplus.com> wrote in message
news:e1**************@TK2MSFTNGP09.phx.gbl...

Sorry about this but I'm new to ADO.NET (finally coming from simple ADO,
bless it) and I'm trying to create a simple three tier program.
Ie, User interface Layer / Business object layer / Database layer

I've got a simple program that is activilly populating and writing my
satasets. They are currently only mapping the database tables.So 1 dataset, 5 datatables and several relationships.

In this program I can't seem to hide the database information very well from the user interface. What I'm looking for is an example that hides all the
connection and data objects in the middle tier, so that the user interface
simply has to deal with collections and such like.

Any examples please would be greatly appricated. All the examples I have
found so far have been writing to datagrids and missing the point
completely.

[One Handed Man \( OHM - Terry Burns \)]

Stored proceedure are not our. Access has them as well, they are called
Queries!

Regards -OHM

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

"Andrew" <an*****@nospam.dbasplus.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

Thanks for the replies.

The examples are a bit of a mountain to go through, but good. Although I do keep asking myself about how best to implement my program in a simple
manner.

For now I am simply doing a subset of an original program, so mapping my
dataflows etc are not necessary as it is already defined.
I have several hierarchal classes that in VB6 and ADO were mapped into
parent/child collection classes, to handle all the data mapping and database access.
In .NET I am trying to do similar, but I do not have the luxary of
exclusively targeting SQL server as some users insist on using an Access
database (a long story), so Stored Procedures are out. And I don't want to
tie the dataset to Form controls.

What is the best way to map a hierarchal database in .NET given that I would like it pretty tierd.

Cheers.

"Andrew" <an*****@nospam.dbasplus.com> wrote in message
news:e1**************@TK2MSFTNGP09.phx.gbl...

Sorry about this but I'm new to ADO.NET (finally coming from simple ADO,
bless it) and I'm trying to create a simple three tier program.
Ie, User interface Layer / Business object layer / Database layer

I've got a simple program that is activilly populating and writing my
satasets. They are currently only mapping the database tables.So 1

dataset,

5 datatables and several relationships.

In this program I can't seem to hide the database information very well

from

the user interface. What I'm looking for is an example that hides all the connection and data objects in the middle tier, so that the user interface simply has to deal with collections and such like.

Any examples please would be greatly appricated. All the examples I have
found so far have been writing to datagrids and missing the point
completely.

[Richard Myers]

Howdy Andrew

If you have a need to switch the DAL then i would suggest using the Provider
pattern. Basically the provider pattern allows you to use the same business
logic for different DALs.

So for instance i have just completed an application for a customer whereby
the same BL was used for both a website and a winforms application. The Web
Forms app used SQL Server and the Winforms app used Access 2000. The middle
tier was the same for both deployments which prevented alot of redundant
coding/time waste.

With this kind of architecture you essentially split your DAL into an upper
layer interface that the BL talks to and this then passes through the BL's
request for data retrieval/persistance to a loosely coupled datastore, which
could be XML/OleDb\MSSql\Oracle, you name it.

The loose coupling is achieved via the config file which looks up a section
handler for a particular business object and uses that to reference an
assembly that contains datastore specific commands to communicate with the
choosen data store.

For instance OleDb commands for Access, SqlCommand for Sql Server.

The real beauty here is when you are exactly replicating the datastore from
say an MS Sql Db to an Access.mdb such that the schema is the essentially
the same. Given ADO.Net is object oriented, many of the data specific
providers inherit/implement from the base classes in the System.Data
namespace.

So for instance OleDbDataReader inherits from IDataReader.

This subclassing/implementation provides a terrific opportunity for even
more code reuse as you can fill your business objects from the upper
interface layer of the DAL mentioned earlier, using these System.Data base
classes as argument types in the various method signatures.

Public Function FillMyObject(dr as IDatareader) as MyBusinessObject

In this way, the loosely coupled data access logic of the lower DAL becomes
a very simple pass through layer for accessing specific datastores. Nothing
more, nothing less.
In short i think the mind shift you need to look for if you are going to
harness the real power of ADO.net is to seek to make the most out of it's
OOP only features and benefits. It will be a sad waste if all you do is
learn the syntax such that you just repeat what you used to do in dowdy old
ADO.

hth
Richard

[Andrew]

Thanks a lot for this Richard. I have been looking forward to getting my
hands dirty with ADO.NET for sometime now, mainly because it is OO enabled.
You are right that it is a mind shift to get used to after so many years of
simple ADO. After looking forward to using .NET I guess it will take me a
while to get used to real OO, not my pseudo, bastardised, understanding of
OO from VB6/ADO.

"Richard Myers" <ri*********************@basd.co.nz> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

Howdy Andrew

If you have a need to switch the DAL then i would suggest using the Provider pattern. Basically the provider pattern allows you to use the same business logic for different DALs.

So for instance i have just completed an application for a customer whereby the same BL was used for both a website and a winforms application. The Web Forms app used SQL Server and the Winforms app used Access 2000. The middle tier was the same for both deployments which prevented alot of redundant
coding/time waste.

With this kind of architecture you essentially split your DAL into an upper layer interface that the BL talks to and this then passes through the BL's
request for data retrieval/persistance to a loosely coupled datastore, which could be XML/OleDb\MSSql\Oracle, you name it.

The loose coupling is achieved via the config file which looks up a section handler for a particular business object and uses that to reference an
assembly that contains datastore specific commands to communicate with the
choosen data store.

For instance OleDb commands for Access, SqlCommand for Sql Server.

The real beauty here is when you are exactly replicating the datastore from say an MS Sql Db to an Access.mdb such that the schema is the essentially
the same. Given ADO.Net is object oriented, many of the data specific
providers inherit/implement from the base classes in the System.Data
namespace.

So for instance OleDbDataReader inherits from IDataReader.

This subclassing/implementation provides a terrific opportunity for even
more code reuse as you can fill your business objects from the upper
interface layer of the DAL mentioned earlier, using these System.Data base
classes as argument types in the various method signatures.

Public Function FillMyObject(dr as IDatareader) as MyBusinessObject

In this way, the loosely coupled data access logic of the lower DAL becomes a very simple pass through layer for accessing specific datastores. Nothing more, nothing less.
In short i think the mind shift you need to look for if you are going to
harness the real power of ADO.net is to seek to make the most out of it's
OOP only features and benefits. It will be a sad waste if all you do is
learn the syntax such that you just repeat what you used to do in dowdy old ADO.

hth
Richard

[Andrew]

Typed DataSets. That's what I was looking for all along. What wondrous
things they truly are.

"Andrew" <an*****@nospam.dbasplus.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Thanks a lot for this Richard. I have been looking forward to getting my
hands dirty with ADO.NET for sometime now, mainly because it is OO enabled. You are right that it is a mind shift to get used to after so many years of simple ADO. After looking forward to using .NET I guess it will take me a
while to get used to real OO, not my pseudo, bastardised, understanding of
OO from VB6/ADO.

"Richard Myers" <ri*********************@basd.co.nz> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

Howdy Andrew

If you have a need to switch the DAL then i would suggest using the

Provider

pattern. Basically the provider pattern allows you to use the same

business

logic for different DALs.

So for instance i have just completed an application for a customer

whereby

the same BL was used for both a website and a winforms application. The

Web

Forms app used SQL Server and the Winforms app used Access 2000. The

middle

tier was the same for both deployments which prevented alot of redundant
coding/time waste.

With this kind of architecture you essentially split your DAL into an

upper

layer interface that the BL talks to and this then passes through the BL's request for data retrieval/persistance to a loosely coupled datastore,

which

could be XML/OleDb\MSSql\Oracle, you name it.

The loose coupling is achieved via the config file which looks up a

section

handler for a particular business object and uses that to reference an
assembly that contains datastore specific commands to communicate with the choosen data store.

For instance OleDb commands for Access, SqlCommand for Sql Server.

The real beauty here is when you are exactly replicating the datastore

from

say an MS Sql Db to an Access.mdb such that the schema is the essentially the same. Given ADO.Net is object oriented, many of the data specific
providers inherit/implement from the base classes in the System.Data
namespace.

So for instance OleDbDataReader inherits from IDataReader.

This subclassing/implementation provides a terrific opportunity for even
more code reuse as you can fill your business objects from the upper
interface layer of the DAL mentioned earlier, using these System.Data base classes as argument types in the various method signatures.

Public Function FillMyObject(dr as IDatareader) as MyBusinessObject

In this way, the loosely coupled data access logic of the lower DAL

becomes

a very simple pass through layer for accessing specific datastores.

Nothing

more, nothing less.
In short i think the mind shift you need to look for if you are going to
harness the real power of ADO.net is to seek to make the most out of it's OOP only features and benefits. It will be a sad waste if all you do is
learn the syntax such that you just repeat what you used to do in dowdy

old

ADO.

hth
Richard