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. 10 1919
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
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.
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.
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.
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.
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.
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.
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
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
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
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: nospam |
last post by:
Reasons for a 3-tier achitecture for the WEB?
(NOTE: I said, WEB, NOT WINDOWS.
DON'T shoot your mouth off if you don't understand the difference.)
I hear only one reason and that's to switch a...
|
by: David Noble |
last post by:
We've been developing a web site using 3-tier architecture for 18
months now.
There is a common layer that defines the classes - using XML schemas.
The data layer acts as a wrapper to 3 databases...
|
by: rua17 |
last post by:
Anyone can recommend me a good book on how to build 3 tier applications in
..Net?
thanks
|
by: nospam |
last post by:
THIS IS the DOTNETJUNKIES MESSAGE
-------------------------
We're Sorry
As many of you know we have recently launched SqlJunkies.com. We have
overhauled our runtime and will be using it on...
|
by: mehdi_mousavi |
last post by:
Hi folks,
In an N-tier application, what is the possible values of N??? I'm not
kidding, I just interviewed with a programmer today, and he started the
"2-tier application" conversation. From then...
|
by: Rowan |
last post by:
Hi there,
I am planning/building an n-Tier system with 2 presentation layers
(web, windows) which will share the BLL and DAL. This is my first
experience with .Net. As a VB6er I had to work...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |