Global dataconnection

J

John

Hi

How can I setup a global dataconnection which is accessible by all forms so
each form does not have to open its own connection?

Thanks
 
W

William Ryan

You can stick it in a module for instance and that would give you global
access to it, but you would still want to open and close each connection
when you need it/then are done with it.

The better approach is to stick it all in a datalayer and let the component
return data to you. Let the component worry about opening and closing
connections. check out the MS DAAB. But no matter what, Do NOT have a
publicly available connection that you leave open throughout the session...

HTH,

Bill
 
D

David Browne

William Ryan said:
You can stick it in a module for instance and that would give you global
access to it, but you would still want to open and close each connection
when you need it/then are done with it.

The better approach is to stick it all in a datalayer and let the component
return data to you. Let the component worry about opening and closing
connections. check out the MS DAAB. But no matter what, Do NOT have a
publicly available connection that you leave open throughout the session...

Actually that I would do exactly that. For a winforms application there's
no real reason to use connection pooling. You will have at least one
connection open throughout the life of your app anyway, because the
connection pool will keep it open. So using a global connection doesn't
increase resource use significantly. Moreover keeping a connection open
allows you to use certian RDBMS features that rely on persistent connections
(temp tables, transactions, session-based data storage, etc).

Connection pooling is really a workaround used in application server
environments (web and COM+) to avoid frequently opening and closing physical
connections. Client-server applications don't really need it, and it just
brings another layer of complexity and reduces functionality.

So just open a global connection at startup and use it throughout your
application.

David
 
J

Jason

I would not use a global connection. First of all, it is a bad design (it
is not OOP). Second, keeping a connection open through out the app will
keep it in memory. I am assumming that you will not need to have the
connection open all the time. There are ways to limit the number of
connections to the database. I would design a data layer which each form
could access. This way you could seperate the database logic from the UI.
With that design, you could make changes to the UI or the Data Layer without
having a major impact on either.

Good Luck
 
D

David Browne

John said:
Where can I do that so it remains accessible to all forms?


In a module:

Module Globals
Public con as SqlConnection
end Module


or

In a shared member


Public Class SomeClass

Public shared con as SqlConnection


end class


David
 
D

David Browne

Jason said:
I would not use a global connection. First of all, it is a bad design (it
is not OOP).

There's nothing non-OOP about it.
Second, keeping a connection open through out the app will
keep it in memory.

So will a connection pool. And if you want to close it, you can.
I am assumming that you will not need to have the
connection open all the time. There are ways to limit the number of
connections to the database. I would design a data layer which each form
could access. This way you could seperate the database logic from the UI.

I agree that you should employ a data layer, but that's a different issue.
You still have to decide whether to use a global connection object or not.


David
 
J

Jason

Why would you need to have the connection global to the forms? Why not
encapsulate the connection in the data layer. And when you need to open a
connection, call the data layer which opens the connection and grabs the
data. From his post it seems to me that he is going to do all the database
logic (business rules) in the UI and I am trying to get him to create a data
layer and business layer. That way he does not need a global connection.
 
C

Cor

So just open a global connection at startup and use it throughout your
application.

I think also that it is a good approach, when your boss says maybe in
future, can we port our application to Internet you can say, no that was not
in my design, I did not know in 2003 that Internet exist.

:))

Cor
 
D

David Browne

Jason said:
Why would you need to have the connection global to the forms? Why not
encapsulate the connection in the data layer.

Sure, that would be good design.
And when you need to open a
connection, call the data layer which opens the connection and grabs the
data. From his post it seems to me that he is going to do all the database
logic (business rules) in the UI and I am trying to get him to create a data
layer and business layer. That way he does not need a global connection.

Again it's a totally seperate issue.

Here are 2 simple data layers, one using a persistent connection, one which
opens and closes a connection in each method. I would prefer the version
with the open connections in a client-server application. Heck, I even
prefer that version for web apps, you just have to Dispose the DAL object
after you use it each time.


Here is a DAL that keeps an open connection:

Public class DAL
Implements IDisposable

private con as SqlConnection

Public sub New()
con = new SqlConnection("...")
con.Open()
end sub

Public sub Dispose() implements IDisposable.Dispose
con.Close()
end sub

Public Sub CreateFoo(name as string)
dim cmd as new SqlCommand("insert into foo(name) values (@name)",con)
cmd.parameters.add(new SqlParameter("@name",name))
cmd.ExecuteNonQuery()

end sub

end class




Here is a DAL that opens and closes the connection each time:



Public class DAL

Public Sub CreateFoo(name as string)

dim con as new SqlConnection("...")
con.Open()
try
dim cmd as new SqlCommand("insert into foo(name) values (@name)",con)
cmd.parameters.add(new SqlParameter("@name",name))
cmd.ExecuteNonQuery()
finally
con.Close()
end try

end sub

end class
 
W

William Ryan

I respectfully disagree and would throw a fit if that were done under my
watch.


ADO.NET is architecturally built on Close and Kill methodology. In a
largely distrbuted system, this is key. Desktop or not, lets say 500 users
are using your app. Are you really advocating having 500 constantly open
connections to your DB? And even if the number is only 20 now, things tend
to grow, so you are limiting scalability all in the name of keeping a bad
habit.
All of the disconnected objects sure aren't going to use those resources
throughout the session, so why use them?


If there isn't a need to have the connection open, why leave it open? If
nothing else, it uses server resources that aren't needed.

What if also, you need to work in a disconnected mode? Our major app uses
SQL Server, but in case of a connection timeout or anything such problem,
all of the individual datasets are serialized locally and whenever the
server comes back up, they will update themselves.

Now, if you are totally connection dependent, let alone insist on keeping
the connection open, and the connection needs to be broken, you will have to
write a ton of logic to accomodate this and repoen everything. Maybe in an
ideal situation this doesn't happen, but that doesn't make it good practice.

There's a reason most every example you come across out there recommends
Immediately closing your connections unless you are going ot use them again
immediately...and there's a reason for that.

Bill
 
D

David Browne

William Ryan said:
I respectfully disagree and would throw a fit if that were done under my
watch.


ADO.NET is architecturally built on Close and Kill methodology. In a
largely distrbuted system, this is key. Desktop or not, lets say 500 users
are using your app. Are you really advocating having 500 constantly open
connections to your DB? And even if the number is only 20 now, things tend
to grow, so you are limiting scalability all in the name of keeping a bad
habit.
All of the disconnected objects sure aren't going to use those resources
throughout the session, so why use them?

Remember that the connection pool will keep the connection open anyway. So
as far as the server can tell, the client is using a persistent connection
anyway. The only alternative would be to explicily turn off connection
pooling and force the connections to actually close. But then you will be
constantly opening and closing connections to the database which is both
slow and costly. So there is no free lunch here. With either approach you
will generally have one database session for each client.

David
 
C

Cor

Hi David,

I understand it at least I think.

Bill uses a road from 10 miles long and you a road from 10 miles wide.

And you are right, riding over a road from 10 miles wide is more
comfortable.

Everybody can go as fast too the destignation as they want.

They don't need to pool the lane.

Cor
 
W

William Ryan

Once again, I disagree. The connection pool doesn't necessarily keep one
connection open. In an ideal world with a specific app, that may be so.
think about the context of my last post...... How does the connection pool
keep a live connection open when my server is totally down? We have in just
one of our apps well over 150 users at any given time. Some from the Web,
Some from the desktop, some from the PDA. If the server needs to go down,
and it often does, everything is trapped in an exception handler and then
transfers over to a serialized XML. My serialized XML file doesn't have a
connection pool as such....you don't even need a connection to accomplish
this. Ok, so maybe your server never goes down, or your pda users never go
out of the wireless/bluetooth spectrum...mine do. A few months back this
wasn't the case, but things grow. What is the benefit here of leaving a
connection open? Similarly, I have multiple apps that just talkto a web
service. It gets all of the data for me. No connection to a datasource.
The Web Service Returns a dataset. Is this totally out of the mainstream?
myDataSet = myWebService.MyMethod();? No client side connection whatsoever.
And my whole post was about making components out of things. Why in the
world would I want tight coupling? Sure, If I knew that I could count on a
static environment.. but I can't, and I'm not alone.

This was the whole point of my last post, and nothing about the connection
pool changes any of this. Components are the way to go in many instances
(in my world view, the only way to go most of the time). Let it worry about
connections if they are appropriate. If they aren't, the h*ll with them.
ADO.NET is not dependent on connections to a database as such, and the more
distributed your architecture, the more you'll realize the beauty of
seperating UI, DataAccess and business logic. These are all abstract
differences, and will remain such. I can connect into googles API without
using any derivative of the IDBConnection interface.... so how does the
connection pool even apply here?

I appreciate your point, but I think that methodology is limiting...and as a
general guideline...there's a lot more to it than what you bring up.
 
W

William Ryan

Cor:

What about a scenario where you have data access without a connection? XML,
web services? How do you take advantage of a connection pool with SQL CE?
Would anyone possibly recommend leaving a CE connection open? If not, then
why introduce design limitations? Apps tend to grow and get bigger, and
have more dynamic requirements? And building in design limitations isn't
the way to accomodate this. Is it?
 
C

Cor

Hi Bill,

I hope you did understand I did fully agree with you.

I have nothing to add to you'r last mail in this thread.

I did just wanted to show how outdated Williams words where with some more
simple to understand examples.

Cor
 
C

Cor

Hi William,

Oops, used the wrong names,

I agree with you without one exception in your statements

:))

Sorry, sorry sorry sorry

Cor
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top