Connected & Disconnected architecture
-
Hi everyone, Can anyone guide me thru this? I'm quite bit confused with the ADO.NET connected & disconnected architectures The working method is not the prob, but i just wanted to know the real SIGNIFICANCE of both. ie, if connected Arch is better than disconnected arch, then why do we need disconnected arch in ADO.NET Or Vice versa. I hope u guys got me.. Thanks in advace. "Nothing goes unknown, unless.... " i think u know the answer :)
-
Hi everyone, Can anyone guide me thru this? I'm quite bit confused with the ADO.NET connected & disconnected architectures The working method is not the prob, but i just wanted to know the real SIGNIFICANCE of both. ie, if connected Arch is better than disconnected arch, then why do we need disconnected arch in ADO.NET Or Vice versa. I hope u guys got me.. Thanks in advace. "Nothing goes unknown, unless.... " i think u know the answer :)
Disconnected architecture means that you retrieve the data and work with it without being connected to the database. Basically, this means that you aren't holding connection resources open, which makes applications much more scalable. If you are working on a web application, then you can't really work in any other way - it is impractical and undesirable to leave connections open in scenarios like this.
Deja View - the feeling that you've seen this post before.
-
Disconnected architecture means that you retrieve the data and work with it without being connected to the database. Basically, this means that you aren't holding connection resources open, which makes applications much more scalable. If you are working on a web application, then you can't really work in any other way - it is impractical and undesirable to leave connections open in scenarios like this.
Deja View - the feeling that you've seen this post before.
-
Hi man, Thanx for the reply. But i hv one more query. If disconnected architecture is more reliable and scalable than the connected one, then why do we need the Connected Arch? why does ADO.NET provide both of them..?
The name is Sandeep
You should use connected arch. for quickly reading data in a readonly manner (meaning each record is read one time and navigation to past records is not possible). Can be used to quickly fill controls, etc. Using data readers def has its place and is very quick when used appropriately.
Any suggestions, ideas, or 'constructive criticism' are always welcome. "There's no such thing as a stupid question, only stupid people." - Mr. Garrison
-
You should use connected arch. for quickly reading data in a readonly manner (meaning each record is read one time and navigation to past records is not possible). Can be used to quickly fill controls, etc. Using data readers def has its place and is very quick when used appropriately.
Any suggestions, ideas, or 'constructive criticism' are always welcome. "There's no such thing as a stupid question, only stupid people." - Mr. Garrison
-
thanks buddy. i think i got it somewhat clear.
kissdznuts wrote:
Using data readers def has its place and is very quick when used appropriately.
can u please give a scenario in which the above said is satisfied..?
The name is Sandeep
A form could have a couple combo boxes that users cannot change the values of and each contains 50 items. You could use datareaders to very rapidly fill the combos. You might have to fill a collection or list object of some kind, you could initially fill the data quickly with a data reader. You wouldn't want to use a data reader and between each read perform a ton of checks and toggling UI properties, etc because you're keeping the connection alive. You want to use data readers in operations were the reads are very quick and then close the connection.
Any suggestions, ideas, or 'constructive criticism' are always welcome. "There's no such thing as a stupid question, only stupid people." - Mr. Garrison